Sampling question on merge

Moderator: SecondMan

User avatar
razzy
Fusioneer
Posts: 143
Joined: Sun Aug 10, 2014 3:12 pm
Location: Vancouver, British Columbia, Canada

Sampling question on merge

#1

Post by razzy » Fri Dec 18, 2015 2:24 pm

Hey,

So I have this really simple merge. I have a foreground image that is smaller is resolution than the background. The difference would be like 401x556 pixel aspect 1:1 over a 2K HD image aspect pixel aspect 1:1.

So when I merge them sampling is occurring on the foreground image. I may be having a brain fart, but in my book this should not be happening!

Thought anyone? You can even see the shift, no transforms are being done!

edit: So it seems to move in x by .5 of a pixel. If I move it back that much it looks the same!

cheers

User avatar
SecondMan
Site Admin
Posts: 3366
Joined: Thu Jul 31, 2014 5:31 pm
Answers: 2
Location: Vancouver, Canada
Been thanked: 65 times
Contact:

Re: Sampling question on merge

#2

Post by SecondMan » Fri Dec 18, 2015 2:33 pm

Shift your merge half a pixel horizontally, using the background resolution as your Reference size.

User avatar
razzy
Fusioneer
Posts: 143
Joined: Sun Aug 10, 2014 3:12 pm
Location: Vancouver, British Columbia, Canada

Re: Sampling question on merge

#3

Post by razzy » Fri Dec 18, 2015 2:36 pm

SecondMan wrote:Shift your merge half a pixel horizontally, using the background resolution as your Reference size.
I did! :-) I edited my original post, prior to your post.

I guess I am just wondering why?

cheers

User avatar
SecondMan
Site Admin
Posts: 3366
Joined: Thu Jul 31, 2014 5:31 pm
Answers: 2
Location: Vancouver, Canada
Been thanked: 65 times
Contact:

Re: Sampling question on merge

#4

Post by SecondMan » Fri Dec 18, 2015 2:37 pm

The reason being that there will be no filtering only if your pixels fit over eachother one to one. Because your FG resolution has an uneven dimension (so the center is in the middle of a pixel) and your BG is even (so center is inbetween pixels), you need to shift either over a little.

User avatar
razzy
Fusioneer
Posts: 143
Joined: Sun Aug 10, 2014 3:12 pm
Location: Vancouver, British Columbia, Canada

Re: Sampling question on merge

#5

Post by razzy » Fri Dec 18, 2015 2:39 pm

SecondMan wrote:The reason being that there will be no filtering only if your pixels fit over eachother one to one. Because your FG resolution has an uneven dimension (so the center is in the middle of a pixel) and your BG is even (so center is inbetween pixels), you need to shift either over a little.

Ok thanks I was just coming to the same conclusion. I don't like that very much

cheers

User avatar
SecondMan
Site Admin
Posts: 3366
Joined: Thu Jul 31, 2014 5:31 pm
Answers: 2
Location: Vancouver, Canada
Been thanked: 65 times
Contact:

Re: Sampling question on merge

#6

Post by SecondMan » Fri Dec 18, 2015 2:42 pm

razzy wrote:
SecondMan wrote:The reason being that there will be no filtering only if your pixels fit over eachother one to one. Because your FG resolution has an uneven dimension (so the center is in the middle of a pixel) and your BG is even (so center is inbetween pixels), you need to shift either over a little.

Ok thanks I was just coming to the same conclusion. I don't like that very much

cheers
Well, it's math. Liking is irrelevant :)

User avatar
razzy
Fusioneer
Posts: 143
Joined: Sun Aug 10, 2014 3:12 pm
Location: Vancouver, British Columbia, Canada

Re: Sampling question on merge

#7

Post by razzy » Fri Dec 18, 2015 2:59 pm

Well you are correct. Can't change the laws of math! :-) One of the issues of this kind of merging with the merge being at .5,.5. I should say "software" that use pixels as position not resolution independent values from 0 -> 1 and merge the pixels over pixels!

User avatar
Chad
Fusionator
Posts: 1381
Joined: Fri Aug 08, 2014 1:11 pm
Been thanked: 8 times

Re: Sampling question on merge

#8

Post by Chad » Sat Dec 19, 2015 7:39 am

To clarify, it's an issue if you merge an odd image over an even one or an even one over an odd one. For even over even (the most common case) or odd over odd, the default .5 works fine.

This assumes pixels are the same size, of course. If your pixels are not the same size you'll get filtering.

User avatar
razzy
Fusioneer
Posts: 143
Joined: Sun Aug 10, 2014 3:12 pm
Location: Vancouver, British Columbia, Canada

Re: Sampling question on merge

#9

Post by razzy » Sat Dec 19, 2015 9:14 am

Thanks chad, that is duly noted, but I got it already ;-) Frankly I figured it was that, but I like to ask and talk about issues so I understand and am not just guessing, even stupid/obvious questions :-)

However, I did not want to bring up specific software so there is some kind of debate, but when you merge in others, that are pixel based, they just blend one pixel over the other, from pixel 0,0, so you do not get this initial filtering. Once you move it around, sure it can get a hit, but you can expect that.

So actually, as much as this is math and it is correct from those optics, I would say that it can throw people off, even me ;-) I looked at this with a bit of WTF! then it slowly dawned on me, that is why I moved it a half pixel over, but frankly that is what I don't like, that the implementation of this has a potential for confusion, even though the benefits are plenty! This may be stupid to talk this way to all the math purists ;-), but the software could surely detect this scenario, and warn the user that sampling will happen in this merge, or just move it that 1/2 pixel over. Yes Yes I know, this is heresy. Again, users/artist are just expecting certain things, and sometimes you need to bend the rules, but it will still work correctly.

Cheers

User avatar
Chad
Fusionator
Posts: 1381
Joined: Fri Aug 08, 2014 1:11 pm
Been thanked: 8 times

Re: Sampling question on merge

#10

Post by Chad » Sat Dec 19, 2015 11:11 am

But Fusion does it fine most of the time. It does no filtering in 95% of the cases where there is a resolution mismatch, because 97.5% of the time, your images have an even number of rows and columns. No broadcast format has ever had odd numbers, I've never seen a non-machine-vision camera shoot odd pixels, even when shooting RAW, and many file formats won't even LET you have odd numbers.

Could it detect the inputs being an odd number of pixels different? Sure, but it could just as easily do point sampling. The issue will be the same, if the inputs have sizes that vary over time, you'll get jitter. So in no case will users get what they expect under all circumstances.

If you wanted to detect the input mismatch in X and Y and offset from center +.5 pixels, you could do that with an intool script. Assuming you didn't care about proxies, just use OriginalWidth and OriginalHeight and offset by (1+OriginalWidth)/(OriginalWidth*2) if math.fmod(abs(Foreground.OriginalWidth-Background.OriginalWidth), 2) > .5.

User avatar
razzy
Fusioneer
Posts: 143
Joined: Sun Aug 10, 2014 3:12 pm
Location: Vancouver, British Columbia, Canada

Re: Sampling question on merge

#11

Post by razzy » Sat Dec 19, 2015 11:30 am

Chad wrote:But Fusion does it fine most of the time. It does no filtering in 95% of the cases where there is a resolution mismatch, because 97.5% of the time, your images have an even number of rows and columns. No broadcast format has ever had odd numbers, I've never seen a non-machine-vision camera shoot odd pixels, even when shooting RAW, and many file formats won't even LET you have odd numbers.

Could it detect the inputs being an odd number of pixels different? Sure, but it could just as easily do point sampling. The issue will be the same, if the inputs have sizes that vary over time, you'll get jitter. So in no case will users get what they expect under all circumstances.

If you wanted to detect the input mismatch in X and Y and offset from center +.5 pixels, you could do that with an intool script. Assuming you didn't care about proxies, just use OriginalWidth and OriginalHeight and offset by (1+OriginalWidth)/(OriginalWidth*2) if math.fmod(abs(Foreground.OriginalWidth-Background.OriginalWidth), 2) > .5.
Hey Chad,
regarding image resolution, yeah you are totally correct, when filming the odds are in a hi percentile for sure, however, when I work and other work, we take images from many sources, and the odds drop off. I use images for elements, textures, like I am now, and so the chances will rise. However, I agree with your point in principal!

Hmm, jitter, yeah.... I don't think this is what I was really talking about. I am not talking about a an issue of size change over time. This would be a result for sure if this scenario arose though. Point taken, but I think this would be more rare than what I am talking about ;-)

ok.. well this is great, your understanding of the expressions required is well known and appreciated! Perhaps with some effort I could come to the same conclusion, but we have to remember that what I am driving at is this is not an obvious symptom of this process, I bet many people would be wondering WTF if they see this! Not everyone will have the time (this would be me!) or the knowledge perhaps to think about a scripting solution to these issues. Now that you have pointed it out, well cool. I think I will look into this for a solution, but why should I have to think about this. I would like the developers to think about this, at the very least have a warning that the image resolution are odd to each other and sampling will happen. That would be a huge thing for people, so they can say oh ok, I need to do this to work around this issue. No need to get into any fancy scripting! I guess that is to much to ask, because overall most of us over time will see this and figure it out, or not even notice :-)

Cool, good feedback!

cheers

User avatar
xmare
Fusioneer
Posts: 82
Joined: Thu Aug 07, 2014 3:25 pm
Contact:

Re: Sampling question on merge

#12

Post by xmare » Sat Dec 19, 2015 5:08 pm

well, at least You can fix that /work that around quite easily...
while You can't so easily work with fact that merges do not coa-sth-sth, ;) so You do get filtering while stabilizing / destabilizing..
yeah, flame on :)
merry christmass

User avatar
SecondMan
Site Admin
Posts: 3366
Joined: Thu Jul 31, 2014 5:31 pm
Answers: 2
Location: Vancouver, Canada
Been thanked: 65 times
Contact:

Re: Sampling question on merge

#13

Post by SecondMan » Sat Dec 19, 2015 9:44 pm

Merges don't what? :P

User avatar
theotheo
Fusionista
Posts: 300
Joined: Thu Aug 07, 2014 8:35 am
Been thanked: 10 times

Re: Sampling question on merge

#14

Post by theotheo » Sun Dec 20, 2015 3:52 am

stutter?

jirka
Fusioneer
Posts: 60
Joined: Mon Sep 15, 2014 3:24 am
Location: Prague, Czech Republic

Re: Sampling question on merge

#15

Post by jirka » Sun Dec 20, 2015 11:45 am

Merges do not concatenate cornerpin, maybe?