[Sidefx-houdini-list] Film at 16 bit

Simon Kapeniak szymon.kapeniak at gmail.com
Wed Mar 12 13:06:45 EDT 2008


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
>



More information about the Sidefx-houdini-list mailing list