[Nuke-users] OCIO Colorspace (nuke-default) clamping colors

I can see that the OCIO Colorspace node, using the nuke-default config, clamps colors between 0-1 while the regular colorpsace node doesn't? Is it a bug or a feature? set cut_paste_input [stack 0] version 9.0 v7 BackdropNode { inputs 0 name BackdropNode1 tile_color 0x7171c600 label OCIO

Re: [Nuke-users] OCIO Colorspace (nuke-default) clamping colors

Well, it is how OCIO works and how the nuke-default is implemented. It is all defined through 1D lookup tables. And that means it is defined only in a limited range. In this case it is -0.125 - 1.125. So when you convert back from linear it gets clamped to this range. The colorspace node on the

Re: [Nuke-users] Export user tracks to Axis from CameraTracker

That worked...thanks! On 1 November 2015 at 16:56, Frank Rueter|OHUfx wrote: > I haven't tried but you should be able to do this on any resolved 3D point > (green points). > > > On 1/11/15 2:50 am, Michael Garrett wrote: > > Thank you for pointing out that menu in the 2d view.

Re: [Nuke-users] OCIO Colorspace (nuke-default) clamping colors

Hi Mads, That's a feature, IMO. sRGB doesn't define super brights. It should clamp. I think you should get the same result saving an image out as sRGB, and reading it back in, as converting it to sRGB and converting it back. Which is what you see with the OCIO node. Don't convert to a

Re: [Nuke-users] Export user tracks to Axis from CameraTracker

I haven't tried but you should be able to do this on any resolved 3D point (green points). On 1/11/15 2:50 am, Michael Garrett wrote: Thank you for pointing out that menu in the 2d view. So can I do that over any point including a user track, meaning a 2d track I've fed in? On 30 October

Re: [Nuke-users] OCIO Colorspace (nuke-default) clamping colors

Well, there's definetly cases were you want to a gamma encoded format in your processing tree (for example sRGB). For example it will sometimes give better result when keying by converting to sRGB first (and then back to linear). For this very reason OpenColorIO added support for a secondary sRGB