sRGB Jpeg use in ACEScg


If I want to use jpeg(sRGB) image from google into my ACEScg workspace, how can I set the OCIO colorspace?

I’m using the Nuke10.0v4 and my ACES config is aces_1.0.1.

Please help :slight_smile:

1 Like

Hi @edenan,

That would be the Utility - sRGB Texture colourspace.



I would say that depends.

When you chose Utility - sRGB Texture you bring the image into ACEScg but when then shown through the RRT/ODT it changes it’s look. Sometimes aceptable sometimes, definitely not. Especially when it comes to corporate identity colors and logos.

So if you have to preserve the actual look of the source image you have to invert the RRT/ODT. I don’t remember in which thread I learned that here in the forum, but the solution was to choose the Output sRBG (which is the RRT/ODT meant for Output transform) as Input.

Sounds strange, but that did the trick for me. This way I get ACEScg values that at the end of the chain look like the original sRGB image.


That would be that thread: Preserving the look of sRGB graphics

Thanks, @Peter_Rixner and @Thomas_Mansencal

The ‘Output - sRGB’ is worked for me.
Just in case, if I don’t need to match the color to corporate identity(original sRGB color), is ‘Utility - sRGB Texture’ the right way technically?


Yes, that would be! :slight_smile:

By the way …

Besides the “Utility - sRGB Texture” and “Input - Generic sRGB Texture” - which seem to be the same thing, I would have expected to be “Utility - Curve sRGB” the same thing also. But it isn’t.

What is that doing? Is there in general a documentation what all those do?


I found it :slight_smile:

So for everyone else who is looking for that:


  • Utility - Curve sRGB strictly applies a Colour Component Transfer Function (CCTF) of the sRGB colourspace, either the Opto-Electrical Transfer Function (OETF) or the Electro-Optical Transfer Function (EOTF) depending the direction.

  • Utility - Linear sRGB strictly performs a gamut change from ACES2065-1 primaries to Rec.709/sRGB primaries or the reverse depending the direction.

Here are the relevant definitions in the 1.0.3 OCIO config:

  - !<ColorSpace>
    name: Utility - Curve - sRGB
    family: Utility
    equalitygroup: Curve - sRGB
    bitdepth: 32f
    description: |
      The Curve - sRGB color space
    isdata: false
    allocation: uniform
    allocationvars: [0, 1]
    to_reference: !<FileTransform> {src: sRGB_to_linear.spi1d, interpolation: linear}

  - !<ColorSpace>
    name: Utility - Linear - sRGB
    family: Utility
    equalitygroup: Linear - sRGB
    bitdepth: 32f
    description: |
      The Linear - sRGB color space
    isdata: false
    allocation: lg2
    allocationvars: [-8, 5, 0.00390625]
    from_reference: !<GroupTransform>
        - !<MatrixTransform> {matrix: [0.952552, 0, 9.36786e-05, 0, 0.343966, 0.728166, -0.0721325, 0, 0, 0, 1.00883, 0, 0, 0, 0, 1]}
        - !<MatrixTransform> {matrix: [3.2096, -1.55743, -0.495805, 0, -0.970989, 1.88517, 0.0394894, 0, 0.0597193, -0.210104, 1.14312, 0, 0, 0, 0, 1]}



Perfect! Thanks! :slight_smile:


Technically, it depends.

If you have footage that self-describes as sRGB (or you know for sure that it is sRGB), the right way to import it into an ACES pipeline, is using an Inverse Output Transform from sRGB as Input Transform, therefore “Output - sRGB” is the way yo go. You know it is the right transform because, as you yourself noticed, that is the only way to go out of the ACES pipeline with an image preserving its original colorimetry. Short version of it: +1 -1 = 0

If, however, you don’t know what color-space the footage is in, (e.g. because it is stored in a color-unmanaged file format like PNG, GIF and even a metadata-less TIFF or a JPEG without embedded ICC profile), then Utility - sRGB Texture may be your best choice (you have a right choice, in this case, only if you can tell whcih source solor space the image is really in).
“Utility - sRGB texture”, however, was specifically made for importing such footage and adjust things like contrast, gamma and saturation. But you won’t get it back in its original colorimetry (also because no direct Output Transform exists for this “unspecified” colorimetry – at least in the OCIO ACES repository).

I hope this helps.


It’s really helpful to understanding about ACES workflow of sRGB image.

Would you mind if I have one more question?
In some of articles and tutorials, they used ‘Rec.709’ for Viewer LUT.
However, if I have a monitor that only supports the ‘sRGB’ color mode, can I use the ‘sRGB’ colorspace for Viewer LUT?


Hi Eden.
Yes, if your monitor “supports” sRGB you should in fact use sRGB in the viewer. If you use ACES in Nuke, however, it should read “sRGB (ACES)”, not just sRGB. Is OpenColorIO enabled?

Plase recall, however, that the fact your monitor “supports” a color-space, that generally doesn’t mean it is calibrated to match that space – sometimes not even remotely.

So a proper calibration is suggested out of every monitor before any color-critical operations with it. This is not an ACES recommendation of course: it is suggested best practice for any color work.

Hello Walter.
Thanks for your quick reply.

Yes. I’ve been using the monitor that calibrated to ‘sRGB’. Also I’m using the latest OpenColorIO in NUKE.
So what I said ‘sRGB’ means 'sRGB (ACES).
It is good news for me what you said. Because I just finished the ‘sRGB’ calibration of my crew computers few days ago :slight_smile:

I appreciate your help.