Maya OCIO standard rule

[Derek Flood]

The color management section of Maya's Preferences, lists the "OCIO standard rule" which it says "assigns an input color space if its name appears in the image file name."

I'm hoping to get some more info about how that works exactly. The Maya manual says very little, and I do not see it mentioned in the OCIO docs. Could someone point me to something? Thanks!

[Troy Sobotka]

From the documents regarding strict parsing at http://opencolorio.org/userguide/config_syntax.html

“OCIO provides a mechanism for applications to extract the colorspace from a filename (the parseColorSpaceFromString API method)

So for a file like example_render_v001_lnf.0001.exr it will determine the colorspace lnf (it being the right-most substring containing a colorspace name)

However, if the colorspace cannot be determined and strictparsing: true, it will produce an error.

If the colorspace cannot be determined and strictparsing: false, the default role will be used. This allows unhandled images to operate in “non-color managed” mode.

Application authors should note: when no config is present (e.g. via $OCIO), the default internal profile specifies strictparsing=false, and the default color space role is raw. This means that ANY string passed to OCIO will be parsed as the default raw. This is nice because in the absence of a config, the behavior from your application perspective is that the library essentially falls back to “non-color managed”.

With respect,

TJS

On Wed, Feb 28, 2018, 3:40 PM Derek Flood <dere...@gmail.com> wrote:

The color management section of Maya's Preferences, lists the "OCIO standard rule" which it says "assigns an input color space if its name appears in the image file name."

I'm hoping to get some more info about how that works exactly. The Maya manual says very little, and I do not see it mentioned in the OCIO docs. Could someone point me to something? Thanks!

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

[Derek Flood]

Thanks Troy, that's helpful. I'm able to get it working now.

On a related note I was trying to create a color space with a name that can be used as a token in the filename like _dif_ and I'm noticing that if I set the input color space to sRGB it will do a degamma on the texture as desired, but if I have the exact same color space with a different name (in this case _dif_) it does not. For example:

  - !<ColorSpace>
    name: sRGB
    family: ""
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Standard RGB Display Space
    isdata: false
    allocation: uniform
    allocationvars: [-0.125, 1.125]
    to_reference: !<FileTransform> {src: srgb.spi1d, interpolation: linear}
 
  - !<ColorSpace>
    name: _dif_
    family: ""
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Standard RGB Display Space
    isdata: false
    allocation: uniform
    allocationvars: [-0.125, 1.125]
    to_reference: !<FileTransform> {src: srgb.spi1d, interpolation: linear}

Any idea what I may be missing?

[Troy Sobotka]

On Wed, Feb 28, 2018, 5:24 PM Derek Flood <dere...@gmail.com> wrote:

> On a related note I was trying to create a color space with a name that can be used as a token in the filename like _dif_ [...], but if I have the exact same color space with a different name (in this case _dif_) it does not.

Not entirely sure what your issue is here, but I will infer you are having problems with OCIO recognizing the colourspace in the 

Did you put a double underscore in before the d in dif in the filename? Such as foo__dif_.bar?

With respect,

TJS

[Derek Flood]

Thanks Troy. Sorry if I was unclear. It is not a matter of it recognizing the color space from the file name. This works fine. It's what the color space does to the texture file. When sRGB is selected the texture gets an inverse gamma correction, but when _dif_ is selected (even though the color space is identical other than the name) it does nothing. This is also the case if I manually choose the color space from the drop-down menu in a Maya file node.

[Troy Sobotka]

On Wed, Feb 28, 2018, 6:39 PM Derek Flood <dere...@gmail.com> wrote:

When sRGB is selected the texture gets an inverse gamma correction, but when _dif_ is selected (even though the color space is identical other than the name) it does nothing. This is also the case if I manually choose the color space from the drop-down menu in a Maya file node.

Sounds odd.

Try removing the underscores to see if there is some strange YAML / parsing issue first.

With respect,

TJS

[Derek Flood]

Will do. Let me change topic back to the filename issue...
If I have a color space named "_dif_" this will match all of these filenames:

Car_tire_dif_v01.png
Car_tire_dif_v01.jpg
Car_tire_dif_v01.tx

However I do not want it to match the tx file which is already linearized. Is there a strategy for dealing with that?

[Troy Sobotka]

On Thu, Mar 1, 2018, 7:31 AM Derek Flood <dere...@gmail.com> wrote:
> However I do not want it to match the tx file which is already linearized. Is there a strategy for dealing with that?

Label whatever transform is used as reference. foo_linear.exr for example.

TJS

[Derek Flood]

Yes I could do that. I was just hoping that there was a more sophisticated way of parsing things. For example to say that IF a file was a certain format (TX for example or EXR) it would always be linear/raw regardless of the filename.  Those kinds of color space rules are possible in Maya's color management, and I was hoping to be able to to do something similar with OCIO since it disables these color space rule options in Maya.