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.
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.
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.”
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.
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. 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.
DPX does not have a canonical log color space. It was originally made for Cineon scans back in the day, but your footage is probably not a film scan. If you get a DPX file it is usually in the native log color space of the camera it was shot on.
We use ACEScct for DPX files sent to matte painting in Photoshop, meaning we have an ACEScg EXR in Nuke that we write out as a DPX in ACEScct. We then use an ICC profile in Photoshop to convert from ACEScct to sRGB display for artist viewing in Photoshop.