|
Abraham Schneider <abraham....@...>
Hi there!
I just posted this question on the ACES website: http://acescentral.com/t/why-utility-raw-as-reference-for-aces1-0-3-and-not-aces2065-1/1378
It seems like it's not just me that is unsure, how OCIO decides, which colorspace in a config is used as the reference space, that all other colorspaces are related to. And what excact purpose the 'reference' role has.
Could you maybe have a look at this and shine some light on this topic?
Thanks, Abraham
|
|
|
Haarm-Pieter Duiker <li...@...>
Cross posting for completeness
The document detailing ACES support in various applications, is here (read only):
If anyone is interested in updating the document for more current versions, let me know. I'd be happy to provide an editable link. Just message me.
For those interested in implementations, I think the Nuke nodes are supposed to be a reference. The OCIO Colorspace node creates the path from one colorspace to the next with this call m_processor = config->getProcessor(context, inputName, outputName);
which leads to this call to create a color space conversion processor->getImpl()->addColorSpaceConversion(*this, context, src, dst);
which eventually leads to this function BuildColorSpaceOps which takes two colorspaces and concatenates the source colorspace's to_reference (or inverse from_reference) transforms with the destination colorspace's from_reference (or inverse to_reference) transforms.
So... the code has it. The reference colorspace isn't the first colorspace. It isn't the space pointed to by the 'reference' role. It's the space that the config colorspace's various to_reference and from_reference transforms use as a target or as a source. Hopefully all the colorspace's in the config agree on that definition!
On Mon, Apr 16, 2018 at 12:38 AM, Abraham Schneider <abraham....@...> wrote: Hi there!
It seems like it's not just me that is unsure, how OCIO decides, which colorspace in a config is used as the reference space, that all other colorspaces are related to. And what excact purpose the 'reference' role has.
Could you maybe have a look at this and shine some light on this topic?
Thanks, Abraham
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
|
|
|
Dithermaster <dither...@...>
Yes, I completely agree with that definition. My assertion that 'reference' was related turned out to be something in our own code, not OCIO.
///d@
On Wed, Apr 18, 2018 at 11:25 PM, Haarm-Pieter Duiker <li...@...> wrote: Cross posting for completeness
The document detailing ACES support in various applications, is here (read only):
If anyone is interested in updating the document for more current versions, let me know. I'd be happy to provide an editable link. Just message me.
For those interested in implementations, I think the Nuke nodes are supposed to be a reference. The OCIO Colorspace node creates the path from one colorspace to the next with this call m_processor = config->getProcessor(context, inputName, outputName);
which leads to this call to create a color space conversion processor->getImpl()->addColorSpaceConversion(*this, context, src, dst);
which eventually leads to this function BuildColorSpaceOps which takes two colorspaces and concatenates the source colorspace's to_reference (or inverse from_reference) transforms with the destination colorspace's from_reference (or inverse to_reference) transforms.
So... the code has it. The reference colorspace isn't the first colorspace. It isn't the space pointed to by the 'reference' role. It's the space that the config colorspace's various to_reference and from_reference transforms use as a target or as a source. Hopefully all the colorspace's in the config agree on that definition!
|
|
|
Hi folks-
H.P., I also agree with that definition. But - it's also true that if you are converting to or from the 1st colorspace in the config list (aka "Reference" colorspace) we should see the to_reference or from_reference transform (or inverse as-needed) applied alone. More specifically, we don't need to explicitly convert from colorspace A to Reference colorspace, then from Reference colorspace to colorspace B because the conversion from Reference to Reference is a non-op. So the OCIO ColorSpace isn't ignoring the reference colorspace in its conversion (as we can explicitly use it if desired), it's simply skipping the conversion from Reference<>Reference that is implied which seems to be standard OCIO behavior. Nevertheless I agree - it's up to the config author to accuratly define the to_reference and from_reference transforms.
From my view, the relevant issues that crop up are symptoms of inconsistent implementations, esp. where Roles are used for implied conversions in the host application.
For example, I can see that Nuke OCIO CDLTransform uses the "reference" ROLE assignment for converting to/from the "working space" assigned in the OCIO CDLTransform node. This is inconsistent, because for other standard operations Nuke honors the reference colorspace that is implied by the first colorspace in the config file. A Read node transforms colors from the Read node colorspace to the Project Settings working space, as do other standard Nuke nodes with colorspace assignments. Of course, we can set the Project Settings working space to the reference/1st colorspace if we want to, and the conversions still happen as expected.
As for the Roles in the config - some of them are used to populate the color Project Settings assignments for "working space," "log files," etc. when a given config file is first loaded. But when some plugins like OCIO CDLTransform use OCIO Roles in its own way, ignoring the Nuke color Project Settings, things are getting overly complicated.
From the source code comments: https://github.com/imageworks/OpenColorIO/blob/a557a85454ee1ffa8cb66f8a96238e079c452f08/export/OpenColorIO/OpenColorTypes.h#L341
ColorSpace Roles are used so that plugins, in addition to this API can have abstract ways of asking for common colorspaces, without referring to them by hardcoded names. All this considered, I conclude that the "reference" role should always be the "reference" (1st) colorspace in the config list. A few suggestions for improved behavior in the wild:
1. As users, get in the habit of setting the reference role to the 1st colorspace in the list. 2. OCIO sanity checks and ociocheck app should return an error if "reference" role is anything other the 1st colorspace. 3. Maybe - hardcode the "reference" role to the first colorspace in the list when configs are read in. I.e.: don't allow custom assignments. I expect some backlash for this suggestion - please don't rake me over the coals :) This at least enforces the intended usage.
-Chris
On Thursday, April 19, 2018 at 8:52:43 AM UTC-7, Dennis Adams wrote: Yes, I completely agree with that definition. My assertion that 'reference' was related turned out to be something in our own code, not OCIO.
///d@
On Wed, Apr 18, 2018 at 11:25 PM, Haarm-Pieter Duiker <li...@...> wrote: Cross posting for completeness
The document detailing ACES support in various applications, is here (read only):
If anyone is interested in updating the document for more current versions, let me know. I'd be happy to provide an editable link. Just message me.
For those interested in implementations, I think the Nuke nodes are supposed to be a reference. The OCIO Colorspace node creates the path from one colorspace to the next with this call m_processor = config->getProcessor(context, inputName, outputName);
which leads to this call to create a color space conversion processor->getImpl()->addColorSpaceConversion(*this, context, src, dst);
which eventually leads to this function BuildColorSpaceOps which takes two colorspaces and concatenates the source colorspace's to_reference (or inverse from_reference) transforms with the destination colorspace's from_reference (or inverse to_reference) transforms.
So... the code has it. The reference colorspace isn't the first colorspace. It isn't the space pointed to by the 'reference' role. It's the space that the config colorspace's various to_reference and from_reference transforms use as a target or as a source. Hopefully all the colorspace's in the config agree on that definition!
On Mon, Apr 16, 2018 at 12:38 AM, Abraham Schneider <abrah...@...> wrote: Hi there!
It seems like it's not just me that is unsure, how OCIO decides, which colorspace in a config is used as the reference space, that all other colorspaces are related to. And what excact purpose the 'reference' role has.
Could you maybe have a look at this and shine some light on this topic?
Thanks, Abraham
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
|
|
|
Dithermaster <dither...@...>
I've read the source. I didn't see anything special about the "first" colorspace. Unless someone can show me (either in the code or by an API call example) where it is somehow special, I won't believe it.///d@
On Fri, Apr 20, 2018 at 5:58 PM, <chris....@...> wrote: Hi folks-
H.P., I also agree with that definition. But - it's also true that if you are converting to or from the 1st colorspace in the config list (aka "Reference" colorspace) we should see the to_reference or from_reference transform (or inverse as-needed) applied alone. More specifically, we don't need to explicitly convert from colorspace A to Reference colorspace, then from Reference colorspace to colorspace B because the conversion from Reference to Reference is a non-op. So the OCIO ColorSpace isn't ignoring the reference colorspace in its conversion (as we can explicitly use it if desired), it's simply skipping the conversion from Reference<>Reference that is implied which seems to be standard OCIO behavior. Nevertheless I agree - it's up to the config author to accuratly define the to_reference and from_reference transforms.
From my view, the relevant issues that crop up are symptoms of inconsistent implementations, esp. where Roles are used for implied conversions in the host application.
For example, I can see that Nuke OCIO CDLTransform uses the "reference" ROLE assignment for converting to/from the "working space" assigned in the OCIO CDLTransform node. This is inconsistent, because for other standard operations Nuke honors the reference colorspace that is implied by the first colorspace in the config file. A Read node transforms colors from the Read node colorspace to the Project Settings working space, as do other standard Nuke nodes with colorspace assignments. Of course, we can set the Project Settings working space to the reference/1st colorspace if we want to, and the conversions still happen as expected.
As for the Roles in the config - some of them are used to populate the color Project Settings assignments for "working space," "log files," etc. when a given config file is first loaded. But when some plugins like OCIO CDLTransform use OCIO Roles in its own way, ignoring the Nuke color Project Settings, things are getting overly complicated.
From the source code comments:
ColorSpace Roles are used so that plugins, in addition to this API can have abstract ways of asking for common colorspaces, without referring to them by hardcoded names. All this considered, I conclude that the "reference" role should always be the "reference" (1st) colorspace in the config list. A few suggestions for improved behavior in the wild:
1. As users, get in the habit of setting the reference role to the 1st colorspace in the list. 2. OCIO sanity checks and ociocheck app should return an error if "reference" role is anything other the 1st colorspace. 3. Maybe - hardcode the "reference" role to the first colorspace in the list when configs are read in. I.e.: don't allow custom assignments. I expect some backlash for this suggestion - please don't rake me over the coals :) This at least enforces the intended usage.
-Chris
On Thursday, April 19, 2018 at 8:52:43 AM UTC-7, Dennis Adams wrote:Yes, I completely agree with that definition. My assertion that 'reference' was related turned out to be something in our own code, not OCIO.
///d@
On Wed, Apr 18, 2018 at 11:25 PM, Haarm-Pieter Duiker <li...@...> wrote:
Cross posting for completeness
The document detailing ACES support in various applications, is here (read only):
If anyone is interested in updating the document for more current versions, let me know. I'd be happy to provide an editable link. Just message me.
For those interested in implementations, I think the Nuke nodes are supposed to be a reference. The OCIO Colorspace node creates the path from one colorspace to the next with this call m_processor = config->getProcessor(context, inputName, outputName);
which leads to this call to create a color space conversion processor->getImpl()->addColorSpaceConversion(*this, context, src, dst);
which eventually leads to this function BuildColorSpaceOps which takes two colorspaces and concatenates the source colorspace's to_reference (or inverse from_reference) transforms with the destination colorspace's from_reference (or inverse to_reference) transforms.
So... the code has it. The reference colorspace isn't the first colorspace. It isn't the space pointed to by the 'reference' role. It's the space that the config colorspace's various to_reference and from_reference transforms use as a target or as a source. Hopefully all the colorspace's in the config agree on that definition!
On Mon, Apr 16, 2018 at 12:38 AM, Abraham Schneider <abrah...@...> wrote:
Hi there!
It seems like it's not just me that is unsure, how OCIO decides, which colorspace in a config is used as the reference space, that all other colorspaces are related to. And what excact purpose the 'reference' role has.
Could you maybe have a look at this and shine some light on this topic?
Thanks, Abraham
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-d...@....
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-d...@....
For more options, visit https://groups.google.com/d/optout.
|
|
|
Haarm-Pieter Duiker <li...@...>
Hey,
I came to the same conclusion. I had thought the first colorspace was the special ‘reference’ colorspace (pretty sure Jeremy told me that...), but there is nothing in the code enforcing or depending on that. As long as all the colorspace’s to and from transforms go to and from the same _implied_ reference colorspace, then the reference colorspace is effectively defined.
If you have a colorspace with no to or from transform list, which had better be what you think of as your reference space, it can at the front of the list, the end, or anywhere in between.
I think it is a good convention to - have a colorspace definition with no to or from transform lists to make the reference colorspace definition explicit - have that be the first colorspace - have the ‘reference’ role to point to that colorspace
All that said, these are currently suggested conventions. They aren’t hard requirements. I’d be in favor of making them hard requirements for a well formed config.
HP
On Fri, Apr 20, 2018 at 4:06 PM Dithermaster < dither...@...> wrote: I've read the source. I didn't see anything special about the "first" colorspace. Unless someone can show me (either in the code or by an API call example) where it is somehow special, I won't believe it.
--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
|
|
|
