[Sidefx-houdini-list] Film at 16 bit

Larry Giunta larry at gcreativestudios.com
Wed Mar 12 20:40:54 EDT 2008


Thanks, but I ended up tracking down the error of my ways.

Mark had me totally pointed in the right direction with limit COP,
I was just not putting them in the correct places in my COP network.

Once I inserted them after very aggressive contrast and blur COPS,
it all snapped into place.

Thanks again for all the help on this one.

Larry



On Mar 12, 2008, at 7:51 PM, Antoine Durr wrote:

> 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
>
>
>
>
> _______________________________________________
> 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