View transform as LUT highlight clipping issues

Discussions - Using ACES
1

Hello,
I am currently working on developing an ACES 1.3 workflow for Photoshop and After Effects with LUTs used to apply my transformations, and am running into an issue. My working space in both AE and PS is AcesCG, so I need to create a view transform to display AcesCG correctly in sRGB (this is after AE and PS’ built in view transforms have been disabled, so prior to applying the AcesCG > sRGB view transform I am viewing the raw ACES color). I have tried generating LUTs to use as my view transform using the following techniques, and all but one result in clipping/altering of the highlights when used as the view transform (said clipping can be seen in the attached images):

clippingdemo
clippingdemo1108×707 212 KB

unclippeddemo
unclippeddemo975×590 156 KB

LUT Generation techniques that result in clipping-
Nuke 14 node tree (cg-config-v.1.0.0_aces-v1.3_ocio-v2.0):
CMS Test pattern node (Cube size: 64) → OCIO Color Space node (In: AcesCG; Out: Output - sRGB) → Generate LUT node (preLUT size: 1024; linear [have also tried Logarithmic])

Nuke 14 node tree (cg-config-v.1.0.0_aces-v1.3_ocio-v2.0):
CMS Test pattern node (Cube size: 64) → OCIO Display node (In: AcesCG; Display: sRGB; View: ACES 1.0 SDR Video) → Generate LUT node (preLUT size: 1024; linear[have also tried Logarithmic])

Photoshop with fnord OCIO Plugin (cg-config-v.1.0.0_aces-v1.3_ocio-v2.0 [edited - see below]):
(Export) Convert- In: AcesCG; Out: ACES 1.0 SDR Video (added this display view transform by editing the config as per DisplayViewTransforms for output? · Issue #82 · AcademySoftwareFoundation/OpenColorIO-Config-ACES · GitHub)

Photoshop with fnord OCIO Plugin (cg-config-v.1.0.0_aces-v1.3_ocio-v2.0):
(Export) Display- In: AcesCG; Display: sRGB; View: ACES 1.0 SDR Video

LUT Generation Technique that does not clip:
Photoshop with fnord OCIO Plugin (ACES 1.2 OCIO 1.0 config from colour-science repository):
(Export) Convert- In: AcesCG; Out: Output - sRGB

The way that these LUTs are being applied to where the clipping occurs is as follows:
Photoshop (2023)-

  1. Open 32bit ACEScg image rendered from V-Ray in Maya using OCIO 2.0 ACES 1.3
  2. Edit > Assign profile > ACEScg ACES Working Space AMPAS S-2014-004
  3. Create LUT adjustment layer at top of layer stack to invert Photoshop’s view transform (sRGB Texture → ACEScg) – LUT created with cg-config-v.1.0.0_aces-v1.3_ocio-v2.0, either from Nuke or fnord OCIO Photoshop plugin
  4. Raw ACEScg colors are now seen, so I need a view transform that goes from ACEScg to Output - sRGB – I expect any of the LUTs generated by the above techniques to work for this step, but only the last LUT (generated from an ACES 1.2 config, not even 1.3 like I want to be using) results in a correct image, the rest have highlight clipping

After Effects (2022 with 32bit linearized ACEScg ACES Working Space AMPAS S-2014-004 working space):

  1. Open 32bit ACEScg image rendered from V-Ray in Maya using OCIO 2.0 ACES 1.3
  2. Enable preserve RGB for the image in Interpret Footage so it isn’t color managed
  3. Disable AE’s view transform in the View menu
  4. In the layer stack, create an adjustment layer to apply the view transform LUT – I expect any of the LUTs generated by the above techniques to work for this step, but only the last LUT (generated from an ACES 1.2 config, not even 1.3 like I want to be using) results in a correct image, the rest have highlight clipping

Nuke (14 with cg-config-v.1.0.0_aces-v1.3_ocio-v2.0):

  1. Read 32bit ACEScg image rendered from V-Ray in Maya using OCIO 2.0 ACES 1.3 with ACEScg IDT
  2. Set viewer to ACEScg to mimic what’s happening in PS and AE
  3. Use vectorfield node to read in a LUT as a view transform to mimic what’s happening in PS and AE – I expect any of the LUTs generated by the above techniques to work for this step, but only the last LUT (generated from an ACES 1.2 config, not even 1.3 like I want to be using) results in a correct image, the rest have highlight clipping

In both Photoshop and After Effecfts, using the fnord OCIO plugin to directly apply the view transform works perfectly without clipping, but I’m developing this workflow using LUTs because it will be used in an environment where the plugin cannot be installed. I do not know enough about ACES and LUTs to understand why the majority of LUTs that I am generating with the aforementioned techniques have this highlight clipping, where if I directly apply the transformation to the image (won’t be possible in my final workflow) instead of writing it out as a LUT this highlight clipping is not present.

Any pointers would be greatly appreciated. Thanks!

2

When creating a LUT you need to bring it into log space to avoid clipping. So in Nuke you would have

CMS Test pattern node (Cube size: 64) →

Log to Lin: OCIOcolorspace in: ACEScct out: ACEScg →

OCIO Display node (In: AcesCG; Display: sRGB; View: ACES 1.0 SDR Video) →

Lin to Log: OCIOcolorspace in: ACEScg out: ACEScct →

Generate LUT node (preLUT size: 1024; Logarithmic])

3

Hi Derek,
I was able to follow that node tree to create a LUT that correctly applies the view transform without clipping, but am I understanding correctly that before applying the LUT I need to convert my image from ACEScg to ACEScct, then apply the LUT, then convert back from ACEScct to ACEScg? If this is the only way then it is better than nothing, but I was hoping it would be possible to achieve the view transform in a singular LUT. Additionally, as I mentioned I’m developing this workflow for Photoshop with only using LUTs, which means the Lin to Log and Log to Lin conversions before and after the LUT application will also have to be their own LUTs, which hopefully won’t be a problem.

Finally, is this workflow for applying LUTs in log required for all transform LUTs? I also have to use LUTs for my IDTs, which seemed to be working correctly when generating and applying them without any log transforms, but is this incorrect?

Here is a screenshot of the system that removed the clipped highlights following your LUT creation nodetree, I just want to make sure that I’m not misunderstanding because if there is a way to apply the transformation on ACEScg images with a single LUT that would be ideal.
loglutapplication

Thanks!

4

Nope. No need. The image stays in the working space (ACEScg). The shaper space (lin2log) is baked into a single LUT.

In Nuke to view the LUT just attach a Read into an OCIOFileTransform (I’d use this rather than a vectorTransform). View Transform set to Raw.

The issue I suspect you will bump into in Photoshop is that a lot of it’s best tools don’t work in 32bit linear mode.

5

In that case, using the node tree you provided without the Lin to log conversions that I added in the above screenshot results in an incorrect image on my end – I also tried reversing the lin and log conversions in the LUT and received an incorrect image again. The only way I was able to get a correct result was with the lintolog and logtolin conversions nested around the LUT. Again, my working space is ACEScg, my image is brought in as ACEScg, and my viewer is set to RAW (sRGB - Display). Any insight? (Screenshots use the vectorfield node, but the same result occurs with the OCIOFileTransform). I am using the Cinespace .csp LUT filetype and in my GenerateLUT node have it set to Logarithmic.

IncorrectResults
IncorrectResults1200×975 319 KB

6

The working space in Nuke is ACEScg, but you need to set the Working Space in the OCIOFileTransform node to ACEScct. That means that the LUT will be processed in log, while everything else in Nuke is scene-linear.

7

Ah, I see now, that worked in Nuke. However, I’m worried about applying this in Photoshop – using the color lookup adjustment layer allows me to load the LUT but it has the same result as Nuke when the OCIO file transform node’s working space is set to AcesCG. The only way I’ll be able to interface with OCIO in Photoshop in the workflow that I’m developing (for working at my school where the OCIO plugin cannot be installed) is through LUTs (aside from the document working space being the ACEScg working space that ships with Photoshop 2023), so I don’t see any way of affecting the LUTs working space.

I think that creating a working LUT and using it in Photoshop should be possible, though, because like I mentioned in the original post a LUT generated from the OCIO plugin in Photoshop using the ACES 1.2 OCIO 1.0 config from colour-science with Convert- In: AcesCG; Out: Output - sRGB generates a LUT that works as my view transform without the clipping and without any need to change any LUT working space setting or anything similar, but I need to generate a view transform LUT for my OCIO 2.0 ACES 1.3 config (and need to be able to generate similar LUTs for future ACES versions).

8

Can I ask what it is that you are wanting to do in Photoshop (or rather what students will be doing)? Textures? Matte Paintings?

9

I am a student and am developing a workflow for my peers and I to use for consistency on our projects, and some prefer to do basic compositing adjustments in photoshop (hue, exposure, etc, the basic adjustments that work in photoshop 32bit mode). I prefer to use Nuke but am developing the workflow for photoshop so that they are able to use ACES as well, even though it’s not a very good compositing tool.

I was able to get a workflow for ACES 1.2 working because as previously mentioned the fnord OCIO ACES Plugin was able to export a lut that worked as the view transform without clipping for 1.2, but as I’ve mentioned the current issue is generating a working view transform lut for 1.3 (the 1.2 lut appears to work for 1.3 as well but I’d prefer consistent version matching and the ability to generate a working lut for future versions of aces).

10

You want to design a workflow that will promote industry standard best practices. With that in mind I’d strongly want to suggest that your peers should not be compositing in Photoshop ever. No one should. Photoshop is not compositing software.

11

That is a valid concern. However, I still need to solve this specific issue because the same LUTs will be used in the workflow for After Effects, which although not as powerful as Nuke is a valid tool for compositing. AE 2023 has built in OCIO support, but we’re still on 2022 and do not have the ability to install the OCIO fnord plugin on campus so the same LUTs for the view transform and IDTs will have to be used, at least for the time being. If it wasn’t for the working Aces 1.2 LUT, I would assume it is impossible to solve this problem, but the working view transform lut convinces me that a solution is possible. Thanks for all of your help through this, by the way.

12

After Effects (pre-2023) was designed for compositing in display-referred Rec.709. Nuke in contrast was designed for compositing in scene-linear. At the end of the day, I’d again suggest that the simplest solution is just to have students use the best software for the job. In this case, with the versions you have, that is clearly Nuke. It is designed to do what you need right out of the box. After Effects is not.

I honestly don’t know how, without the Fnord plugin, you’d get the working space for After Effects to be in ACEScg, which you’ll need in addition to the IDT and ODT LUTs. Maybe someone else can say how to MacGyver that. Personally, I would just use Nuke now, and wait til next semester when they install AE 2023.

13

Following on from @Derek’s comments, Photoshop operators are really not designed to work with unclamped float linear data. I would suggest you would be better off working with logarithmic data in Photoshop, either ACEScct or the “native” log space of the camera your footage originates from. Then you will be able to work in 16-bit integer, and the image data will be limited to the float 0-1 (0-65535 int) range. Then you can apply a display transform as a simple 3D LUT. I’m not sure Photoshop even supports LUTs which include a 1D shaper and a 3D cube in one file in any case.

14

I did encounter the same issue a few weeks ago. Fnord’s plugin for Photoshop with ACES 1.3 configs was producing csp luts without 1D shapers for some reason. No issues with 1.2 configs. Would be best to contact Fnord.

15

It remains true that Photoshop isn’t an ideal compositing workspace, but I was able to generate correct LUTs for the workflow that I am developing. As @piotrus3333 mentioned, the Fnord plugin produces csp LUTs without 1D shapers to take ACEScg → ACEScct (log) and back when using the 1.3 config. The nuke LUT generation workflow from @Derek works when you are able to change the working space that the LUT is read in, but since you aren’t able to do that in Photoshop you need a 1D shaper in the LUT. I set up the Python API (using pip install opencolorio==[version]) and generated them manually, here is the code if anyone needs to do this in the future (written for the OCIO 2.1 API + config file; all baker set methods are commented out so you must uncomment the code block that you desire to bake):

import PyOpenColorIO as ocio
from io import StringIO

config = ocio.Config.CreateFromFile("") !!! <- CONFIG PATH

baker = ocio.Baker()

baker.setConfig(config)

baker.setFormat("cinespace")

#View transform w/ displayView
# baker.setInputSpace("lin_ap1")
# baker.setShaperSpace("acescct_ap1")
# baker.setDisplayView("sRGB - Display", "ACES 1.0 - SDR Video")

#View transform w/ TargetSpace (requires modified config for target space: see @sharktacos message on https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/issues/82)
# baker.setInputSpace("lin_ap1")
# baker.setShaperSpace("acescct_ap1")
# baker.setTargetSpace("Output - ACES 1.0 - SDR Video (sRGB)")

#PS IVT
# baker.setInputSpace("srgb_texture")
# baker.setTargetSpace("lin_ap1")

out = baker.bake()
buf = StringIO(out)
with open('.csp', mode='w') as f: !!! <- SET FILE PATH WITH .csp EXTENSION
	print(buf.getvalue(), file=f)
2 Likes
16

I did not realise that Photoshop supported .csp files with shapers. Thank you for that info. Although my point about Photoshop operators not really being designed for unclamped linear data still stands.

I successfully baked a LUT using ociobakelut and an unmodified copy of the OCIOv2 Studio Config:

export OCIO=/Library/Application\ Support/OpenColorIO/studio-config-v1.0.0_aces-v1.3_ocio-v2.1.ocio
ociobakelut --format cinespace --inputspace ACEScg --shaperspace ACEScct --outputspace "sRGB - Display" ACEScg_to_sRGB_Display.csp
17

Hey Nick,
Quick question since you’re using ociobakelut. Are you familiar with what the correct string to bake a .icc file with the OCIO 2.2 API is? I had the same issue when baking .csp, where originally the format = “csp” returned an error but “cinespace” worked, and now I can’t figure out what the string should be to bake a .icc file, and can’t find anywhere on the docs that would tell me.

18

Sorry, I don’t use ICC colour management, I’m afraid. The documentation suggests that the syntax is just --format icc

19

Hmm, that’s what I tried earlier with the 2.1.1 Python API and it unfortunately wasn’t working. Hopefully someone will know.
image

20

Not in Python, but I just literally took my ociobakelut line above and changed to --format icc and it worked. Or at least it created a .icc file. I have not tested the result.

Baking Options
    --format %s          the LUT format to bake: flame (.3dl), lustre (.3dl), Academy/ASC Common LUT Format (.clf), Color Transform Format (.ctf), cinespace (.csp), houdini (.lut), iridas_cube (.cube), iridas_itx (.itx), resolve_cube (.cube), truelight (.cub), icc (.icc)