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

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)

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.
: https://groups.google.com/forum/#!topic/ocio-users/tgdKbhrJcdI

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 http://www.logarist.com/ 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:

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

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.

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

1 Like

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?

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.

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?

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

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.

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

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.

Logarist is not based on any OpenColorIO config nor on ACES. It’s my own take on color management; an alternative to ACES specifically for color correction.

I also have an OpenColorIO config that transforms from the working color space to the display color space without using the ACES RRT: ACES and ACEScc in Sony Vegas Pro - jbalazer It’s meant specifically for Vegas Pro and it’s compensating for the way that program maps video levels when reading and writing files. You might need to modify that for use in Nuke or wherever. Look for for the color space with name “Rec.709 still image file”. That’s ACES to Rec.709 without the ACES RRT.

2 Likes

ACES is a scene-referred color space and sRGB is a display-referred color space. You can’t go from scene-referred to display-referred without some kind of display rendering. sRGB doesn’t specify how display rendering should be performed. If you want to render to sRGB, you need to come up with your own display rendering.

ACES has an sRGB ODT, but it was never clear to me how they were doing the display rendering, and I always found the output to be unsuitable.

There’s already a standard and very common way of rendering output for a display: the BT.709 transform. Images rendered with the BT.709 transform will look correct on an sRGB display.

BT.709 doesn’t perform any kind of highlight compression to make up for the fact that standard displays aren’t very bright. So usually BT.709 is used with some additional transformation that compresses the highlights. In a camera that’s called a “knee”. In ACES it’s the ACES RRT. I find the ACES RRT to be far too aggressive. But you are under no obligation to use the ACES RRT. You can use straight Rec.709 like in my OpenColorIO config, and add whatever highlight compression curve you want.

1 Like

Thanks @balazer, I’ll give that a try next time I’m setting up another ACES test case. Right now I’m glad to be back in nuke_default for work where things are predictable and easy to control. Once that’s delivered I’ll play with ACES some more. Maybe the default config has matured a bit by then.

The thing is, when I make my own config and others do their own configs because the RRT isn’t suitable for much, it kind of defeats the purpose of ACES: To be a unified space where everyone participating knows it’ll work right when they get a package.

I’m glad you’re seeing the difference between display and output as well though.