Premulted ACEScct IDT in Nuke from photoshop

Does anyone please know if an OCIO config can unpremult by alpha before doing a Colour transform? I can’t find it in the docs.

  • My issue is that I’ve got premulted images in ACEScct from photoshop via exr-io. And I need to get too my nuke working space of ACEScg, in nukes read node’s colourspace knob drop down. This is done via an OCIO config that’s picking up the ‘default’ from the alias name set in the file name of the exr…
  • The multiple layers are then merged using nukes PSDmerge node in ACEScct space, with ‘sRGB colourspace’ unticked. And then returned to ACEScg for the rest of the comp.
  • For the layers with alpha values >0 & <1 I need to do any colour transforms in the unpremultplied state. This ensures that all the flattened image in photoshop matches the layered image in nuke. (Using icc proof luts in photoshop)

Am I missing something here?

  • is my only choice to fix it by reversing the process after the read. (Current workaround)
  • Or asking the exr-io dev to have an option to not premult photoshop exr exports.

Couldn’t you just have the following nodes in Nuke?

read > unpremult > CC > premult

To reverse the process would be:
Read (colourspace ACEScct to working space ACEScg) > ACEScg to ACEScct> Unpremult > gamma 0.4545 > ACEScct to ACEScg > premult

I.e. If the premults don’t happen in P.S. working space, the edge detail gets unintentionally changed.

p.s. the exr-io also bakes is a reverse srgb i.e. the 0.4545

EXR is intended to hold linear data not log. I wonder if that is contributing to the issues here? Have you tried saving these as DPX? A possible workflow would be:

Nuke: write plates to DPX in ACEScct
Photoshop: Paint with an ICC profile of ACEScct to ACES 1.0 SDR video (sRGB Display). This allows you to paint in log but view it in the display space.
Photoshop: save working file as PSD. Export for Nuke either in DPX or PSD.

For reading it back into Nuke, you would only need it to be PSD if you needed to keep all the alphas using the PSDmerge node. This will save the file unpremulted.

1 Like

Thanks for your detailed explanation Derek.

Yes, previously we used a similar workflow, but with tiff into ps and psd out (or separate tiffs out if over 2gb due to PSD limit). The reason this workflow works is that PS exports out unpremulted images. But we want to leverage the advantages of exporting exr from photoshop (via exr-io). I see no issue with holding log data in exr?

The issue afaik, is that OCIO / nuke is not designed for accommodating premulted RGBA images in different tone-maps. For image edge data to match in different applications, the unpremult/premult/over’s need to always be in the working space of whatever was used in creation application (and linear is not a workable option in P.S.).

I assume that OCIO colourspace configs can’t have unpremult’s & premults as part of the config. So I will pursue workarounds.

There is no image file container format specified for use with ACEScct as the encoding is intended to be transient and internal to software or hardware systems, and is specifically not intended for interchange or archiving.

“It is important to remember when dealing with float-16 data, that the bits are allocated very differently from integer encodings. Whereas integer encodings have a uniform allocation of bits over the entire coding space, the floating-point encodings have increased precision in the low end, and decreased precision in the high end. Consequently, if one has a uint-16 image, converts to a float-16 representation, and then converts back, fewer than 16-bits of precision are maintained.”

Cinematic Color, appendix 4.3

1 Like

Yes, storing log encoded imagery (or anything log encoded) into a half-float container is not a good idea, you will lose more data than expected.

1 Like

Generally, Photoshop and EXR is a real PIA. I’ve taken to using Krita instead. In Krita you can work scene-linear, use OCIO, and it’s free.

That said, I did find this…

FWIW, you could read in the premulted image in Nuke with the input transform set to raw, unpremult in that color space, do a color space conversion from log to linear, and then premult.

read (raw) > unpremult > OCIOcolorspace (ACEScct to ACEScg) > premult

This should give correct edges.

1 Like

Sorry, but do not touch any ACES c$€p in Photoshop without extreme needs. Photoshop don’t have any native support for ACES at all. Some limited support only happen when you installing AfterEffects that adding some ICC profiles with ACES color spaces.
But bear in mind ICC is only for [0-1] range. So that profiles can be only used for some previews.

If you really need to use wide gamut color space for some composing in Photoshop use ProPhoto RGB (RIMM/ROMM) and export that into Nuke to do the rest of your works. Just be careful about gamma transfer function, photoshop use sRGB gamma transfer together with ProPhoto instead of official ProPhoto specs. So at the end, better export from 32bit linear ProPhoto.

With the rapid scaling/hiring of DMP artists on VFX jobs we are stuck with photoshop (insert plug of Krita or affinity photo here). These artists have to work in PS 16bit mode due to 32bit having a limited toolset.

Working within these limitations, what better solution is there apart from Log ACEScct in 16bit? I.e. what if I kept the cameras original gamut (typically Arri wide) but used a cct like log curve would that prevent the artefacts mentioned above?

Thanks Derek forwarded .jsx code link to the developer.

We will continue with our current unpremult workaround that is the same as the one you stated.

Hi Vlad… Re proPhoto. I’ve set P.S. to not do any colour management, apart from a icc proof lut as the monitor ODT

I believe that could all work with DPX rather than EXR.

Thanks. So the issue is when any gamut transform happens? i.e. one would not want to convert an Arri Gamut file to a sRGB/709 gamut that is the norm for DPX.

Also DPX log (Cineon) has issues in the black portion of the curve - that is resolved by ACEScct. This issues is apparent when in photoshop as it is really difficult to adjust the dark areas. Would a DPX in pLog fix this. I remember back in the day the Josh Pines Log fixing black issues with cineon/dpx log.