Write out to linear exr. I only ever recommend this as an intermediate format
anyway. ___
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Thanks Deke,
Its good to know these things. I did test out linear exr files and it seems to
work as you described. So the only way to keep this information in a dpx file
is using log colorspace.
___
Nuke-users mailing list
Hi Deke,
We are finding this problem when we ingest files into our pipeline for all
departments. Something like file.dpx (Clog) - file.dpx (linear) and it clips
all the information available in the super-bright values like cloud detail in
the sky.
But what workflow are you using?
Read node then Write node? That's it?
Ron Ganbar
email: ron...@gmail.com
tel: +44 (0)7968 007 309 [UK]
+972 (0)54 255 9765 [Israel]
url: http://ronganbar.wordpress.com/
On 5 June 2012 21:06, aesnakes nuke-users-re...@thefoundry.co.uk wrote:
**
Hi Deke,
yes sorry, Read in the dpx as Alexa Clog colorspace, which Im assuming stripped
the baked lut to make it linear for nukes workflow and then using the write
node to output a linear dpx.
___
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk,
That's why. Nuke only supports 8-16 bit integer dpx files. Your
writing linear which is going to clip in a non float file format if
you have any values above 1.
-deke
On Tue, Jun 5, 2012 at 12:22 PM, aesnakes
nuke-users-re...@thefoundry.co.uk wrote:
yes sorry, Read in the dpx as Alexa Clog