Path: ACEScg to regular sRGB? (Nuke 10.5v1, ACES 1.0.3)

Tags: #<Tag:0x00007f3c5cf52ec8> #<Tag:0x00007f3c5cf52d88> #<Tag:0x00007f3c5cf52c48>

(Nick Shaw) #13

See this is why I’m still confused. You don’t “see the colours in ACES”. You only ever look at ACES colours through a view transform, i.e. the RRT/ODT combination. And if you render through the same view transform the result should be the same thing you were viewing. I repeat, if things are set up correctly, the transform applied when you set the viewer to “sRGB (ACES)” and the one applied when you set the write node to “Output - sRGB” are exactly the same transform.

(Erwan Leroy) #14

I don’t know if I understand enough yet to be helpful, but I wanted to mention that by default my install of Nuke 10.5v1 with OCIO Aces_1.0.1 does not have any viewer LUT called sRGB (ACES) only sRGB D60 SIM (ACES).
Could it be that this specific viewer lut is custom and not matching the output one? (Like in my custom config last week we had a rec709 (ACES) which was actually custom and not doing the proper thing)

(Nick Shaw) #15

I believe the non “D60 sim” version of the sRGB ODT was added to OCIO in the ACES 1.0.3 version, which Frank says he is using.

(Erwan Leroy) #16

Nevermind, I was reading through the thread trying to find his version, didn’t see it anywhere, posted, then realized it was in the title.

(Francois Lord) #17

This is how you should setup your Nuke in order to work in ACES properly. The image read is in ACES2065-1, the viewer is set to sRGB as well as the write node. The output of the Write node will give the same result as in the viewer.

(Erwan Leroy) #18

Edit: I can see the yellow slot lost some saturation, I guess it is consistent with what Frank sees

(Left: sRGB created by Nuke’s color management from DPX, Middle: Nuke Viewer in sRGB (ACES), Right: Write out using Output - sRGB)

Color primaries shifting and Negative values (OCIO) confusion
(Nick Shaw) #19

That is the effect of the reverse/forward RRT I mentioned previously in this thread. It only affects particular saturated colours near the boundary of the sRGB unit cube, most noticeably yellows near {1.0, 1.0, 0.0}.

Frank has said that this is not the effect he is talking about. Notice the yellow patch is already desaturated in the Nuke viewer compared to the original, and the rendered image matches the Nuke viewer.

(Frank Jonen) #20

Indeed that’s what I’m seeing in the output, just not in the viewer.

To recap: My input is an EXR sequence from Modo at 32f, read as ACEScg, since it’s CG which if I got this right is correct usage.

My viewer is set to sRGB (ACES 1.0.3 config)

Throughout the comp I’m staying in ACEScg as all further inputs are read into this from the Modo renders. I even made the lettering in 32f and saved it as ACEScg (Affinity). So everything is the same.

When I set Nuke’s viewer to RAW and replicate the setup with a OCIODisplay node set to Output - sRGB I’m getting the exact same result as when I set the viewer to sRGB itself. The yellows aren’t desaturated there. When I put a write node right after that the out put is desaturated though. This output then looks like what I see when I set a Resolve session to ACEScc, load the exported ACES (export as ACES2065-1) sequence and set it to view as sRGB.

To verify it’s not a Nuke issue I replicated the same in Affinity Photo. It looks normal with the file set to ACEScg and viewed as sRGB. Once I convert to sRGB (same as export to file), I get the desaturation.

The odd thing however is: When I fix this in Resolve and export from there the colours look as they did in the viewer, even when I fix the saturation issue. So I don’t think that sRGB can’t represent it, but that there are difference approaches on going about it.

I’ve even considered making a couple of screenshots of the CMS Test Pattern at 100%, stitch them together and generate a LUT from there based on the difference between the write output and the screenshots. But that’s a bit of a last resort effort.

(Erwan Leroy) #21

So in the Nuke viewer it looks right, but after render it doesn’t?

Is there any screenshot you can do to illustrate the problem a bit better? (Not that I’m the best person to help you out, I’m also trying to wrap my head around ACES)

(mrrafs) #22

First time poster here. Hello.
From my limited tests and being in the same situation as yourself here is a summary of what i think i have learnt.

My first observation is that you say that you assume that your CG comes in as acesCg. Just checking that you have rendered your CG with textures and hdri’s that were in acesCg before going into Modo? I assume you are doing this in affinity with acesCG as your working space.

Also why go into ACES for the transfer file format? If the AcesCG primares are your widest gamut why complicate it with anything wider?

The ACES workflow always goes through the RRT when going to your ODT. This will create a slight ‘cast’ or look to the image. Others such as have taken the OCIO/ACES config’s, expanded them and removed the RRT. Going with transforms from the working space to the display space without going via the RRT. But i don’t know of any avaliable OCIO config’s out there that do this.

Also the standard gamma display lookups in nuke and other applications will not visualy match a workflow with AcesOCIO ODT’s (See my above link). There is no official config that does this. But the closest one if you were saving a jpeg would be: Utility - sRGB - Texture

I think I’ve got that all right, not guaranteeing It though :wink:

(Frank Jonen) #23

Thanks @mrrafs, indeed removing the RRT seems a good idea since it’s not all that great. I’ll have a look at Logarist.

I tried Utility - sRGB - Texture, the results were abysmal, to be kind. You can’t use that for app playback, the colours wash out and the gamma shoots way up. Output is probably not its intended use.

As for textures, in this case, since the mesh was auto-tesselated from a map, so the topology was absolute rubbish. Which is why I textured it entirely procedurally. I just stuck with ACES since I liked the way the image looked from Modo in Nuke. Bit of a fan of the sRGB D60 ‘look’ and the warmth it adds to the image, for my test scene at least. I dropped it for compatibility reasons since it seemed like it would be easier getting regular sRGB to work to begin with before experimenting deeper.

For the ACEScg to ACES2065-1, the workflow posts I’ve read on here so far stated that ACES2065-1 is the interchange format, it’s also the one of the two that looked right once I loaded it into Resolve (till I set the viewer to sRGB that is).

(Frank Jonen) #24

Here are two shots from my sequence. One from the map area and one from the temp intro.

The intro one with the fog (Nuke particle system with noise generators on cards for fog bits) shows what the cutoff does across the board. The blacks lift up, the blues lose their slight turquoise tint and the yellows pale.

The map shot shows this more drastically. A previously warm and inviting image turns into something closer to Arkham.

What I did for each render: use Output - sRGB to write the files. Nothing else. Yet they don’t match with the sRGB VLUT that supposedly also is Output - sRGB.

(mrrafs) #25

Here were my tests. I quickly rolled my own lut to compensate using ocio ‘looks’. But doing the adjustment before the ODT appears to slightly shift the colours.

comparison with look adjustment
comparison without look adjustment

(Erwan Leroy) #26

These definitely show a color shift, as well as a sharpen on the fog_shot.
In my test, while I was losing color doing a full sRGB>ACES>sRGB, my Nuke viewer and the final file were a match.
Could the viewer you’re using do its own black magic? (wondering where the sharpen comes from)
If you bring back the file into nuke, does it match?

(Nick Shaw) #27

I suspect the actual values in the file do match those in Nuke (bring it back in to check) but OS colour management is altering the way they are displayed. Nuke bypasses OS colour management and displays pixel values directly on the screen. Preview, for example, is colour space aware and will assume any image with no colour profile tag is sRGB. It will therefore modify the displayed pixel values to account for the difference between your display and an ideal sRGB display.

If you choose an sRGB display profile such as sRGB IEC61966-2.1 you are telling the OS that your display is already matched to sRGB, so no adjustment is needed. The images should then match.

However, you said previously that you do not see this effect when working in Nuke in legacy mode rather than ACES. The effect I describe should also occur then, as it is unrelated to ACES.

The sharpen could be down to scaling. Nuke’s viewer scaling (I believe) does no filtering, and simply skips pixels. Preview performs a filtered scale. This difference will affect perceived sharpness.

(Frank Jonen) #28

Sharpening definitely is scaling related. Nuke skips pixels when scaling as you said, Xee (image viewer I used) scales the image.

I think now we’re getting somewhere.
When I read the jpeg back in to Nuke it matches there. But I have to set the Read node to Output - sRGB.

This is the upper centre of the logo frame as that was one of the harsher points. Top is set to raw data to easily spot the seams. The only difference there is now, is the bit depth, so the JPEG shows dithering where the original doesn’t. This is pretty much what I want. Just, you know… outside of Nuke :wink:

So I guess I would need to make an ICC profile from which I then convert TO sRGB IEC61966-2.1 to get the same look back to the file.

I’m thinking along the lines of “assign profile X”, “convert to sRGB IEC61966-2.1” and save. This isn’t such a big deal since I can automate that stuff with a Batch script in Affinity (probably some command line tool?). Right now I just don’t have any idea what Profile X would be. But since I’m reading as Output - sRGB and my working space is ACEScg (is it ACEScg or am I just reading files into ACES2065-1?) it would be something along those lines. I’ll give it a shot tonight with ociobakelut and see what happens.

If that works, I just need to figure out how to make it work for ProRes output which is the next hurdle for me.

Indeed. When I write out a file using nuke_default, it looks the same outside of Nuke as it does within Nuke. I’m guessing that it writes a different kind of sRGB. A cleaner sRGB. I think there’s a step missing with the ACES workflow still. Like it writes the sRGB header but doesn’t fully transform the colours or something like that.

I’d certainly would like a less MacGyver-ish approach than having to convert after writing the file, when I don’t have to do that in an older workflow. Maybe another role like ‘Publish’ that does a full transform?

(Nick Shaw) #29

That is as expected.

You are in dangerous territory trying to make ICC profiles which invert unwanted effects. And all you will probably be able to do is to make a profile which makes them match ON YOUR MACHINE, but may well look utterly wrong on somebody else’s.

The problem with ICC colour management is that is implemented to greater and lesser extents in different applications and some, like Nuke, deliberately bypass it. Many perceived issues like QuickTime gamma problems are actually down to colour management doing what it “thinks” is correct to make the image “look right”, but this not tallying with the user’s expectations.

The safest solution would probably be to have a monitor with its own internal calibration to sRGB, and then set the profile on your computer to sRGB, i.e. tell it “don’t change anything, my monitor is accurate.”

(Frank Jonen) #30

Ok, good then. Just feels a bit weird to use an output as an input. Labels ¯\_(ツ)_/¯.

Yes and no. Mostly no in my case. If it looks right on an iPad display (regular, retina and P3 retina) I’m good. P3 retinas visually match what I’m seeing on my NEC MultiSync which is hardware set to sRGB at D65, then the rest is calibrated with an i1 Display Pro node.

The good thing about this, if it matches on one iPad, it’ll match on virtually all iPads of that type. I’m matching to P3 and live with what the earlier ones do as they’re being phased out. Well, except that new cheap one which has the old display, no coating and no P3 space.

That’s how my system is set up. I had it on wide gamut for a while but once someone doesn’t embed a colour profile everything just looks garish and pure red or green tones physically hurt to look at. After a year of that my tolerance for that was gone and I caved and set it to sRGB on the hardware side and calibrated everything to sRGB 2.1 spec.

QuickTime’s gamma issues are a fun and sordid tale indeed. When I write a ProRes4444, while not really RGB, I’m getting pretty much the same as when writing a JPEG though. So once I got that right, it’s not that much of a stretch to get the ProRes to look right. Once that looks right, Compressor does a good job in keeping the colours close to the ProRes intermediate.

Which is one of the reasons I’m testing with JPEGs, faster iteration since QuickTime player doesn’t auto update a file when it got overwritten. The other reason is that some parts actually end up as a JPEG sequence with a separate alpha channel.

Thank you for taking all that time BTW.

(Erwan Leroy) #31

Could it be a metadata/header mismatch? One tells you mac JPG viewer to apply the icc, the other to not apply it?

(Frank Jonen) #32

Yeah, that happened a lot to me in the past with some image editors that I tried back then. That was the first thing I checked. Bad profile? I’m a bit paranoid in that department I guess. :slight_smile:

I assigned a false colour profile and assigned the sRGB 2.1 profile right after to make sure it has the right profile. Just assigning, not converting to. Didn’t really change anything visually.