32 bit floating point advantages

megabit wrote on 9/12/2007, 1:43 AM
Yeah, I know it's been asked and (sort of) answered many times, but somehow the only thing that is quite obvious to me (and to my eyes) is greater colour resolution (e.g. less banding). Even more noticeable is the increased range (i.e. lows are darker, highs are brighter even to the point of loosing detail); however I am unclear on how to use this feature to my advantage? I mean, should I change the way of shooting with the 32bit video Vegas in mind (e.g. avoid contrast), or what? Please explain in laymen terms what the practical impact of the 32bit processing on the HDV workflow is.

AMD TR 2990WX CPU | MSI X399 CARBON AC | 64GB RAM@XMP2933  | 2x RTX 2080Ti GPU | 4x 3TB WD Black RAID0 media drive | 3x 1TB NVMe RAID0 cache drive | SSD SATA system drive | AX1600i PSU | Decklink 12G Extreme | Samsung UHD reference monitor (calibrated)

Comments

DJPadre wrote on 9/12/2007, 5:18 AM
"Even more noticeable is the increased range (i.e. lows are darker, highs are brighter even to the point of loosing detail); "

how is this a benefit? Sorry, but as soon as saw DSEs 32bit render with no addition cc, i thought,
"it changes the colour"

with this came a myriad of other thoughts in how one can work to compensate for these "boosts" in turn, it seems the only way to work with 32bit and get ACCURATE results would be to set your camera up so as to not reach a peak (highs or lows) in the first place
TO me, this makes no sense as your cameras exposure settings are set to offer an optimal image, not a preproduction image
As an example, you could prolly cosnider this type of shooting along the lines of DSLR RAW files vs jps.. where RAW automatically assumes that Post Production will occur on the image being taken.
I would say that 32bit, in this case would be close to that mentality.

As an example, if you were to capture HDV stright into OnLocation or HDVRack(same shit differnt smell) you might have accuracy in cam at time of capture.. this footage could well be perfect for your applicaiton... now consider that it might be a chromakeyed shot with your keylight setting the luminance of teh background PERFECTLY..

Now you want to arun a composite and key your character into their new background.. run 32bit and what happens to your colour?

It seems that 32bit is designed to assist in the repair and rebuild of colour, not as a means for general workflow.
Dont get me wrong, 32bit is a great option if you have alot of footage which requires gamma/luma and colour correction, but for jobs where you KNOW dont need any processing (ie your a good shooter or the shoot was in a controled environment) i see no beenfit aside from "popping" colour.. which could even easily be done with curves IMO

To me, if you shoot something for a specific look i dont see why rerendering with no filters should change that. It jstu doesnt make sense to me considering your not asking the engine to change anything, your just asking for a new copy to be created..
The point here though, is it raises a HUGE question..
If we were to do a clean render from file to file, with no filtering, is Vegas considering the source footage to be inferior in quality to the output? If so why? How? How is it calculating the bitstream and the "requird' 32bit process? What is it doing to the existing footage considering no filtering is taking place? Is it assuming that its process is far more accurate as opposed to the image capture upon acquisition and is the "this is how it should look" algorythm of the program dictated by a certain set of processes which say.. "right, this is what we go.. all im gonna do is reshuffle this and that and give them this output.."
the question then... what is the "this and that"

With DSE's sample and with my own trial footage i been messing with, it seems that levels come damn close to what this entire process is doing.. i could be wrong, but the fact remains, is that if you dont choose a filter, the colour should not change..

This totally defeats the purpose of good camera work
megabit wrote on 9/12/2007, 5:38 AM
Thanks for this answer. Where can DES's 32bit renders you mention be seen?

AMD TR 2990WX CPU | MSI X399 CARBON AC | 64GB RAM@XMP2933  | 2x RTX 2080Ti GPU | 4x 3TB WD Black RAID0 media drive | 3x 1TB NVMe RAID0 cache drive | SSD SATA system drive | AX1600i PSU | Decklink 12G Extreme | Samsung UHD reference monitor (calibrated)

Shergar wrote on 9/12/2007, 6:43 AM
The increased range or change you are seeing in colors between 8 bit and 32 bit on raw clips is a Studio RGB /Computer RGB mapping difference, as discussed here...

http://www.sonycreativesoftware.com/forums/ShowMessage.asp?messageID=546367

So this is just unusual default behavior in Vegas - not a real example of what 32bit is for. Spot/DSE originally posted an example here...

http://www.sonycreativesoftware.com/forums/ShowMessage.asp?Forum=4&MessageID=544151

but it looks to me like his example is just highlighting the same thing - ie 32bit version is mapped to Computer RGB whereas the 8bit is Studio RGB.

To get back on topic -

Having 32bit processing in the editor allows effects, transitions and color correction to be applied more heavily without banding artifacts. I don't think it makes any difference to how to best to shoot.

If your project is destined for a large amount of effects/color correction in post then generally you should try not to clip any of the color channels as you shoot (hence not too heavy on the contrast) and get plenty of exposure so that you've got data for the effects to work on. But that applies for 8 bit and 32 bit equally.


GlennChan wrote on 9/12/2007, 11:54 AM
8-bit versus 32-bit does not change how you shoot.

A- What you see in the video preview isn't necessarily accurate. Vegas, in the past, would usually show you video footage with studio RGB levels. That is not what your viewers will see... a proper-looking image would have the levels expanded to computer RGB levels, with black at 0 and white at 235 RGB.

B- Now it gets more complicated as to all your levels. You want to preview with the right levels and you want to output with the right levels.

Previewing over DV/firewire is tricky since Vegas' DV codec always wants to see studio RGB levels, regardless of whether the project is 8 or 32-bit.
I think the 10-bit SonyYUV codec depends on 8/32-bit... so previewing over SDI is somewhat simpler.
A windows secondary display can be switched under preferences... you can set it to want studio RGB levels if that box is checked.
bruceo wrote on 9/12/2007, 12:09 PM
It just sucks that you cannot preview acceptably in 32 bit to see what your results are in motion when filtering.... Also if you put a filter that does not support 32 bit in the chain does that bring all the other filters down to 8 bit processing?
bruceo wrote on 9/12/2007, 12:15 PM
"how is this a benefit? Sorry, but as soon as saw DSEs 32bit render with no addition cc, i thought,
"it changes the colour" "

Yeah I think all of the initial footage posts were misleading because they all made it sound like 32bit made regular footage richer, which was bogus it wasn't the 32bt it was the gamma shift just as if you took the 8 bit and used curves or levels to distribute your curve for better contrast 8 or 32 bit notwithstanding.... Now that I see that it is just a gamma shift it makes sense because that is the same shift you appy when prepping video footage for print.
GlennChan wrote on 9/12/2007, 12:37 PM
If you add a 8-bit filter (the blue ones I think), then Vegas will convert 32-bit --> 8-bit --> 32-bit.

With a compositing gamma of 1.000, some weird stuff is going on.
On transitions, you get banding + dithering (but I don't think the dithering necessarily hides / deals with the banding).
With filters, you get dithering on the filter (that doesn't necessarily need to be there??).

I'm not sure about that... I havent quite yet figured it out.