Hi all,
It's not really Nuke, but there may be quite a few people on here using
Shake for automated conversion, as I have been doing, and so might be
interested in this little tidbit.
I was doing some automated DPX -> EXR conversions using Shake, and was
noticing a slight discrepancy in Nuke between the resulting EXRs and the
original DPXs, put through Nuke's Cineon conversion (and Nuke's Log2Lin
and Colorspace nodes)
Eventually, I tracked the issue down. Shake's DPX reader (but not the
CIN reader, which appears to work fine) has a small bug in it.
I haven't tried this with anything other than 10-bit DPX files, as this
is what most of us spend most of our time working with.
As the DPXs are 10-bit, the values have a range of 0..1023. Nuke will
happily turn these values into a range of 0..1.
Shake, however, takes the original 10-bit values and divides them by
1024, instead of 1023. If you render a pure white DPX out of Nuke (using
a Constant, and then a Write node set to Linear) and load it into Shake,
you'll find that it actually reports a value of 0.999039.
Anyway, thought you guys might be interested in that one...
--
Hugh Macdonald
*n**vizible**-- **VISUAL EFFECTS*
[email protected] <mailto:[email protected]>
+44(0) 20 3167 3860
+44(0) 7773 764 708
www.nvizible.com <http://www.nvizible.com/>
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
