I wanted to start a bit of discussion about dealing with Photoshop in the context of an ACES pipeline.
A number of workflows I’ve seen/tried revolve around giving Photoshop log data of one flavour or another, and using ICC soft proof profiles, or giving it linear data and using LUT based adjustment layers for viewing (with the additional limitations of working in 32bit mode).
Whilst these work OK, my feeling is that going down that road means you’re fighting the way Photoshop wants to work. Photoshop always seems happiest when it’s working with normalized display referred data that’s managed by the ICC system.
So keeping this in mind, we moved to a setup where we take our ACES data, apply an output transform, work in Photoshop, then invert that transform when we want to move back to the rest of the pipe.
Initally we tried just using P3D60, which is our standard display space, but this causes predictable issues at the edge of the P3 gamut, so we made a custom ODT that targets an imaginary display with AP1 primaries, D60 whitepoint, and a gamma of 2.6. Roughly approximating our display space, but with extra elbow room to protect ACEScg level saturation.
We then created a synthetic ICC profile describing this space, and assigned it to our images.
The user can then just open them in Photoshop and work as normal. If they’re going back to EXR land afterward, we have adjustment LUT they can apply before saving out the EXR. Or if they’re going elsewhere (like a marketing delivery) they can just use normal PS colour management to get there (Adobe98 tif for example).
Values above 16.3 in ACEScg are clipped (Good compared to Cineon curve workflows which we’ve used in the past, not as good as ACEScc)
Requires a conversion step coming in and out.
All Photoshop tools available (unlike 32bit mode)
Moving data between other color managed documents and applications works as expected (from the perspective of a Photoshop user)
Normal ICC Colour operations all work as expected (So exporting Adobe98 or sRGB images for marketing works normally)
Colour swatches behave predictably.
Looks normal in other more basic image viewing applications.
Photoshop users actually like it.
Now, there are some bits in here that could go either way.
We based our custom AP1 Display ODT on the dark surround variation, but there is a good case to be made for this to be a dim surround ODT.
Also there isn’t a great story here for HDR, whilst a decent amount of information is packed in, it’s still clipping at 694nits in PQ. I’m not really sure what the move is going to be here until we start getting HDR aware colour management on the PS side.
I’ve attached a sample PNG with the described profile attached, the profile on it’s own, and the example CTL transforms (which can be included in an OCIO config bake).
I’d be curious to know if anyone else has gone down a similar road, or other approaches people are currently taking.
Prototype CTL code and ICC profile: http://gofile.me/2SnCA/W4cbmKl1r
2K example image: http://gofile.me/2SnCA/cKzk3KQzv
(Edit: deleted the embedded example image as the ACESCentral CMS was stripping the ICC profile)