Colour-spaces, colours processing and bit depths!

[MrKepzie]

To avoid confusions I will explain the different levels of colorspace conversion occurring in Natron.

The following expects that the OpenColorIO-Configs are found by Natron. (If you see the choices in input/output colorspaces of a Reader/Writer this is ok). If the OCIO config cannot be found, the color-space conversion on the reader/writer will not be correct. You can specify the OCIO config only for 1 Reader/Writer via the parameter "OCIO config", but Natron allows you to specify the OCIO config across the whole application in the preferences panel. In the OpenColorIO tab, select the OCIO config file. By default we use the config OpenColorIO-Configs/blender/config.ocio 

By default Natron bundles with some OCIO configs which are:

• nuke-default
  
• blender
• Aces
  
• spy-anim
• spy-vfx

By default, if found Natron will use the config "blender" in the preferences, hence all readers/writers will use this config.

If Natron fails to find these bundled configs this is probably because they are not located where Natron expects them.

1. On Linux Natron looks in /usr/share or ../share relative to the binary by default. You can change it by pointing to the right config in the preferences.
   
2. On MacOSX Natron looks in ../Resources/ relative to the binary. If you're using the pre-compiled version of Natron (downloaded from our website) it should find it alone.
   
3. On Windows it is the same as MacOSX.

See here http://opencolorio.org/configurations/index.html for more infos about the OpenColorIO configs.

Now let's explain how colorspaces are handled in Natron...

First of all there's the Reader node which converts from the image file's colorspace (e.g sRGB for a jpg) to linear 32 bits fp data.

This can be controlled in the Reader node with the "Input colorsapce" and "Output  colorspace". 

If you're reading a jpeg, then you can safely assume the colorspace is sRGB for the "input colorspace".

Regarding the output colorspace you should always set it to linear unless you know what you're doing. If you set it to something else than Linear then Natron's processing will be done in the colour-space you set and it can be mathematically wrong.

Now the opposite is done in the writer node. The input colorspace is the color-space of the image within Natron. You can assume this is almost always 32bits fp linear colours, so leave it unchanged. The output colorspace specifies what will be the colorspace of the image in the output file. Generally the write node will choose it right for you (e.g sRGB for jpeg, linear for EXRs) , but sometimes it can do it wrong, so double check that this is exactly the output colorspace you want.

And now some more complexity is added on top of that: 

Generally all processing , end to end , in Natron is done in linear 32 bits floating point. However some plug-ins in the middle of the workflow might not support 32 bits floating point processing, so we're forced to convert the images to something the plug-in can support , e.g 8 bits.

When doing such conversion Natron wil use the parameters of the project to convert to the appropriate color-space, according to the target bit depth. For example if we're in 32 bits and Natron needs to convert to 8 bits for some plug-in,  then we will convert from Linear to sRGB (assuming the project settings are left unchanged, that is Linear for 32 bits, sRGB for 8bits and Rec709 for 16bits). 

By chance after your plug-in that only supports 8 bits, if you have only plug-ins that can also support 8 bit processing, the output of the graph will be 8 bits, and it will be in the color-space of 8 bits images (i.e sRGB), thus you'll have to be careful in your write node at the end of the graph to the color-space of your input data!

In the case that below your 8bit plug-in only you have another plug-in that doesn't support 8 bits processing, Natron will do the same and will convert from 8 bits to XX (insert the bit depth of the plug-in that doesn't support 8bits).

There're very FEW plug-ins out there that don't support 32 bits fp processing , so you should assume all the processing inside Natron is 32 bit fp and in the color-space defined in the project (i.e: Linear by default).

In the general case you have nothing to do and Natron should correctly guess all the color-spaces for you, except in some tricky cases. 

You generally have to check that your Reader node reads in the right color-space (i.e the Input colorspace parameter is set accordingly) and that your Writer nodes writes in the right color-space (i.e the output colorspace parameter is set accordingly), that's all.

Now there's a last thing: The viewer colour-space (adjustable from the viewer interface). 

This is the color-space into which data will be converted to be displayed on the viewer. You should generally not change this, unless you know what you are doing. This can be helpful for example to watch the viewer on a monitor in Rec709 color-space. 

Hope this helps,

Alex

[paulge...@gmail.com]

On Saturday, June 28, 2014 3:38:21 PM UTC+4, MrKepzie wrote:
> To avoid confusions I will explain the different levels of colorspace conversion occurring in Natron.
>
>
>

> The following expects that the OpenColorIO-Configs are found by Natron. (If you see the choices in input/output colorspaces of a Reader/Writer this is ok). If the OCIO config cannot be found, the color-space conversion on the reader/writer will not be correct. You can specify the OCIO config only for 1 Reader/Writer via the parameter "OCIO config", but Natron allows you to specify the OCIO config across the whole application in the preferences panel. In the OpenColorIO tab, select the OCIO config file. By default we use the config OpenColorIO-Configs/nuke-default/config.ocio 

> By default Natron bundles with some OCIO configs which are:
>
>
> nuke-default

> Aces
> spy-animspy-vfx
> By default, if found Natron will use the config "nuke-default" in the preferences, hence all readers/writers will use this config.

> If Natron fails to find these bundled configs this is probably because they are not located where Natron expects them.
>
>

> On Linux Natron looks in /usr/share by default. You can change it by pointing to the right config in the preferences.

> On MacOSX Natron looks in ../Resources/ relative to the binary. If you're using the pre-compiled version of Natron (downloaded from our website) it should find it alone.
> On Windows it is the same as MacOSX.
>
>
>
>

> Now let's explain how colorspaces are handled in Natron...
>
>
>
>
> First of all there's the Reader node which converts from the image file's colorspace (e.g sRGB for a jpg) to linear 32 bits fp data.
> This can be controlled in the Reader node with the "Input colorsapce" and "Output  colorspace". 
> If you're reading a jpeg, then you can safely assume the colorspace is sRGB for the "input colorspace".
> Regarding the output colorspace you should always set it to linear unless you know what you're doing. If you set it to something else than Linear then Natron's processing will be done in the colour-space you set and it can be mathematically wrong.
>
>
> Now the opposite is done in the writer node. The input colorspace is the color-space of the image within Natron. You can assume this is almost always 32bits fp linear colours, so leave it unchanged. The output colorspace specifies what will be the colorspace of the image in the output file. Generally the write node will choose it right for you (e.g sRGB for jpeg, linear for EXRs) , but sometimes it can do it wrong, so double check that this is exactly the output colorspace you want.
>
>
> And now some more complexity is added on top of that: 
>
>
> Generally all processing , end to end , in Natron is done in linear 32 bits floating point. However some plug-ins in the middle of the workflow might not support 32 bits floating point processing, so we're forced to convert the images to something the plug-in can support , e.g 8 bits.
> When doing such conversion Natron wil use the parameters of the project to convert to the appropriate color-space, according to the target bit depth. For example if we're in 32 bits and Natron needs to convert to 8 bits for some plug-in,  then we will convert from Linear to sRGB (assuming the project settings are left unchanged, that is Linear for 32 bits, sRGB for 8bits and Rec709 for 16bits). 
>
>
> By chance after your plug-in that only supports 8 bits, if you have only plug-ins that can also support 8 bit processing, the output of the graph will be 8 bits, and it will be in the color-space of 8 bits images (i.e sRGB), thus you'll have to be careful in your write node at the end of the graph to the color-space of your input data!
>
>
> In the case that below your 8bit plug-in only you have another plug-in that doesn't support 8 bits processing, Natron will do the same and will convert from 8 bits to XX (insert the bit depth of the plug-in that doesn't support 8bits).
>
>
> There're very FEW plug-ins out there that don't support 32 bits fp processing , so you should assume all the processing inside Natron is 32 bit fp and in the color-space defined in the project (i.e: Linear by default).
>
>
> In the general case you have nothing to do and Natron should correctly guess all the color-spaces for you, except in some tricky cases. 
> You generally have to check that your Reader node reads in the right color-space (i.e the Input colorspace parameter is set accordingly) and that your Writer nodes writes in the right color-space (i.e the output colorspace parameter is set accordingly), that's all.
>
>
>
>
> Now there's a last thing: The viewer colour-space (adjustable from the viewer interface). 
> This is the color-space into which data will be converted to be displayed on the viewer. You should generally not change this, unless you know what you are doing. This can be helpful for example to watch the viewer on a monitor in Rec709 color-space. 
>
>
> Hope this helps,
>
>
> Alex

Could you add this link http://opencolorio.org/configurations/index.html to your decription about OpenColorIO config file? So that people just can download the config and set them in Edit->Presferences.

[Alexandre]

Sure but we already provide the OpenColorIO configs with the binaries of Natron!

> --
> You received this message because you are subscribed to the Google Groups "Natron" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to Natron-VFX+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[srl...@gmail.com]

On Saturday, June 28, 2014 7:38:21 AM UTC-4, MrKepzie wrote:
> To avoid confusions I will explain the different levels of colorspace conversion occurring in Natron.
>
>
>
> The following expects that the OpenColorIO-Configs are found by Natron. (If you see the choices in input/output colorspaces of a Reader/Writer this is ok). If the OCIO config cannot be found, the color-space conversion on the reader/writer will not be correct. You can specify the OCIO config only for 1 Reader/Writer via the parameter "OCIO config", but Natron allows you to specify the OCIO config across the whole application in the preferences panel. In the OpenColorIO tab, select the OCIO config file. By default we use the config OpenColorIO-Configs/nuke-default/config.ocio 
> By default Natron bundles with some OCIO configs which are:
>
>
> nuke-default
> Aces
> spy-animspy-vfx
> By default, if found Natron will use the config "nuke-default" in the preferences, hence all readers/writers will use this config.
> If Natron fails to find these bundled configs this is probably because they are not located where Natron expects them.
>
>
> On Linux Natron looks in /usr/share by default. You can change it by pointing to the right config in the preferences.
> On MacOSX Natron looks in ../Resources/ relative to the binary. If you're using the pre-compiled version of Natron (downloaded from our website) it should find it alone.
> On Windows it is the same as MacOSX.

> See here http://opencolorio.org/configurations/index.html for more infos about the OpenColorIO configs.
>
>

> Now let's explain how colorspaces are handled in Natron...
>
>
>
>
> First of all there's the Reader node which converts from the image file's colorspace (e.g sRGB for a jpg) to linear 32 bits fp data.
> This can be controlled in the Reader node with the "Input colorsapce" and "Output  colorspace". 
> If you're reading a jpeg, then you can safely assume the colorspace is sRGB for the "input colorspace".
> Regarding the output colorspace you should always set it to linear unless you know what you're doing. If you set it to something else than Linear then Natron's processing will be done in the colour-space you set and it can be mathematically wrong.
>
>
> Now the opposite is done in the writer node. The input colorspace is the color-space of the image within Natron. You can assume this is almost always 32bits fp linear colours, so leave it unchanged. The output colorspace specifies what will be the colorspace of the image in the output file. Generally the write node will choose it right for you (e.g sRGB for jpeg, linear for EXRs) , but sometimes it can do it wrong, so double check that this is exactly the output colorspace you want.
>
>
> And now some more complexity is added on top of that: 
>
>
> Generally all processing , end to end , in Natron is done in linear 32 bits floating point. However some plug-ins in the middle of the workflow might not support 32 bits floating point processing, so we're forced to convert the images to something the plug-in can support , e.g 8 bits.
> When doing such conversion Natron wil use the parameters of the project to convert to the appropriate color-space, according to the target bit depth. For example if we're in 32 bits and Natron needs to convert to 8 bits for some plug-in,  then we will convert from Linear to sRGB (assuming the project settings are left unchanged, that is Linear for 32 bits, sRGB for 8bits and Rec709 for 16bits). 
>
>
> By chance after your plug-in that only supports 8 bits, if you have only plug-ins that can also support 8 bit processing, the output of the graph will be 8 bits, and it will be in the color-space of 8 bits images (i.e sRGB), thus you'll have to be careful in your write node at the end of the graph to the color-space of your input data!
>
>
> In the case that below your 8bit plug-in only you have another plug-in that doesn't support 8 bits processing, Natron will do the same and will convert from 8 bits to XX (insert the bit depth of the plug-in that doesn't support 8bits).
>
>
> There're very FEW plug-ins out there that don't support 32 bits fp processing , so you should assume all the processing inside Natron is 32 bit fp and in the color-space defined in the project (i.e: Linear by default).
>
>
> In the general case you have nothing to do and Natron should correctly guess all the color-spaces for you, except in some tricky cases. 
> You generally have to check that your Reader node reads in the right color-space (i.e the Input colorspace parameter is set accordingly) and that your Writer nodes writes in the right color-space (i.e the output colorspace parameter is set accordingly), that's all.
>
>
>
>
> Now there's a last thing: The viewer colour-space (adjustable from the viewer interface). 
> This is the color-space into which data will be converted to be displayed on the viewer. You should generally not change this, unless you know what you are doing. This can be helpful for example to watch the viewer on a monitor in Rec709 color-space. 
>
>
> Hope this helps,
>
>
> Alex

Hi Alex,

If this conversion to 8bit is going on behind the scenes, could you guys add some sort of indicator in the interface to let us know when its happening? Maybe these plugins can have a symbol added to their node that shows they support only 8bit data flow.

[Alexandre]

Hey,

They do !;)

If a plug-in is explicitly converting to 8bit, it will have a “C” warning symbol on the node indicating that a conversion is occurring, and the tooltip will contain the details.

regards,

Alex

-- 
You received this message because you are subscribed to the Google Groups "Natron" group.
To unsubscribe from this group and stop receiving emails from it, send an email to Natron-VFX+...@googlegroups.com.

To post to this group, send email to Natro...@googlegroups.com.
Visit this group at http://groups.google.com/group/Natron-VFX.
To view this discussion on the web visit https://groups.google.com/d/msgid/Natron-VFX/795f2652-b4ac-4a5b-9c88-e3889725f899%40googlegroups.com.

[jden...@gmail.com]

On Saturday, June 28, 2014 6:38:21 AM UTC-5, MrKepzie wrote:
> To avoid confusions I will explain the different levels of colorspace conversion occurring in Natron.
>
>
>

> The following expects that the OpenColorIO-Configs are found by Natron. (If you see the choices in input/output colorspaces of a Reader/Writer this is ok). If the OCIO config cannot be found, the color-space conversion on the reader/writer will not be correct. You can specify the OCIO config only for 1 Reader/Writer via the parameter "OCIO config", but Natron allows you to specify the OCIO config across the whole application in the preferences panel. In the OpenColorIO tab, select the OCIO config file. By default we use the config OpenColorIO-Configs/blender/config.ocio 

> By default Natron bundles with some OCIO configs which are:
>
>
> nuke-default

> blenderAces
> spy-animspy-vfx
> By default, if found Natron will use the config "blender" in the preferences, hence all readers/writers will use this config.

> If Natron fails to find these bundled configs this is probably because they are not located where Natron expects them.
>
>

> On Linux Natron looks in /usr/share or ../share relative to the binary by default. You can change it by pointing to the right config in the preferences.

> On MacOSX Natron looks in ../Resources/ relative to the binary. If you're using the pre-compiled version of Natron (downloaded from our website) it should find it alone.
> On Windows it is the same as MacOSX.
> See here http://opencolorio.org/configurations/index.html for more infos about the OpenColorIO configs.
>
>
> Now let's explain how colorspaces are handled in Natron...
>
>
>
>
> First of all there's the Reader node which converts from the image file's colorspace (e.g sRGB for a jpg) to linear 32 bits fp data.
> This can be controlled in the Reader node with the "Input colorsapce" and "Output  colorspace". 
> If you're reading a jpeg, then you can safely assume the colorspace is sRGB for the "input colorspace".
> Regarding the output colorspace you should always set it to linear unless you know what you're doing. If you set it to something else than Linear then Natron's processing will be done in the colour-space you set and it can be mathematically wrong.
>
>
> Now the opposite is done in the writer node. The input colorspace is the color-space of the image within Natron. You can assume this is almost always 32bits fp linear colours, so leave it unchanged. The output colorspace specifies what will be the colorspace of the image in the output file. Generally the write node will choose it right for you (e.g sRGB for jpeg, linear for EXRs) , but sometimes it can do it wrong, so double check that this is exactly the output colorspace you want.
>
>
> And now some more complexity is added on top of that: 
>
>
> Generally all processing , end to end , in Natron is done in linear 32 bits floating point. However some plug-ins in the middle of the workflow might not support 32 bits floating point processing, so we're forced to convert the images to something the plug-in can support , e.g 8 bits.
> When doing such conversion Natron wil use the parameters of the project to convert to the appropriate color-space, according to the target bit depth. For example if we're in 32 bits and Natron needs to convert to 8 bits for some plug-in,  then we will convert from Linear to sRGB (assuming the project settings are left unchanged, that is Linear for 32 bits, sRGB for 8bits and Rec709 for 16bits). 
>
>
> By chance after your plug-in that only supports 8 bits, if you have only plug-ins that can also support 8 bit processing, the output of the graph will be 8 bits, and it will be in the color-space of 8 bits images (i.e sRGB), thus you'll have to be careful in your write node at the end of the graph to the color-space of your input data!
>
>
> In the case that below your 8bit plug-in only you have another plug-in that doesn't support 8 bits processing, Natron will do the same and will convert from 8 bits to XX (insert the bit depth of the plug-in that doesn't support 8bits).
>
>
> There're very FEW plug-ins out there that don't support 32 bits fp processing , so you should assume all the processing inside Natron is 32 bit fp and in the color-space defined in the project (i.e: Linear by default).
>
>
> In the general case you have nothing to do and Natron should correctly guess all the color-spaces for you, except in some tricky cases. 
> You generally have to check that your Reader node reads in the right color-space (i.e the Input colorspace parameter is set accordingly) and that your Writer nodes writes in the right color-space (i.e the output colorspace parameter is set accordingly), that's all.
>
>
>
>
> Now there's a last thing: The viewer colour-space (adjustable from the viewer interface). 
> This is the color-space into which data will be converted to be displayed on the viewer. You should generally not change this, unless you know what you are doing. This can be helpful for example to watch the viewer on a monitor in Rec709 color-space. 
>
>
> Hope this helps,
>
>
> Alex

So an odd question: I'm interested in exploring ACES workflows, and I see that Natron supports that in the read/write nodes. My question is Natron supposed to convert the ACES data into it's own linear 32 bit space on read in? What would happen if I told the reader node to output into ACES space?

[Alexandre]

So an odd question: I'm interested in exploring ACES workflows, and I see that Natron supports that in the read/write nodes.  My question is Natron supposed to convert the ACES data into it's own linear 32 bit space on read in?  What would happen if I told the reader node to output into ACES space?

If you’re reading something that is not ACES, e.g: a Linear 32b fp EXR file,  then the Reader node’s “File colorspace”  parameter will be set to Linear.

You’re free to set the “Output colorspace” to ‘aces’ in which case the output of the Reader node will be in that color-space (ACES) and all the processing downstream too. 

You can also modify the colorspace within the node tree with the OCIOColorSpace node. 

In output with the Writer node you then just have to do the opposite: set the “Input colorspace” to ACES if all your tree’s colorspace has not changed, and set the file colorspace to something corresponding to your file type (e.g Linear for EXR). 

To be able to select the ACES config, you should use the aces_0.7.1 color profile in the preferences (in the OpenColorIO tab). Note that changing this requires a restart of Natron.

-- 
You received this message because you are subscribed to the Google Groups "Natron" group.
To unsubscribe from this group and stop receiving emails from it, send an email to Natron-VFX+...@googlegroups.com.
To post to this group, send email to Natro...@googlegroups.com.
Visit this group at http://groups.google.com/group/Natron-VFX.

To view this discussion on the web visit https://groups.google.com/d/msgid/Natron-VFX/7f1c1366-024d-4937-8a9f-92078e505629%40googlegroups.com.

[jden...@gmail.com]

> If you’re reading something that is not ACES, e.g: a Linear 32b fp EXR file,  then the Reader node’s “File colorspace”  parameter will be set to Linear.
> You’re free to set the “Output colorspace” to ‘aces’ in which case the output of the Reader node will be in that color-space (ACES) and all the processing downstream too. 
> You can also modify the colorspace within the node tree with the OCIOColorSpace node. 
> In output with the Writer node you then just have to do the opposite: set the “Input colorspace” to ACES if all your tree’s colorspace has not changed, and set the file colorspace to something corresponding to your file type (e.g Linear for EXR). 
>
>
> To be able to select the ACES config, you should use the aces_0.7.1 color profile in the preferences (in the OpenColorIO tab). Note that changing this requires a restart of Natron.
>
> -- 
> You received this message because you are subscribed to the Google Groups "Natron" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to Natron-VFX+...@googlegroups.com.
> To post to this group, send email to Natro...@googlegroups.com.
> Visit this group at http://groups.google.com/group/Natron-VFX.
> To view this discussion on the web visit https://groups.google.com/d/msgid/Natron-VFX/7f1c1366-024d-4937-8a9f-92078e505629%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

So would I be right in thinking that Natron itself doesn't really have a colorspace of it's own? Would Natron still be compositing in ACES space using the 'Blender' default OCIO config (the ACES transforms still appear)? Is there even a benefit to doing this vs converting ACES material to linear on read in and then back at write out? I'm trying like heck to understand how colorspaces work in rendering and compositing apps and it's a bit of a black art to put it mildly.

[Gmail]

I'm not an expert of Aces color space so I might be mistaken when speaking about it, but generally what you want to do is have all your internal pipeline linear , I.e by having the output color space of the reader to linear and the input color space of the writer linear. For what I know you could use a workflow in aces instead of linear, although there might be pitfalls that I'm unaware of. I think the aces colors pace of the blender ocio confg corresponds to aces 0.1 so you might want to use aces 0.7 instead

> To view this discussion on the web visit https://groups.google.com/d/msgid/Natron-VFX/a8a4bc23-2feb-462a-9ee0-4a5dd6b8e031%40googlegroups.com.

[jden...@gmail.com]

On Tuesday, December 30, 2014 6:09:07 AM UTC-6, MrKepzie wrote:
> I'm not an expert of Aces color space so I might be mistaken when speaking about it, but generally what you want to do is have all your internal pipeline linear , I.e by having the output color space of the reader to linear and the input color space of the writer linear. For what I know you could use a workflow in aces instead of linear, although there might be pitfalls that I'm unaware of. I think the aces colors pace of the blender ocio confg corresponds to aces 0.1 so you might want to use aces 0.7 instead
>
>
>

I've done as much reading on ACES as I can find without running into white papers (which would go over my head). If I did decide to use an ACES flow I think I would have to convert the Blender material to ACES in Natron since it doesn't appear that Blender can directly output it. My live action would be converted to ACES inside Davinci Resolve. I figure experimenting never hurt anyone so I'll see what happens.

[Dennis Summers]

Ok, I have a 16 bit linear exr file. If I keep everything as linear in natron the image looks almost like the same image in rec 709 colorspace in vray, photoshop, fusion, and AE (meaning all four of these look the same and as I want). But natron is just a little bit more contrasty, almost unnoticeable, but still different. Since I want my output to be in rec 709, if I change the output colorspace to either nuke_rec709 or rrt_rec709, the image is considerably lighter, and also different from each other (why are the two rec709s different anyway?). What am I missing here? And is Natron unable to access the icc profile that all the other apps can?

[Ole Andre Rodlie]

As far as I know ReadOIIO only checks for the ICC profile name, if OpenColorIO takes the ICC into account before converting is unknown to me. I'm currently experimenting with ICC in one of the read nodes (doing icc color convert before OIIO).

Ole