Date   

Homebrew version of OCIO not bringing all apps ...

Abraham Schneider <abraham....@...>
 

I tried to create the original ACES 1.0.3 config from the included python folder via the 'create_aces_config' tool on my Mac. To do that, I installed all necessary tools via 'homebrew' (like 'ctl') and especially OCIO like it's mentioned on the website: 'brew install opencolorio --with-python'

Unfortunately the 'create_aces_config' script won't run successfully because it can't find the tool 'ociolutimage'. Would be cool if the homebrew version of OCIO would install all the tools that are available in 'https://github.com/imageworks/OpenColorIO/tree/master/src/apps', so it would be easy to create the ACES reference config easily on your own. 


Re: no function in (Python) API to get colorspace of defined role?

Abraham Schneider <abraham....@...>
 

Seems to work, thanks. Not quite obvious from the documentation, especially if you only look at the API docs and not the user guide first.

Am Montag, 28. Mai 2018 16:39:02 UTC+2 schrieb Sean Cooper:

Not at a computer to verify, but I believe you can just do a getColorspace() call using the user defined or default roles, the query the name of the returned object. Role names are equivalent to color space names. Its a bit obtuse I must admit.

On Mon, 28 May 2018, 3:21 pm Abraham Schneider, <abrah...@...> wrote:
Just had a look in the Python API and wondered how I could get the referenced colorspace of a named role. Some of the roles are predfined as constants (OCIO.Constants.ROLE_...), but what's with user defined roles? So for example the compositing_linear one in the ACES config, or a self defined one?

Shouldn't there be just an easy function like 'getRole(rolename)' that just gives back the name of the colorspace that the role is linking to!?

Really confused at the moment on how to use roles via API.

Thanks!

--
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.


Re: no function in (Python) API to get colorspace of defined role?

Sean Cooper <se...@...>
 

Not at a computer to verify, but I believe you can just do a getColorspace() call using the user defined or default roles, the query the name of the returned object. Role names are equivalent to color space names. Its a bit obtuse I must admit.


On Mon, 28 May 2018, 3:21 pm Abraham Schneider, <abraham....@...> wrote:
Just had a look in the Python API and wondered how I could get the referenced colorspace of a named role. Some of the roles are predfined as constants (OCIO.Constants.ROLE_...), but what's with user defined roles? So for example the compositing_linear one in the ACES config, or a self defined one?

Shouldn't there be just an easy function like 'getRole(rolename)' that just gives back the name of the colorspace that the role is linking to!?

Really confused at the moment on how to use roles via API.

Thanks!

--
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.


no function in (Python) API to get colorspace of defined role?

Abraham Schneider <abraham....@...>
 

Just had a look in the Python API and wondered how I could get the referenced colorspace of a named role. Some of the roles are predfined as constants (OCIO.Constants.ROLE_...), but what's with user defined roles? So for example the compositing_linear one in the ACES config, or a self defined one?

Shouldn't there be just an easy function like 'getRole(rolename)' that just gives back the name of the colorspace that the role is linking to!?

Really confused at the moment on how to use roles via API.

Thanks!


Re: Which colorspace is used as the reference space for an OCIO config?

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.

///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.

--
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.

--
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.


Re: Which colorspace is used as the reference space for an OCIO config?

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.

--
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.


Re: Which colorspace is used as the reference space for an OCIO config?

chris....@...
 

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.


Re: Which colorspace is used as the reference space for an OCIO config?

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!



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.

--
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.


Re: Which colorspace is used as the reference space for an OCIO config?

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.


Re: Implement Open Color IO in Maya and 3ds Max

Patrick Hodoul <patric...@...>
 

Hi Marion,

 

Maya supports OCIO as synColor embeds the OCIO library for config file reading.


Below are some links explaining the OCIO support in Maya & Arnold:

Maya -> https://knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2017/ENU/Maya/files/GUID-A5A2B5C8-7992-41E3-8482-9DD86EC89717-htm.html

Arnold -> https://arnold-rendering.com/2017/06/01/color-management-in-arnold-for-maya/


Here is the command to query/edit the Color Management settings in Maya:

https://help.autodesk.com/cloudhelp/2017/ENU/Maya-Tech-Docs/Commands/colorManagementPrefs.html

 

Having an OCIO config file at Maya startup could be done by setting the OCIO env. variable to a specific config file before starting Maya.


Regards,

Patrick.


On Tuesday, April 17, 2018 at 4:42:44 PM UTC-4, marion michon wrote:
Hello,

I would like to implement OpenColor IO in Maya and 3ds Max at startup.

Can you explain me how can I do that from Python please ? 
The goal is that Open Color IO will be implemented at startup of each software, i'm using Vray for both of them so if you can help me, I would be grateful !

Thanks,
Best regards,
Marion


Implement Open Color IO in Maya and 3ds Max

marion michon <marion...@...>
 

Hello,

I would like to implement OpenColor IO in Maya and 3ds Max at startup.

Can you explain me how can I do that from Python please ? 
The goal is that Open Color IO will be implemented at startup of each software, i'm using Vray for both of them so if you can help me, I would be grateful !

Thanks,
Best regards,
Marion


Re: Digest for oci...@googlegroups.com - 1 update in 1 topic

Haarm-Pieter Duiker <li...@...>
 

Thanks for the clarification. I’ll make sure that the team working on the next iteration of the ACES config is aware and addresses this. It’s a one line fix. 

HP
Author of the ACES config




On Tue, Apr 17, 2018 at 2:18 AM dbr/Ben <dbr....@...> wrote:
The reference role doesn't appear to be used anywhere inside OCIO itself. The choice of a reference space is just an choice when creating all your transforms. That said, it is a good idea to specify this role for people reading the config, and some applications "could" potentially use it (but setting it to something weird like "utility - raw" would work technically fine, it is only confusing)

The suggestions in that thread of "it's the first colorspace" is probably just because the example SPI config a happen to specify their "lnf" space first. However this is mistaken - there is nothing special about the first defined space.

I would suspect whoever created the ACES config misinterpreted the "reference" role as "what space to use for reference footage"

The meaning of the default roles are defined here:

http://opencolorio.org/userguide/config_syntax.html#roles

As you say, the reference role should be set to the main ACES space, as that is what the other spaces are defined relative to

These meanings should be a bit easier to find (e.g in the C++ API docs and Python bindings too) - made ticket for this,

On 17 Apr 2018, at 17:50, Abraham Schneider <abraham....@...> wrote:

Hi there!

Thanks for your answer. The reason for a reference colourspace and the 'star topology' of the colorspaces is perspicous for me. I was just wandering, why the ACES 1.0.3 config has at least 2 colourspace that are missing all 'from' and 'to' transforms (and in this definition would both be THE reference), why the 'reference' role points to 'Utility - Raw' and not to 'ACES2065-1' and why these two spaces have different allocation vars.

And in the discussion on the ACES page now there is the uncertainty, if the reference role defines the reference space or some other logic, because there needs to be a logic which space definition will be used when there are more than one that misses all from/to definitions.

Abraham

Am Dienstag, 17. April 2018 06:17:04 UTC+2 schrieb bsloan:
Hi Abraham,

The reference colorspace is the one that every colorspace defined in the config converts from (or to). It may or may not be defined in the config. If it does, the to_reference and from_reference transforms for the reference colorspace are necessarily null.

As for the purpose of having a reference colorspace, one cannot simply take a bunch of pixel values and transform them to colorspace X without knowing the colorspace associated with the incoming pixel values -- a transformation requires well-defined source and destination colorspaces.

Within ocio, a conversion from colorspace X to colorspace Y is built by concatenating colorspace X's from_reference and colorspace Y's to_reference*.

The alternative to having a reference colorspace would be for the config to define transformations from each colorspace in the config to every other colorspace in the config, which I think is N! entities instead of N. 

The ACES 1.0.3 config uses ACES-2065 as its reference colorspace, but a custom config could as easily define all of it's colorspaces in terms of an ACEScg reference or some camera vendor's encoding and gamut.

*most ocio colorspaces are invertible so they need only provide a from_ or a to_.

Hoping this is helpful.

--
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.

--
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.


Re: Digest for oci...@googlegroups.com - 1 update in 1 topic

dbr/Ben <dbr....@...>
 

The reference role doesn't appear to be used anywhere inside OCIO itself. The choice of a reference space is just an choice when creating all your transforms. That said, it is a good idea to specify this role for people reading the config, and some applications "could" potentially use it (but setting it to something weird like "utility - raw" would work technically fine, it is only confusing)

The suggestions in that thread of "it's the first colorspace" is probably just because the example SPI config a happen to specify their "lnf" space first. However this is mistaken - there is nothing special about the first defined space.

I would suspect whoever created the ACES config misinterpreted the "reference" role as "what space to use for reference footage"

The meaning of the default roles are defined here:

http://opencolorio.org/userguide/config_syntax.html#roles

As you say, the reference role should be set to the main ACES space, as that is what the other spaces are defined relative to

These meanings should be a bit easier to find (e.g in the C++ API docs and Python bindings too) - made ticket for this,

On 17 Apr 2018, at 17:50, Abraham Schneider <abraham....@...> wrote:

Hi there!

Thanks for your answer. The reason for a reference colourspace and the 'star topology' of the colorspaces is perspicous for me. I was just wandering, why the ACES 1.0.3 config has at least 2 colourspace that are missing all 'from' and 'to' transforms (and in this definition would both be THE reference), why the 'reference' role points to 'Utility - Raw' and not to 'ACES2065-1' and why these two spaces have different allocation vars.

And in the discussion on the ACES page now there is the uncertainty, if the reference role defines the reference space or some other logic, because there needs to be a logic which space definition will be used when there are more than one that misses all from/to definitions.

Abraham

Am Dienstag, 17. April 2018 06:17:04 UTC+2 schrieb bsloan:
Hi Abraham,

The reference colorspace is the one that every colorspace defined in the config converts from (or to). It may or may not be defined in the config. If it does, the to_reference and from_reference transforms for the reference colorspace are necessarily null.

As for the purpose of having a reference colorspace, one cannot simply take a bunch of pixel values and transform them to colorspace X without knowing the colorspace associated with the incoming pixel values -- a transformation requires well-defined source and destination colorspaces.

Within ocio, a conversion from colorspace X to colorspace Y is built by concatenating colorspace X's from_reference and colorspace Y's to_reference*.

The alternative to having a reference colorspace would be for the config to define transformations from each colorspace in the config to every other colorspace in the config, which I think is N! entities instead of N. 

The ACES 1.0.3 config uses ACES-2065 as its reference colorspace, but a custom config could as easily define all of it's colorspaces in terms of an ACEScg reference or some camera vendor's encoding and gamut.

*most ocio colorspaces are invertible so they need only provide a from_ or a to_.

Hoping this is helpful.

--
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.


Re: Digest for oci...@googlegroups.com - 1 update in 1 topic

Abraham Schneider <abraham....@...>
 

Hi there!

Thanks for your answer. The reason for a reference colourspace and the 'star topology' of the colorspaces is perspicous for me. I was just wandering, why the ACES 1.0.3 config has at least 2 colourspace that are missing all 'from' and 'to' transforms (and in this definition would both be THE reference), why the 'reference' role points to 'Utility - Raw' and not to 'ACES2065-1' and why these two spaces have different allocation vars.

And in the discussion on the ACES page now there is the uncertainty, if the reference role defines the reference space or some other logic, because there needs to be a logic which space definition will be used when there are more than one that misses all from/to definitions.

Abraham

Am Dienstag, 17. April 2018 06:17:04 UTC+2 schrieb bsloan:

Hi Abraham,

The reference colorspace is the one that every colorspace defined in the config converts from (or to). It may or may not be defined in the config. If it does, the to_reference and from_reference transforms for the reference colorspace are necessarily null.

As for the purpose of having a reference colorspace, one cannot simply take a bunch of pixel values and transform them to colorspace X without knowing the colorspace associated with the incoming pixel values -- a transformation requires well-defined source and destination colorspaces.

Within ocio, a conversion from colorspace X to colorspace Y is built by concatenating colorspace X's from_reference and colorspace Y's to_reference*.

The alternative to having a reference colorspace would be for the config to define transformations from each colorspace in the config to every other colorspace in the config, which I think is N! entities instead of N. 

The ACES 1.0.3 config uses ACES-2065 as its reference colorspace, but a custom config could as easily define all of it's colorspaces in terms of an ACEScg reference or some camera vendor's encoding and gamut.

*most ocio colorspaces are invertible so they need only provide a from_ or a to_.

Hoping this is helpful.


Re: Digest for ocio...@googlegroups.com - 1 update in 1 topic

Blake Sloan <bsl...@...>
 

Hi Abraham,

The reference colorspace is the one that every colorspace defined in the config converts from (or to). It may or may not be defined in the config. If it does, the to_reference and from_reference transforms for the reference colorspace are necessarily null.

As for the purpose of having a reference colorspace, one cannot simply take a bunch of pixel values and transform them to colorspace X without knowing the colorspace associated with the incoming pixel values -- a transformation requires well-defined source and destination colorspaces.

Within ocio, a conversion from colorspace X to colorspace Y is built by concatenating colorspace X's from_reference and colorspace Y's to_reference*.

The alternative to having a reference colorspace would be for the config to define transformations from each colorspace in the config to every other colorspace in the config, which I think is N! entities instead of N. 

The ACES 1.0.3 config uses ACES-2065 as its reference colorspace, but a custom config could as easily define all of it's colorspaces in terms of an ACEScg reference or some camera vendor's encoding and gamut.

*most ocio colorspaces are invertible so they need only provide a from_ or a to_.

Hoping this is helpful.


On Mon, Apr 16, 2018, 1:34 PM <ocio...@...> wrote:
Topic digest
View all topics
Abraham Schneider <abraham....@...>: Apr 16 12:38AM -0700

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
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to ocio-dev+u...@....


Which colorspace is used as the reference space for an OCIO config?

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


Re: Converting Primaries

Breadbox <markel.j...@...>
 

Thank you all, after searching around I stumbled upon the site Sean mentioned and ended up using it. They were PCS-relative XYZ values for AdobeRGB in case anyone was wondering. Here's another site I also found that works for XY values. Not as sophisticated but it seems to work. 


On Monday, March 26, 2018 at 12:32:16 PM UTC-5, Sean Cooper wrote:

On Mon, Mar 26, 2018 at 5:34 PM, Troy Sobotka <troy...@...> wrote:
On Mon, Mar 26, 2018, 9:22 AM Jim Houston, <jim....@...> wrote:

I checked for the first (to new primaries) and third (to ACES) Matrix Transforms and they match conversion of the colorspace to XYZ.  I did not check for the middle XYZ adaptation Matrix (my spreadsheet doesn’t include that.)

Thanks so much for the check Jim!

With respect,
TJS

--
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.


Re: Digest for ocio...@googlegroups.com - 6 updates in 2 topics

tony cole <ton...@...>
 

Hi,
This is likely a very old request.
I am charged with setting up a global config for a new startup.
I am basing the .ocio on aces1.0.3
I'm confused on how to customise profiles, looks etc ... I do not need half of the colourspaces, ie; dolby ...
Any advice from all of you would be greatly appreciated !
Thanks

On 27 March 2018 at 04:32, <ocio...@...> wrote:
Topic digest
View all topics
chris....@...: Mar 12 10:43AM -0700

Hi Sean,
 
Would you please add me as well?
 
chris....@...
 
Thanks!
-Chris Davies
Sean Cooper <se...@...>: Mar 26 06:34PM +0100

Luis, Chris added.
 
If someone could make a Slack invite bot that would be useful :)
 
Troy Sobotka <troy.s...@...>: Mar 26 02:23AM

Not sure if you got help here Markel.
 
I managed to craft up a spreadsheet that should work. Should being that it
hasn't been tested extensively and that you'll need to manually make your
OCIO stanzas from the provided entries. This isn't nearly as terrific as
Colour, but I realize not everyone has Python handy, and a sort of "online
calculator" probably couldn't hurt as I found myself doing the adaptation
frequently.
 
https://docs.google.com/spreadsheets/d/1qB1YVuQFTlAKeRLyQXtOJalbZQv3V1vRPXBywqIGV_o/edit?usp=sharing
 
I've input the values you gave along with ACES AP0 primaries. The chromatic
adaptation is the Bradford CAT. The OpenColorIO stanzas appear on the final
three lines. Those should be suitable to copypasta into a configuration as
part of a group transform. Note that your source buffer will need to be
linearized however appropriate for your encoded image.
 
Let me know if anyone spots a mistake.
 
With respect,
TJS
 
Jim Houston <jim.h...@...>: Mar 25 11:38PM -0700

I checked for the first (to new primaries) and third (to ACES) Matrix Transforms and they match conversion of the colorspace to XYZ. I did not check for the middle XYZ adaptation Matrix (my spreadsheet doesn’t include that.)
 
Jim
 
 
Troy Sobotka <troy.s...@...>: Mar 26 04:34PM

On Mon, Mar 26, 2018, 9:22 AM Jim Houston, <jim.h...@...>
wrote:
 
> Transforms and they match conversion of the colorspace to XYZ. I did not
> check for the middle XYZ adaptation Matrix (my spreadsheet doesn’t include
> that.)
 
Thanks so much for the check Jim!
 
With respect,
TJS
Sean Cooper <se...@...>: Mar 26 06:32PM +0100

I'd also point you here:
http://colour-science.org/cgi-bin/rgb_colourspace_models_transformation_matrices.cgi
 
On Mon, Mar 26, 2018 at 5:34 PM, Troy Sobotka <troy.s...@...>
wrote:
 
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to ocio-dev+unsubscribe@googlegroups.com.


Re: Slack invite

Sean Cooper <se...@...>
 

Luis, Chris added.

If someone could make a Slack invite bot that would be useful :)

On Mon, Mar 12, 2018 at 5:43 PM, <chris....@...> wrote:
Hi Sean,

Would you please add me as well?


Thanks!
-Chris Davies

--
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.


Re: Converting Primaries

Sean Cooper <se...@...>
 

On Mon, Mar 26, 2018 at 5:34 PM, Troy Sobotka <troy.s...@...> wrote:
On Mon, Mar 26, 2018, 9:22 AM Jim Houston, <jim.h...@...> wrote:

I checked for the first (to new primaries) and third (to ACES) Matrix Transforms and they match conversion of the colorspace to XYZ.  I did not check for the middle XYZ adaptation Matrix (my spreadsheet doesn’t include that.)

Thanks so much for the check Jim!

With respect,
TJS

--
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.

461 - 480 of 2147