[Sidefx-houdini-list] Film at 16 bit

Larry Giunta larry at gcreativestudios.com
Wed Mar 12 19:10:52 EDT 2008

so here's one more question.

When I take my 32 bit float rendered volume light layers into composite,
and plug them into a comp network that was originally worked up with
8 bit renders, the results are vastly different.  The final images  
are way
more contrasty  ....... like I threw a composite comp on the end and  
in 10 and 10 on the high and low end.

I tried to use the limit COPs, but didn't see much difference.

If I drop a convert  COP after all file COPs and convert to 32 bit  
with a B+ W point of 0 and 255, then my final comp looks as I expect.

However, am I now canceling out all of the benefit of rendering the
source layers as 32 bit float in the first place??

Is there another white point I should be using for 32 bit integer??

As always, thanks for any thoughts.


On Mar 12, 2008, at 1:14 PM, Sean Lewkiw wrote:

> Interestingly, we were looking at this a while back.
> One of our senior compers reports that shake converts exrs to 16  
> bit on
> load, so 32 bit exrs are unnecessary.  However, we also found that 16
> bit float EXRs were not entirely accurate.  (For example, rendering UV
> maps out of Houdini and loading into Shake results in some very subtle
> banding.)
> We have not done any tests on loading times/image quality and image
> sizes of 32 bit VS 16 bit exr floats.  I'm wondering if Nuke deals  
> with
> this differently and/or better.
> So, our policy here is 16 bit float with embedded DODs for most CG
> renders, except where great precision is necessary, then 32 bit TIFFs.
> Sean
> Simon Kapeniak wrote:
>> Hello Mark,
>> This is extremely interesting. Are you saying that any application  
>> working
>> on any current platform has to deal with a 16bit float data by  
>> converting it
>> up to a 32bit float internally? Or it does have to do it if wants  
>> to use
>> MMX/SSE? How this happens in Nuke working with EXR for example
>> (theoretically)? Assuming that it doesn't use GPU which supports  
>> half floats
>> natively, which isn't the case I bet. Surely Shake converts EXRs  
>> to 32bit on
>> load, which illustrate that issue.
>> Hmm, interesting... I've never though this way although I'm  
>> complete freak
>> about compositing performance (working with Shake's iffs mostly  
>> for that
>> very reason). I was silently assuming that half float means means  
>> half space
>> and half work for CPU (roughly).
>> 2008/3/7, Mark Alexander <malexender at sidefx.com>:
>>> Both 16b Int and 32b FP are XMMX and SSE optimized. 16b FP is the
>>> slowest of the bunch, being a format that is not native to the  
>>> CPU (it
>>> is pretty much always up-converted to FP32). 16b Int is probably the
>>> most work, since you have to worry about the white point (setting it
>>> somewhere around 4000 for really HDR stuff).
>>> However, you can save all your files in 16b FP and force the  
>>> compositor
>>> to load them as FP32 files. Edit->Composite Project Settings, "Pixel
>>> Format" = "32 bit FP" and "File Operators use the Project Pixel  
>>> Depth by
>>> Default" = "On". That save disk space and network bandwidth, while
>>> optimizing performance in COPs by comp'ing everything in 32b FP.  
>>> You can
>>> still save out 16b FP files at the end without any problems.
>>> Cheers,
>>> M.
>>> _______________________________________________
>>> Sidefx-houdini-list mailing list
>>> Sidefx-houdini-list at sidefx.com
>>> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>> _______________________________________________
>> Sidefx-houdini-list mailing list
>> Sidefx-houdini-list at sidefx.com
>> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
> -- 
> Sean Lewkiw
> --
> CIS London
> 130 Shaftesbury Avenue
> London W1D 5EU
> --
> +44 (0) 207.031.1138 (P) (Direct)
> +44 (0) 207.031.1136 (F)
> +44 (0) 795.606.7245 (M)
> --
> Composite Image Systems London Ltd
> Registered Office: Denham Media Park, North Orbital Road, Denham,
> Uxbridge, Middlesex UB9 5HQ
> Company Registration No. 5577229 England
> _______________________________________________
> Sidefx-houdini-list mailing list
> Sidefx-houdini-list at sidefx.com
> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list

More information about the Sidefx-houdini-list mailing list