[Sidefx-houdini-list] Film at 16 bit

Antoine Durr antoine at floqfx.com
Wed Mar 12 19:51:59 EDT 2008


8-bit files typically have a gamma of 2.2 baked into them.  When  
converted to a higher-bit depth format, the 2.2 could be getting left  
in there, thus having the image look washed out.

-- Antoine

On Mar 12, 2008, at 4:10 PM, Larry Giunta wrote:

> 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
> type
> 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
> integer
> 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.
>
> Larry
>
>
>
>
> 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
>
> _______________________________________________
> Sidefx-houdini-list mailing list
> Sidefx-houdini-list at sidefx.com
> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list

-- Antoine

Floq FX Inc.
10659 Cranks Rd.
Culver City, CA 90230
310/430-2473







More information about the Sidefx-houdini-list mailing list