Why is 32 bit darker than 8 bit?

Sebaz wrote on 12/12/2008, 6:02 PM
I never understood this, but I'm not an expert in that sort of thing. Why adding a bigger color palette means that the gamma changes to much darker. The 2.22 setting is not as dark as 1, but still much darker than when working in 8-bit. Tried entering a higher number in that field and it lets me up to 4.

Of course as everybody noticed editing in 32 bit is sluggish as hell, however, is there any advantage in setting the project to 32 bit right before rendering to Mpeg 2, whether it's for DVD or BD, or AVC for BD? Will it look better?
One thing I'm not sure I understand is why Vegas makes you choose between 8 or 32 bit, when most NLEs have either 8 or 10 bit?

Comments

Sebaz wrote on 12/12/2008, 7:55 PM
What a mess! I think I'll just keep rendering in 8 bit. Much easier and faster than reading those two threads completely.
Sebaz wrote on 12/13/2008, 6:19 AM
I must say though, I don't know if this is a bug or not, perhaps that's the way it's supposed to be, but Sony should have put in there a gamma setting that gives you the same gamma as the original in 8 bit. When I edit footage in 8 bit it looks just as it looks when I connect the camera to my TV set, but when I switch to 32 bit, even in 2.22 or 4, it still looks darker, so it's useless to me. Things that were visible in shadows are now in a mesh of black.

Now, if anybody can answer me this, is there any advantage into setting the project to 32 bit after done with the editing and render it to AVC or MPEG 2 for Blu-Ray? I will do some short tests myself later, but I would like to know if anybody else tried this and what were your results.
TheHappyFriar wrote on 12/13/2008, 6:26 AM
I did some tests with generated media & some FX and found that 32-bit helps a LOT with gradients. I did some text that was masked with text, lens flares & light rays. Even at DV resolution/quality, rendering with 32-bit had a VERY VISIBLE quality improvement. In 32-bit you could see shadow details on the words that wearn't even there in 8-bit, the gradients from the color to black were soooooo much smoother in 32-bit.

The BEST part? I could do an initial render to 32-bit uncompressed (not 32-bit alpha channel video, but 32-bit per pixel with alpha channel too! There WAS a MAJOR size difference: a 30 SD 8-bit rendered file is ~5gb, a 32-bit rendered file is ~25gb)... THEN (this is the sweet part) you can do a normal 8-bit render to your final encoding format (DV AVI, mpeg-2, wmv, etc) and it looks BETTER then if you just render to 8-bit from the get go.

Yeah, it was darker but I didn't mind for what I was doing, even if I made it darker in 8-bit it didn't look as good as the 32-bit.
Sebaz wrote on 12/13/2008, 6:37 AM
So if I apply the Convert Computer RGB to Studio RGB filter preset in Levels in 32 bit to give it more or less the same gamma as 8 bit (I read that in the forums linked above), and render to MPEG2 for BD, you're saying that I should see a difference, even though MPEG2 will be just 8 bit?
TheHappyFriar wrote on 12/13/2008, 7:59 AM
I don't think so. I believe the only FX/etc. that support 32-bit are the ones with the little blue square next to their name. The broadcast colors/color corrector don't. But what you should be able to do (i just gave it a whirl & it seems to work) is to render out your video in 32-bit (will be darker) & then, in a new project, load up that AVI/HD file (whatever you're using), have that project @ 8-bit & apply the broadcast colors/color corrector to the 32-bit rendered file. That kept the nice detail I got with the 32-bit rendered source file but brightened it up real nice. Gradients still look smoother then if I dealt 100% with 80bit, still the extra detail in the shadows, but brighter.
GlennChan wrote on 12/13/2008, 12:07 PM
Going to the 32-bit mode changes two things:
1- The levels are different. This might lead you to think that there is a huge quality difference, but that's not really the case... what's happening is that there are conversions occurring between studio RGB and computer RGB levels.

2- The compositing gamma setting in project properties may or may not have change. If it is 2.222, then this will affect what the FX do.

http://www.glennchan.info/articles/vegas/linlight/linlight.htm

I don't think there is any reason to render out 32-bit uncompressed files.
farss wrote on 12/13/2008, 12:28 PM
I just tried rendering a grad to both a 32bpc AVI and 8bpc AVI.
Bringing the results back into Vegas something is seriously messed up looking on the scopes. The original linear grad became a log grad i.e. the contrast is increased. The same outcome could have been achieved using a curve in 8 bit.
You will see more shadow detail and probably less banding. I suspect that's more to do with the poor image rendition of LCD displays than any extra detail in the actual image.
The one and only place I can see 32bfp processing being of much use is with 10bit sources. Vegas does appear to read and write these correctly via the 10bit variant of the Sony YUV codec. That codec also uses way less disk space than uncompressed
Regardless, you've got to be darned careful what you're doing or you can make a real hash of your images. If things start looking dramatically better or different you've most likely got something wrong.

Bob.
TheHappyFriar wrote on 12/13/2008, 2:04 PM
I suspect that's more to do with the poor image rendition of LCD displays than any extra detail in the actual image.

My banding on the 8-bit was noticeable worse then the 32-bit. I can even get a screen shot or two if you want to see. I ran it several times.
farss wrote on 12/13/2008, 3:17 PM
"My banding on the 8-bit was noticeable worse then the 32-bit."

I'm not questioning that. Try this simple test.
Open a 8bit project and drop the B&W grad onto the T/L. See what that looks like on the waveform monitor. It should be a straight diagonal line.

Now switch to 32bit 2.22 gamma. Now render that to a 32bit AVI and bring that back into Vegas. Check it again with the waveform monitor. I see a log curve. It should be a straight line.
Before making an analysis of the banding outcomes you need to get the gamma corrected otherwise your comparing apples to oranges.

With that kind of transform happening I suspect you'd see less banding on a LCD regardless. My panels are only 6 bit so I have zero faith in what I see on them regarding banding.

I can't find anything else that'll open the 32bpc AVI file either which is not helping my analysis. Both Pro and AE cannot open the file. If I include an audio stream that's all Ppro can read.

I'm not saying you haven't found some magic soup. Just advising caution. Not long after V8 came out I did a HDV project in 32bit. After legalising the output the results looked more Bollywood than Bollywood and my Indian clients were kind of impressed. Looking back on it though I realised this is not something I'd normally want to do at all and could have achieved the same outcome without the long render times.

Bob.
TheHappyFriar wrote on 12/13/2008, 5:17 PM
Now switch to 32bit 2.22 gamma. Now render that to a 32bit AVI and bring that back into Vegas. Check it again with the waveform monitor. I see a log curve. It should be a straight line.

I do see a curve when I render the gamma to 2.22. If I do 1 it's a straight line.

Change the project to 8-bit & the 32-bit file with the curve still has the curve. I added a color corrector filter & was able to make the waveform straight again.

From some experiments, changing the gamma changes the curve log wise. 1 = linear (like 2.22 in 8-bit), > 1 = curve one way, < 1 = other way.

Infact... I just added the color corrector plugin, and this is specifically what changing the gamma does: it changes the curve. So, it's doing what it should be doing with the gamma, adding/subtracting it. I can take a straight gradient, add a gamma of 1.944 via CC & it's equal to the gamma of the 32-bit file if the project settings are gamma = 4.

Why, I don't know, but I'd imagine with 32-bit you're bought to get darker by default (you now have 32 bits of black instead of 8, that's 4,294,967,296 shades vs 256). The gamma setting must be there to brighten it up project wise so it's not all to dark.
farss wrote on 12/13/2008, 7:05 PM
"Why, I don't know, ...."

Your guess is as good as mine :)
Thanks to Glenn I think I understand what it does but I'm left clueless as to why.
In my other NLE everything seems to stay as it should.

Bob.
GlennChan wrote on 12/13/2008, 8:23 PM
re: files coming back differently if rendered to the 32-bit codec with compositing gamma 2.222
Uh... it's a bug?

---
What the compositing gamma setting in project properties does:
If it is 2.222, then it will convert the signal to the linear light domain before sending it to FX, and then convert it back to its original form after FX. The two operations cancel each other out. The math functions would be:
f(x) = x^(1/0.45)
f(x) = x^(0.45)
Or something close to that.

I can take a straight gradient, add a gamma of 1.944 via CC & it's equal to the gamma of the 32-bit file if the project settings are gamma = 4.
This is a very minor point, but the CC's 'gamma' control will produce different results than the Levels FX if you are working with color images. Much like how saturation yields different results between the CC, HSL adjust, and black&white filters.

A gamma setting of 2.222 or 0.45 in the Levels filter would be appropriate for manually converting/unconverting between linear light and gamma corrected... I think this should be the right number (not 1.944). But I could be wrong (?) since I didn't test this particular situation, since it seems to me like it's definitely a bug.