Comments

farss wrote on 9/24/2012, 3:21 AM
My understanding and experience is that Subtract is exactly that, except of course you cannot have negative light so the smallest possible result is zero.

e.g. White minus mid grey is mid grey. Mid grey minus white is black.

Difference is comumutative, regardless of the order the result is alwaysthe same. e.g. the difference between mid grey and white is mid grey.

I've used Difference and Difference Squared to quickly match an editied program back to the source clips.

"Is "Difference" the same in Vegas as in Photoshop?"

Don't know and there could be lots of complications as some systems I think allow negative light and greater than 100% white.

Bob.


Grazie wrote on 9/24/2012, 3:57 AM
Bob has gone to the "core" of what these features represent mathematically. I hope I've added a bit more flesh to your understanding, and a plea to SCS.

OK, first off great set of questions!

What's the difference between "Subtract" and "Difference" compositing modes.
This from the Online Help:

Subtract - "Subtracts the overlay color values from the background."

Difference - "Compares the overlay and background pixel by pixel and subtracts the darker color value from the lighter color to generate a new color value."

And there is the difference: Difference produces a "new", tertiary colour, Subtract doesn't, it just removes the comparison.

OK, I've put together a string of hopefully illustratory clips to demonstrate these 2 features.

Here is the Original Clip

Here is the Original Clip PLUS Bump Map FX-ing so you can see how I generated a set of comparables

And finally here are two examples where you compare and see the difference between the two composting functions happen:

This for Subtract.

This for Difference.

Moving on . . . . .

Which one is mathematically perfect wrt commutative property? I don't understand the question? Maybe somebody else would care to jump in?

Why do they show different results? As per the info I pasted here from Sony Online Manual and brought together by me: Subtract removes dissimilar colours, but Difference creates that other, "new" colour.

Is "Difference" the same in Vegas as in Photoshop?Well, I would really hope so(!), otherwise SCS would be open to a whole load of emails trying to understand why not? But there again working in the Video field maybe there are other factors at play. Again, somebody might like to jump in and make a few remarks?

You've asked great questions. However, and what still is hanging for me is "Why and where would I use these powerful Compositing options?"

Over the years I've kinda answered much of this for myself, and Bob has illustrated one of his own. However, more and explicit examples would greatly help the cause!

Often I've asked SCS for tutorials on this exact same issue, not just explaining "How" you would execute the functions, but rather "Why" you would. I've kinda picked-up/learnt that at some point SCS needs to make some assumptions that people coming to their software have some working vocabulary/understanding of these, what are essentially Graphics/Photographic manipulations and enhancements, for themselves. For SCS to venture into this Compositing tutorial area of activity SCS would need the input from somebody who uses these Compo features, in Vegas and PS and Corel and so on, on a daily basis.

Good questions,

Grazie

farss wrote on 9/24/2012, 6:00 AM
"I don't understand the question? Maybe somebody else would care to jump in?"

You actually answered this ( I must admit I had to Google "commutative") when you quoted this:

"Compares the overlay and background pixel by pixel and subtracts the darker color value from the lighter color to generate a new color value."

In other words it always commutates so that the darker color is subtracted from the lighter. Doing this is in line with the true meaning of "difference".

Imagine two building of different height If you were asked "what is the difference in their height" you would always subtract the height of the shorter building from the taller. The answer will always be a scalar value.

Now if you had three buildings of different heights and were asked the same question normally your answer would include words such as "taller" and "shorter" and those words are a way of saying "positive" and "negative" because you (probably without even thinking about it) are doing a subtraction and the answer you give is a vector, not a scalar, it has direction; up, down, left, right, north, south, taller, shorter, younger, older.

Hope this helps a bit. Mathematics isn't scary, we use the logic of it without even thinking about it everyday.

Bob.

paul_w wrote on 9/24/2012, 7:17 AM
And just another point of view / way of saying it:

Subtract: will clamp to 0 if the result tries to go negative (which it cannot of course) 0 - 255 per pixel only in an 8 bit system.

Difference: as Bob describes, the answer is always positive. Its the absolute value (no sign). In c++ programming, we use the command 'abs'. So for example:

For subtract:
100 - 200 = -100 therefor it clamps to 0. = black

for difference:
abs of 100 - 200 = 100. = a viewable pixel

Paul.
musicvid10 wrote on 9/24/2012, 7:37 AM
Much clearer now, and I can see that I was not really asking for a commutative solution. "Negative gray" is an extraneous solution (if you drive a car backwards, you are not going "negative distance ;?)

What I found out from reading Gary Rebholz and others is that "Subtract" in Vegas is B-A where B>=A (works from the lower track up!) so that 15-16 is 0, not -1. All making sense now, and exactly what I wanted.

"Difference" in Vegas is actually a pixel-by-pixel test that subtracts the lighter pixel from the darker pixel, so there is no track hierarchy, and is another way of saying "the absolute value of the difference". Probably much better for creative compositing (keeps more of the image data), but not for a mathematical comparison of two tracks, as I had set out to do.

Another interesting tidbit -- Pre/Post toggle applies the effect only to the affected track, or to all composited tracks, respectively. Didn't know that. But important for my tests.

Grazie, your clips are a gem (lovely stairwell too)!
And if you reversed the track order of "Subtract" we would have seen a white blob instead of black I think.

My sincere thanks to Bob and Grazie (even if y'all do talk a bit funny) . . .

https://www.custcenter.com/app/answers/detail/a_id/470/~/compositing-in-vegas-pro
http://www.sonycreativesoftware.com/understanding_video_compositing
http://www.sonycreativesoftware.com/video_effects_pre_post_toggle_in_vegas
Chienworks wrote on 9/24/2012, 7:59 AM
"if you drive a car backwards, you are not going "negative distance ;?"

Actually you are, since distance is a vector. Displacement is not, however, so driving backwards still results in a positive displacement. Well, unless you go backwards in a complete circle and return to your starting point. In that case the distance you have driven is the circumference of the circle, with a negative value of course, while your displacement is zero.
Chienworks wrote on 9/24/2012, 8:03 AM
"but not for a mathematical comparison of two tracks"

I find difference to be exactly the right tool for comparing two tracks. Wherever the result is black the tracks are identical. Wherever the result is above black, there is a difference. With subtract you would lose the information where the upper track is brighter than the lower one, and you therefore wouldn't know there was a difference. Subtract will only show you where the upper track is darker than the lower one and leaves you oblivious to the opposite condition.

What i often do when two tracks are very similar is use the difference mode and then add levels to the output to make the brightest dark, dark grey result white. This highlights anywhere that the tracks are differences as bright white sparkles that are easy to track.
musicvid10 wrote on 9/24/2012, 8:26 AM
Interesting thought Kelly, and I'll ask an aerospace engineer when I meet with her tomorrow. B-A (not |B-A|) gives the best graphical representation of the differences at this point, but it's not too late to change it.
Stay tuned.
musicvid10 wrote on 9/24/2012, 9:47 AM
Better to view in a new browser window because of moire in the forum images.

Here is the Control print on Track A , an Uncompressed 4:4:4 8 bit RGB render:



Here is the Variable on Track B (in this case Cineform 4:2:2):



Here is the "Subtract" result (B-A). The graphical representation works because cyan is the absence of red. The colors would be reversed if we had done A-B:



Here is the "Difference" result (|B-A|). The graphical representation does not give us all the information because all differences show as positive values of red. Means the R/C vectors would extend out only one direction.



Although it wouldn't be true in all situations, for the purposes of these tests of chroma subsampling, Subtract is going to give me the most useful and visually accurate information after we take away all the equal data values.
Tim20 wrote on 9/24/2012, 4:37 PM
Not sure about Photo Shop but I use After Effects alot which is probably the same as Phtoshop and not all terms cross over the same. I think diff and sub do but Source Alpha is likely Normal in AE. When masking the terms are definetly different.

I find Vegas to be brutally painfull for even the simplest compositing. I never know if I am doing something wrong or if Vegas is acting up. Probably a little of both :) I also don't find much use for subtract and difference other than to add artistic value, but I am sure you guys might disagree.

Here is a simple little composisting I shot and did over the weekend. Ok not really simple.

https://dl.dropbox.com/u/108085497/Little%20shot.wmv
musicvid10 wrote on 9/25/2012, 11:20 PM
"I find difference to be exactly the right tool for comparing two tracks. With subtract you would lose the information where the upper track is brighter than the lower one,"

This from a Lockheed aerospace engineer:
"In my error control work, the rule is not to include non-existent data in the results. In this case, anything below zero. It only exaggerates the errors. In my work, I would be quite happy with (B-A), and I would have some questions about (|B-A|)."

Subtract in Vegas seems to be B-A, and Difference is |B-A|.



farss wrote on 9/26/2012, 6:35 AM
"Subtract in Vegas seems to be B-A, and Difference is |B-A|."

That's my understanding too.

As for the Lockhead aerospace engineer, he didn't do the original work on Hubble by any chance did he?
I wonder how he coped with 10.000" +/- 0.010", were all the components that were too short passed as within tolerance?

Seriously, the problem with video in this case is anything below zero is real data, a real error. If you discard those values then one could have two frames that are totally different but your results would show zero error. One way around that would be to normalise the values so that mid grey is no error. I see this done from time to time when looking at chroma subsampling error results.

I am however really only thinking about the luma component, what happens with chroma is a different matter and my head hurts thinking about that because they are vector values.....I think.

Bob.

[edit] thinking about the answer from the Lockheed gent some more, this could be a case of the right answer to the wrong question. Certainly in some statistical QA analysis one does exclude outliers less they skew the result but I don't think the same reasoning would apply in this case. Here the problem is that the measuring system itself cannot cope with negative values.
musicvid10 wrote on 9/26/2012, 8:08 AM
"She" is too young to have worked on Hubble. I think her larger point was that we choose a protocol and stick with it, because any error analysis model is going to have, well . . . errors.

I did explain the problem thoroughly and used graphic examples, so she understood the zero boundary, which is actually quite common in conventional physics.

An example: PEMDAS is full of holes, but it's adoption is universal because conventional math demands a common language.
;?)
Tim20 wrote on 9/26/2012, 8:37 AM
You sure that tolerance wasn't 0.001 +/- 0.0001 :) +/- 0.010 is something a entry level machinist should be expected to do.

I spent 7 yrs as a program manager accepting an LM design. When it comes to their engineering it was always trust but verify. Don't tell her I said that.

Ok it has already been said but this is the desctiprtion from Adobe:

Subtract:Subtracts the source color from the underlying color. If the source color is black, the result color is the underlying color. Result color values can be less than 0 in 32-bpc projects.

Difference: For each color channel, subtracts the darker of the input values from the lighter. Painting with white inverts the backdrop color; painting with black produces no change.

If you have two layers with an identical visual element that you want to align, place one layer on top of the other and set the blending mode of the top layer to Difference. Then, you can move one layer or the other until the pixels of the visual element that you want to line up are all black—meaning that the differences between the pixels are zero and therefore the elements are stacked exactly on top of one another.

The exact algorithms are buried in one of their ISO manuals. To boring for me to go look.
musicvid10 wrote on 9/26/2012, 10:07 AM
Thanks to all for your advice and responses. On the advice of my local rocket scientist, I'm going to proceed with Subtract in Vegas as a control variable for the first round of tests.

I "may" run it again later with Difference to get a second comparison, that I predict will not influence the hierarchy of the results. I don't know if Subtract is the same in Premiere as in Vegas (doesn't sound like it).
farss wrote on 9/26/2012, 10:31 AM
From Tim's post,from Adobe:

"Result color values can be less than 0 in 32-bpc projects."

I think that works the same in Vegas. V12 also throws LAB color into the mix and it supports an even wider range "impossible" outcomes.

Like Tim I use "difference" as a forensic tool, an "is it exactly the same" comparison. By how much it is different isn't a concern, I just want no difference. For that difference wins hands down compared to subtract

If the intent is to derive by how much two images are different, I'm out of here quick smart. That throws us into the realm of human perception where maths doesn't provide answers that are meaningful in the real world at all easily.

Bob.
musicvid10 wrote on 9/26/2012, 11:03 AM
"Like Tim I use "difference" as a forensic tool, an "is it exactly the same" comparison. By how much it is different isn't a concern, I just want no difference. For that difference wins hands down compared to subtract"

I have come to agree with the logic of that statement. The doubled error in the thin lines in the fourth image above (compared with the third image) makes it easier to see, and I think this may be what Kelly was pointing out, too. I guess I would call it a form of "error magnification". Problem is, doing this also turns the cyan bias to red. Net result is that some of the visible data is also masked.

There may be some order of filters in Vegas that would give us "Difference with bias correction," and that might be more useful than just Subtract or Difference alone. I'll look into it, time permitting.

Although visually more representative, I'm unconvinced that Subtract quantifies the "differences" exactly, either. I suspect it does not ( possibly for reasons already discussed). But it would probably take a rocket scientist to tell us by how much . . .
;?)
Tim20 wrote on 9/26/2012, 11:25 AM
Ok here is the link to the adnauseum algorithms:

http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/pdf_reference_1-7.pdf

See section 7 and especially 7.2.4
Chienworks wrote on 9/26/2012, 11:56 AM
"I have come to agree with the logic of that statement. The doubled error in the thin lines in the fourth image above (compared with the third image) makes it easier to see, and I think this may be what Kelly was pointing out, too. I guess I would call it a form of "error magnification". Problem is, doing this also turns the cyan bias to red. Net result is that some of the visible data is also masked."

True, with difference you don't necessarily see what the error is, but you do always see that there is an error. With subtract you can see *some* of the errors, but you probably won't see about half of them at all. When the result of the subtraction is negative you just get black, which looks like no difference.

In order for subtract to work completely, you really need to perform the subtraction both ways: A - B, and B - A, then add those two results together. If you don't do both, you'll miss a lot of errors.
musicvid10 wrote on 9/26/2012, 12:46 PM
Kelly,
Do you have time to take my native images from Dropbox and show us how you would do that? I've tried a couple of things, but just won't have time until the end of Oct. to try anything in depth.
Chienworks wrote on 9/26/2012, 12:59 PM
I'm sure i can over the weekend. I'm hitting a huge deadline here at work myself on Friday.
farss wrote on 9/26/2012, 5:04 PM
"Problem is, doing this also turns the cyan bias to red. Net result is that some of the visible data is also masked."

Yes, absolutely. This is because each of the R,G,B equations are individually commutated. That means two different differences can give the same answer and that is also wrong.

The only correct way to do the comparison is to allow negative results. The usual QA statistical tools are going to give very flawed results without that no matter if you use difference or subtract.

Bob.
musicvid10 wrote on 9/26/2012, 6:55 PM
One way I could imagine doing what Kelly is wanting is to reduce the bit depth to 4 bpc, and lifting the levels by 50%, allowing the previously negative values to live in the lower half of the visible range.

Of course this introduces its own collateral set of losses, which might be worse than doing nothing. Interesting discussion.