Color Spaces for EXRs do not work as expected Tweet

[Deepwell]

When rendering in Modo and saving as PNG with sRGB Color Space the image looks the same when importing into Nunke (with Inpout Transform set to Output-sRGB).

But when saving as 16-bit EXR and setting the Color Space toe ACES-ACEScg - and then setting the input transform in Nuke also to ACES - ACEScg) the image look very different.

In the comparison image the upper left is the PNG (which looks like in Modo). The lower right is the EXR.

I also attached screenshots of the export settings in Modo and the import settings in Nuke.

Anyone any idea what I am doing wrong?

[elsksa]

Hi,

When rendering in Modo and saving as PNG with sRGB Color Space the image looks the same when importing into Nunke (with Inpout Transform set to Output-sRGB).

First of all, PNG shouldn't even be considered.
Literally no reason and explained further on this page. Bonus, that's one less issue to deal with.
The input transform shouldn't be the output ODT, but as the name suggests the IDT (in ACES but also universally). The input source is conventionally Linear-ACEScg or Linear-sRGB in a non-ACES pipeline.

For the sake of trouble solving, what were the Octane export settings for the PNG export?

ACES isn't a necessity, that would simplify the whole pipeline and yield superior results by avoiding it. This page explains further on the topic. Other pages from that site go further on the subject.

[Deepwell]

Hey elsksa,
thx for you reply!

"Literally no reason" is a bold claim in this vast world of DCC applications and workflows - but I will certainly not spend time defendig a file format

I normally do not render to PNG, always EXR. This is my first project with Octane. As I was not able to see in Nuke what I see in Modo with EXRs, I switched to PNG and that at least works.

For the sake of trouble solving, what were the Octane export settings for the PNG export?

See the screenshot "PNG export settings" in the original post.


As to color spaces:

The input transform in Nuke must be set to the color space the file is encoded in. If that is an ACES Input Space (like of some camera), then yes, it should be set to that input color space. But if the file is already encoded in an output color space (like sRGB for a PNG), then the Input Transform in Nuke must be set to that output color space to read the data in correctly - as counter-intuitive as this might sound.

I am working with ACES happily and successfully in my usual setup (Houdini with Redshift and Nuke) - no problem there.

When I display a rendered image in Houdini with an sRGB display transform and write it out in ANY color space, I can read it in to Nuke, set that color space for the input transform and as long as the display transform in Nuke is set to the same as in Houdini, I see the same result.

But in this case even when I write the file to EXR in ACEScg space and read it into Nuke with that very input transform, the result is still different - which IMHO should not be the case.

When I export to PNG (in sRGB space) and read it in (with sRGB input transform) in Nuke, all is good (looks the same in Nuke as it looks in Modo).


So, I would love to not use PNGs and use EXRs instead (as I usually do) – if someone can tell me the right export settings in Octane/Modo and the right input transform in Nuke, I'd be happy to give it a try.

[elsksa]

"Literally no reason" is a bold claim in this vast world of DCC applications and workflows - but I will certainly not spend time defendig a file format

The file format page page I sent explains why.

The input transform in Nuke must be set to the color space the file is encoded in. If that is an ACES Input Space (like of some camera), then yes, it should be set to that input color space. But if the file is already encoded in an output color space (like sRGB for a PNG), then the Input Transform in Nuke must be set to that output color space to read the data in correctly - as counter-intuitive as this might sound.

I am well familiar with ACES. I was referring to EXR encoding. I should have been more specific.

I am working with ACES happily and successfully in my usual setup (Houdini with Redshift and Nuke) - no problem there.

Some sections (such as)briefly cover the misconceptions surrounding ACES that is factually and unarguably flawed, this is in fact well known but not widely discussed as much as it should.

So, I would love to not use PNGs and use EXRs instead (as I usually do) – if someone can tell me the right export settings in Octane/Modo and the right input transform in Nuke, I'd be happy to give it a try.

PNG is an integer file format, the 16 bit option is widely different from EXR 16-bit as the latter is floating point. On a simple scene with a small dynamic range lighting it may not seem obvious, but is unavoidable and demonstrated on the file format page I linked.

How is your OCIO View/Display set in Nuke?
I am suspecting for being the cause.
Depending on it, it may be necessary to check a case named "raw data" to avoid a double transform

[Deepwell]

Hey elsksa,
my view transform in Nuke is set as it always is - either sRGB or Rec709 - depending on the Monitor I am viewing with (I don't have an HDR display).

As soon as the data is correctly transformed from the file's color space to Nuke's internal color space (by applying the appropriate input transform in the Nuke reader node), all should be fine. As said, I read EXRs from RedShift and Video Files from various cameras into Nuke all the time and as soon as I apply the correct input transform it looks in Nuke like it looks everywhere else.

An when I apply the correct input transform to the PNGs (Output/sRGB, as that is what the PNGs are encoded in) then, as usual, all looks fine and the same as in Modo. Just when I read in the EXRs generated by Octane, even when setting the input transform to ACEScg (the color space I set when writing the EXRs in Modo/Octane and hence the one they should be encoded in), it does not look the same as in Modo...

J.

[funk]

I don't use Nuke, but tested this in fusion and it looks correct with a simple textured area light.

In this fusion comparison, I'm using no view LUT.
Left = modo viewport, Octane plugin 2023.1.1.196 (using imager > ACES tone mapping)
Right, Top left = EXR16 (saved as ACEScg). Piped through an OCIO node with Source Space = ACES - ACEScg, Output Space = Output - sRGB.
Right, Bottom right = PNG8 (saved as sRGB) with no input/output transform at all

I'm guessing you have a setup problem in Nuke. I can't see an output space setting in your Nuke screenshots. It looks like you entire viewport is going through an sRGB view (?), but the EXR and PNG will need different output space settings.

EDIT: The fact your PNG has "output - sRGB" as the input transform makes me think your setup might be wrong. Not sure, because that's an output transform from the ACES config. If your viewport is set to Output - sRGB though, it would look correct. I just don't know how Nuke works.

[funk]

I need to add a note here about saving PNGs with Octane. I only noticed this while testing the 2 different ways you can use ACES in Octane.

If you are using an ACES OCIO config with imager > OCIO view = "ACES: sRGB", you need to select color space = "Output - sRGB" when saving to PNG.
Selecting color space = "sRGB" will produce the wrong result.

If you are using the imager > ACES Tone mapping checkbox instead, both color space = "sRGB" or "Output - sRGB" will work for PNG saving. (NOTE: they only show up if you have a config loaded)

This seems to be some sort of quirk...

I don't recommend using PNGs, but its good to be aware of this so your comparisons between the EXR and PNG are correct.

[elsksa]

Frankly, I must insist on putting efforts on trouble solving with EXR or TIFF.
Not even for the sake of trouble solving is PNG worth it.

It is quite counter intuitive to linearly master output as PNG by nature in an integer encoding specification.

Octane output has no known issue to my knowledge. It is as simple as:
Linear sRGB (or ACEScg) EXR with the compression that best fit the post software and context.
TIFF are ideally exported as log encoded, although master output should preferably be EXR.
For preview purposes, JPG it is.

[Deepwell]

Hey funk,
thx for your reply.

Your hint with the Imager settings in Modo led my to the right place and I found the culprit!

In the Imager settings of Octane in Modo there are two different sRGB settings: "None (sRGB)" and "ACES: sRGB" – those are NOT the same!

I had the former, but need the latter.

Once the view transform in Modo is set correctly to the same I have in Nuke (both "ACES sRGB") all is good!!!

Now this workflow works as expected:

• Display the image in Modo with a specific view transform (Imager settings OCIO View) - e.g. "ACES sRGB" (if that is the appropriate for your monitor)
• Save the image in any file format in any color space
  (can be PNG with "Output - sRGB" or an EXR with "ACEScg", or...)
• Load the image into Nuke and set as the input transform in the reader node that very same color space
  (that way the data get's "decoded" and transformed into Nukes internal color space)
• Make sure your viewer transform in Nuke is set to the same as the Imager OCIO View setting in Modo/Octane

Then everything is peachy

As to the choice of image format and color space:
The choice of image format and/or color space has influence on the quality of the image transfer (which colors can be transferred at all and in what quantisation/bit-depth) - but the overall look of the image should stay the same. There can be banding etc. (if the quantisation of the specific colors that are used is insufficient) and there can be issues if extreme color values cannot be represented by the data type of the format (e.g. values > 1 or < 0 in an integer format) - but apart from that in my view there is no wrong format or color space.

That being said, I absolutely prefer floating point formats (like EXR)! There were also external reasons to use PNG (an integer format) in this particular case...
(let alone that EXRs also offer layers, overscan, etc.)


@funk - as to your Fusion setup:
When reading in the image with the OCIO node and transforming it to sRGB that means that you then also have sRGB as your working color space - meaning that Fusion will apply all it's operations on data in that color space, which I think is not ideal. If you do that, you of course need a neutral viewer transform on an sRGB monitor - the data already is sRGB...

I personally prefer to transform the data into a linear working color space (a must in Nuke!) and apply an appropriate viewer transform, just to see the image correctly. That way all the nodes operate on linear data, which I think also in Fusion is as intended and makes dialling in values feel more natural - and also most nodes operate better on such data (keyers, filters, glows, ...). And in the end of course apply an appropriate transform when writing the data out.


All in all: It works not as expected for me and many thanks to everyone for your time and help!!

Cheers!
Johannes


PS: To finally confuse everyone totally: The fact it worked with the PNGs even with the wrong Imager setting is just because for the PNGs I also chose the wrong output transfer ("sRGB" instead of "ACES sRGB") - which compensated for the wrong view transform...

I need to add a note here about saving PNGs with Octane. I only noticed this while testing the 2 different ways you can use ACES in Octane.

If you are using an ACES OCIO config with imager > OCIO view = "ACES: sRGB", you need to select color space = "Output - sRGB" when saving to PNG.
Selecting color space = "sRGB" will produce the wrong result.

If you are using the imager > ACES Tone mapping checkbox instead, both color space = "sRGB" or "Output - sRGB" will work for PNG saving. (NOTE: they only show up if you have a config loaded)

This seems to be some sort of quirk...

I don't recommend using PNGs, but its good to be aware of this so your comparisons between the EXR and PNG are correct.

[elsksa]

As to the choice of image format and color space:
The choice of image format and/or color space has influence on the quality of the image transfer (which colors can be transferred at all and in what quantisation/bit-depth) - but the overall look of the image should stay the same. There can be banding etc. (if the quantisation of the specific colors that are used is insufficient) and there can be issues if extreme color values cannot be represented by the data type of the format (e.g. values > 1 or < 0 in an integer format) - but apart from that in my view there is no wrong format or color space.

There undeniably is. It's further explained in the previously shared links.

That being said, I absolutely prefer floating point formats (like EXR)! There were also external reasons to use PNG (an integer format) in this particular case...
(let alone that EXRs also offer layers, overscan, etc.)

TIFF and JPG are once again undoubtedly better suited as integer formats. It isn't much about preferences but requisite.

I personally prefer to transform the data into a linear working color space (a must in Nuke!) and apply an appropriate viewer transform, just to see the image correctly.

The data is not "transformed" as it that's how it was encoded originally and that's indeed the proper way.

Good to know where the issue was originating from and all has been sorted out.