Thanks for this Deke.
The settings are all the same, but looking at the Nuke Viewer set to sRGB,
I see a very washed out image - what I would normally consider a Cineon
looking image. Looking at the Redcine-X viewer it looks correct.
Any ideas?
Ron Ganbar
email: ron...@gmail.com
tel: +44 (0)7968
The .r3d will output an sRGB'ish image, assuming you select RedColor2
etc in the gamma settings
So, the viewer-process means you are apply a linear-to-sRGB node to the
already-sRGB image, so it looks washed out
Ideally you would select the linear-light gamma-setting, do comp'y stuff
then apply
I forgot to mention that It all depends what file format your
outputting. If your outputting to dpx or tiff then set the decode
colorspace/gamma curve the same as RedcineX but in the write node set the
colorspace to linear. While working with the R3d though, the viewer will
look different from
I might be misunderstanding you, but why the srgb2lin conversion? RedcineX
only outputs linear exrs so as far as I know you shouldn't use any
colorspace convertions in Nuke if you chose that path. You can test this if
you try different gamma curves in RedcineX and render to EXR. They should
all
Hi guys,
I have yet to try your suggestions (on a different job this morning), but
just to explain - I'm not talking about file output from Redcine-X - just
what I see in the Viewer.
Simon, I will try the setting combination you mentioned earlier tonight and
will report back.
Thanks all!
Ron
All-
I followed up on this on the Rush list and Greg Ercolano posted a very thorough
reply. I thought some of you might be interested in what he had to say. Sounds
like the best all around answer is a /usr/bin script which is similar to the
method Johannes was suggesting. Rush specific stuff at
Simon,
your settings work a treat.
I would love to know what's actually happening, though. What is Linear Half
Float? What process is happening inside there? And finally, am I right in
assuming that the output of the Read node is a linear image?
Thanks,
Ron Ganbar
email: ron...@gmail.com
tel: +44
1.0 is half float if it encoded half float and clamp to 1.0
Sent from myTouch 4G
- Reply message -
From: Deke Kincaid dekekinc...@gmail.com
To: Nuke user discussion nuke-users@support.thefoundry.co.uk
Subject: [Nuke-users] Redcine-X VS Nuke
Date: Tue, Dec 20, 2011 12:13
Last I knew
1.0 is half float/float even if not clamped ;)
for Ron's question (if I read it right)
Half float or 16 bit float is a less accurate version of 32 bit float.
AFAIK The float being the floating point part of the number. you dont save
123.45678 you save 12345678 with a bit(?) for the position
clamped to 1.0 or raw data mapped to values between 0-1.0 with 3
places of precision. But I am pretty sure the d/a in every camera is
integer and mapping data into integer space for its raw file.
http://www.rslittle.com
On Tue, Dec 20, 2011 at 13:37, Howard Jones mrhowardjo...@yahoo.com
18% grey isn't pushed to .18 .18=18% of 0-1 linear response.
18%grey is what happens if you mix 50%black and 50%white and spin it
really fast. You get a scene average reflectance of 18%.The chips
aren't reordering more then 16bits INT. the only reason you need/want
float is when you start
11 matches
Mail list logo
