Always when you mean about movs from Alexa remember that in Nuke 6.2 and 6.3
there is no actual 'raw' functionality in movReader.
In older versions of Nuke (up to 6.1 32bit) when you activate raw button,
movReader get values from Quictime's PixelBuffer and copy them directly,
without any
Gary Jaeger wrote:
I see that the read node still clamps values when doing colorspace
transforms. Why is that? Technical limitation or bug?
If your talking about clipping at 0.0, this is a feature of the
DD::Image::LUT class, I assume the read/write nodes use this to do the
conversions.
If
If your talking about clipping at 0.0, this is a feature of the
DD::Image::LUT class, I assume the read/write nodes use this to do the
conversions.
If there was a way to work around this it would be good as quite a few
log-lin conversions map 0.0 linear to a negative value, clipping
them
By the way this could have been avoided if I weren't in the habit of using
colorspace nodes instead of changing the read node.
I see that the read node still clamps values when doing colorspace transforms.
Why is that? Technical limitation or bug?
. . . . . . . . . . . .
Gary Jaeger // Core
I mean, it looks like your viewer is set to linear.
On 16/08/2011 15:32, Francois Lord wrote:
Is your viewer set to sRGB/REC709?
I took your image and applied a colorspace conversion from linear to
REC709 only on the Nuke part of it. Both images became nearly identical.
On 16/08/2011 13:10,
Viewer lut is set. Tried both sRGB and Rec709. I've already set the LogC
footage to AlexsaLogC. So I have a Colorspace node in AlexaV3LogC, out
Linear. So in your case that would be AlexaLogC Linear, then Linear
Rec709, then viewing in Rec709? Isn't that doubling up the Rec709 part since
you're
