This really needs testing with a variety of combinations of Vegas versions and Quicktime versions to establish what exactly is going on and what changed (if anything) and when, before making the sweeping statement in your last paragraph. Plus there are the variables of graphics card settings, preview method etc. that can easily mislead.

This stuff just goes to prove that to be sure of correct delivery one has to verify levels on one's own gear/software/workflow from start to finish.

p.s. You'll get told off for incorrect usage of the term sRGB, instead of "Studio RGB" or "TV levels" etc.. Then you'll get told off for incorrect usage of the term "expanding levels", instead of referring to what codec expects what levels.... but we know what you mean. Happy weekend!

p.p.s. musicvid, got a link to the V8 vs V10 .mov levels discussion (which has slipped my mind) by any chance?

Nick? Is this the link?

Cheers

Grazie

Here is my confusion over the Clamp to YT.

Cheers

Grazie

Hopefully not!

Quite . . . .

G

OK, run tests on 3 machines.

PC #1:
V10 and V11 show levels as different i.e input = ComputerRGB, Output = StudioRGB. Machine runs Win7 64

PC#2:
V9 shows levels as the same i.e. input = ComputerRGB, Ouput=ComputerRGB.
V10 shows levels as different i.e. input = ComputerRGB, Ouput = StudioRGB.
Machine runs WinXP 32

PC#3
Gets the same results as PC#2. Machine runs Win7 64.

Every still camera that I've used to record video records Computer RGB but my tests are limited to the 5D MKII and the Sony RX100.

Bob.

Nick, I found it by searching the word "crappy" (you've only used it three times in forum history) ;?)

http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=748477

It's fairly early in the thread, then separated by a discussion about audio, continues about a third of the way down.

It was actually a discussion of the different MP4 decoders in Vegas 8 and 10, and may be the key to why Laurence's examples are giving different results in different Vegas versions.

My impression is still that Canon and other DSLRs shoot 0-255 in full daylight. So while I understand the observations, my conclusion is different than what was proposed. Also Quicktime versions undoubtedly play a role, since I am stuck with QT 7.6 on Vegas Pro 8.

Ok, Cineform MOVs don't get expanded. Here's a test I just did. I took a Nikon D5100 clip that was showing in Vegas 12 as having levels between 0-255. I did no other changes to this clip aside from converting it to Cineform. I converted to Cineform in both AVI and MOV formats. I loaded these converted clips onto a Vegas timeline. What I ended up with was video in the 16-135 range for both the Cineform MOV and AVI.

I would love it if someone confirmed this with some Canon footage as well. If my DSLR is displaying in 0-255 range in it's native format, why is it getting scaled to the 16-235 range when I convert it to either an AVI or MOV Cineform intermediate? My theory is that it was 16-235 all along and Vegas 12 was simply displaying it incorrectly.

I would love it if some of you could replicate and maybe confirm this.

Laurence, that's one of the "features" of Cineform, to the best of my understanding.
I think I noticed this a while back, not just with GoPro Cineform.

But Cineform intermediate conversion is only rescaling my Nikon DSLR MOV video. It does nothing to other formats.

My GH3 does both AVCHD MTS and Quicktime MOV formats. If I shoot video with AVCHD, it shows up on a Vegas timeline as being in the 16-235 range. If I shoot the same scene with the same settings otherwise in MOV, it shows up on a Vegas timeline as being in the 0-255 range.

I am doing all sorts of tests and getting inconsistent results. For instance if I convert Nikon DSLR MOV footage to Cineform in either AVI or MOV format, the native Nikon MOV will show up in Vegas 12 as being in the 0-255 range but the converted Cineform MOV or AVI will be displayed as being in the 16-235 range. If I do the same test however converting footage from my GH3 to Cineform from either MTS or MOV to either MOV or AVI, the Cineform Intermediate levels will be unchanged. These will be 16-235 levels if the GH3 footage was shot in AVCHD or 0-255 range if the GH3 was shooting MOV.

What this tells me is that neither Vegas 12 nor Cineform are consistent in how they treat different camera MOV formats. Sometimes Cineform rescales from cRGB to sRGB, sometimes it doesn't. Sometimes Vegas stretches MOV footage from sRGB to cRGB. Sometimes it doesn't. It depends upon the camera.

What I suspect is that both my Nikon D5100 and my Panasonic GH3 are shooting their MOV footage in the 16-235 range but that it is getting expanded out to 0-255 by Vegas 12. The MOV footage from the Nikon is getting corrected when it is either converted to Cineform Intermediate or stabilized by Mercalli SAL. The GH3 MOV footage is getting corrected when it is stabilized by Mercalli SAL but not when it is converted to an intermediate by Cineform.

When the levels are different programs, one of them is making a mistake. Mercalli SAL and Vegas are interpreting the levels differently on MOV clips from my Nikon and Panasonic cameras. In the case of the Nikon, Cineform is agreeing with Mercalli. In the case of my GH3, Cineform is agreeing with Vegas. There are mistakes being made here for sure. The question is, which programs are making the mistakes in which instances?

In Vegas Pro 8


The levels and gamma are identical. The discussion I linked may suggest the difference between versions lies in the MP4 decoder, not MOV?

This is an example how an 8 bit video signal looks like when being mapped from 16-235 to 0-255. Watch the banding caused by the mapping.

mapped
.

Down below same signal but without RGB mapping.

unmapped

This kind of banding you see in the upper histogram is often an easy proof whether a 16-235 to 0-255 mapping took place.

The input was a .mov clip taken from the Canon 5D MKII. Vegas Pro 12 does not apply RGB mapping to it. I think it was version 11 of Vegas Pro which introduced MOV H.264 decoding by its own Sony AVC decoder. In earlier versions such clips needed to go their way through the Quicktime decoder which applied a mapping.

> The discussion I link may suggest the difference between versions lies in the MP4 decoder, not MOV?

Yesterday in V12 I changed the mp4 decoder because I was suspecting this as well. Mp4 playback was identical.

Marco, how do you get vegas to show the RGB histogram like that?

Laurence, set the view as shown below.

http://dl.dropboxusercontent.com/u/20488019/histogram.jpg

Mike

Thanks Mike.

OK check this out! I am even more sure I'm right now about Vegas getting the MOV levels wrong.

This is a frame from a clip of my son playing guitar in his room. Notice the bright sunlight coming in through the window on the left. I'm using this to test the high edge of the brightness range:

This is the frame as it looks with the original MOV clip (GH3) on the Vegas 12 timeline:



This is the same frame with a cRGB to sRGB correction filter:



This is the same frame after being stabilized in Mercalli SAL v3 as an mp4 clip. It is zoomed in a little more because of the stabilization:



Here was my thinking in doing this experiment. If I am right and the camera is recording sRGB levels but Vegas is stretching them out to cRGB, then a bright window should probably go a little over the 235 mark and be clipped after the stretching. This brightness would be clipped and not recovered when you scaled the levels to sRGB range.

If stabilizing the clip through Mercalli was correcting this mistake however, I would expect that there would likely be a touch of brights slightly over the 235 mark that would still be there when the stabilized clip was brought into a Vegas timeline.

As you can see, this is exactly what is happening. The original MOV file is clipped at 255, and scaled down to sRGB levels, you can see this clipping at exactly the 235 mark, but the Mercalli stabilized file goes slightly over this and is not clipped at the bright window.

It looks very certain to me now that Vegas is artificially stretching the brightness range from sRGB to cRGB levels. How could my camera be recording at cRGB levels and have brightness detail above 255 that could be recovered by Mercalli? It has to be recording in the sRGB range for there to be data in this range. I am definitely right on this. Think about it.

Laurence, could you show the histogram view of the original clip while the histogram is set to "Luminance/R/G/B"?

Also - when you right-click the clip in the timeline and select "properties/general", in the lower end of the window below "Plug-in": What is shown for the format?

Marco, I did a Luminence/R/G/B check and expanded it across my two monitors but still couldn't see any banding like I did in your example. I'm not sure how to capture a picture across two monitors, but even if I did, there is no sign of the banding anyway.

It is playing with the compoundplug.dll. Yesterday I temporarily moved this plug so that it would play back with something else (I don't remember what it defaulted to, but it did change the name here) and it looked exactly the same.

This should hit the ball home:

Here is a frame from the original MOV:



Here is the Mercalli stabilized version with sRGB to cRGB correction in order to match the levels range. Notice that the histograms are identical:



Now here is the Mercalli stabilized version without the level correction. Notice that there was bright detail there being clipped! That bright detail wouldn't be there if my camera was actually recording at cRGB levels. No, it is recording at sRGB levels, and it just looks like cRGB because Vegas is stretching it! I am absolutely positive now!

"It is playing with the compoundplug.dll"

Sure, but which format is used? Sony AVC or Quicktime?

But there is no further details. It's just a little more swing in the highlight.