Openexr Color Managed Workflow

[paul-pw]

I’ve found that when opening an openexr image with linear rec2020 color profile in krita, the colors are all wrong.

So I started investigating.
aparently Openexr does not embed a color space icc profile inside the image which is unlike other formats like jpeg or tiff that do embed icc profiles in the image file. openexr instead assumes a linear profile and stores the RGB primaries. From that the color profile can be reconstructed.
I’ve found that gimp and darktable seen to be able to do this and thus display the image correctly.
Krita aparently does not reconstruct the color profile from the RGB primaries. and just assumes sRGB-elle-V2-g10.icc

so far so good. then I just tell krita myself that the openexr image I opened is in linear Rec2020. I found this dialog:

and assumed that I can just select another profile and untick the checkbox for “Convert color space” to tell krita the image is in linear rec2020. But the color space gets converted to linear rec2020. I assumed it would just reinterpret the color space (is this a bug or a feature?)

Now I turned to OCIO. I turned it on and selected the aces_1.0.3 ocio config I downloaded. but which linear rec2020 profile do I chose now? and which viewing color space? I have found at least 4 that say linear rec2020 I’ve settled on the “lin_rec2020” profile. that seems about right but I’m still not quite sure if this is the correct one.

After turning on OCIO the openexr image (with the wrong profile detected by krita) and my reference tiff (with the correct linear rec2020 embedded profile used by krita) look the same. Good. but why do they look the same? their Profiles still don’t match, they shouldn’t look the same, or should they? I’m confused.
Does OCIO overwrite the image color space settings?

tldr:

• Does OCIO overwrite the image color space settings?
• why does the colorspace still get converted even when unchecking the checkbox “Convert color space” under image/properties/colorspace

also some info on my system if that helps: I am using krita-5 with the “krita next” build on windows

I hope this is the right category for this questing. I am verry much a krita beginner but I know some stuff about color and image processing so I don’t think this is a beginners question.

[Snudl]

Welcome to the forum! I’ve also been looking into this topic for some time. There are a few confusing parts, some of which are specific to Krita.

Yeah, as far as I’m aware OpenEXR does not have an option to store color space definitions. Having that would make a bunch of things easier, but I guess it’s mostly meant as a format to carry raw color and non-color input data and relies entirely on the production pipeline interpreting it correctly.

Krita does extensive color management, more than even most other image editors, to the point that it color manages each layer separately. You can have a document where each layer uses a different color space or even different color model, and the blending between layers happens in the document color space. It’s a bit of a hidden feature and there are different ways to convert between color spaces or assign profiles, spread over multiple menus. When you change the color space through the Properties window and uncheck the option to convert all layers, like in your screenshot, it will only assign the new color space definition to the document itself and leave all the layers unchanged. Or more exactly, it leaves the data on a Paint or Vector Layer untouched, but it may change the result from layer blending modes or Filter Layers because those utilize the document color space. Fill Layers, I think, use an intrinsic color space that can’t be changed in any case.

What you want to use instead, is Tools > Scripts > Assign Profile to Image. This will assign the desired color profile to all individual layers without actually converting the image data, so it only interprets the color values differently. You can find the color space and profile information for each Paint or Vector Layer in its layer properties (menu button or right-click menu in Layers docker, or F3).

OCIO, as I understand it, is a complete end-to-end color management solution that maps an arbitrary scene-referred input to a display-referred output. Someone more knowledgeable may correct me, but I think ICC profiles aren’t sufficient because those are defined in CIELAB or CIEXYZ color spaces that don’t have meaningful definitions for floating-point HDR data. That’s one of the reasons why an OCIO config needs to supply its own transformations.

I’ve been using a displays formatted ACES version, which is just ACES with a little better display naming.

sobotka/ACES-1.2-Displays-Formatted

Careful if you download the whole thing, it’s very large with a ton of baked LUTs included that aren’t needed for the config to work, and the original ACES 1.2 config that doubles the size.

So if your input is supposed to be linear Rec.2020, then the right OCIO config should be:

• Input ColorSpace: Utility - Linear - Rec.2020 or lin_rec2020. Role - scene_linear seems to work also, but that one’s probably using the default ACEScg gamut, which is very close to Rec.2020

• Display Device: Your monitor’s native profile. There are also HDR10 and HLG targets for HDR capable displays

• View: Output Transform

Unfortunately, there is also no way in Krita to bake an OCIO tone map for final image export, at least not yet. You’ll need another OCIO compatible editor / compositor for that. Also there is currently a bug when displaying a color palette in Krita 5.0 with OCIO active.

I recently found a very good personal blog site of someone that explains about ACES and the workflows in different applications.
https://www.toodee.de/
If you want to use ACES with Blender, have a look at the Blender & ACES 1.2 article, there are some complications and quirks because Blender doesn’t have full color management.

[hulmanen]

BTW, the output transforms are not your specific monitor’s profile, but “to-spec” transforms meant to be used with the specified type of display listed there.And at least the sRGB and Rec.709 transforms include a highlight rolloff, which is very nice but maybe not expected if not pointed out.

[paul-pw]

first thank you for all the answers.
so a little bit about my usecase:
I am a Photographer and I want to use krita to retouch and paint ontop of my images. I use darktable to color correct the images and export them from there in linear rec2020 for use in krita and then go back into darktable for the final adjustments.

@Snudl

Tools > Scripts > Assign Profile to Image

thanks that works like a charm

@Snudl

Unfortunately, there is also no way in Krita to bake an OCIO tone map for final image export

thats not an issue since I “bake” everything back in darktable with filmic (yes that looks a little different than ocio but good enough until we have ocio in darktable.)

@hulmanen

the output transforms are not your specific monitor’s profile

how do I deal with specific monitor profiles then? would I have to create a custom OCIO config?

Unfortionately there still are color shifts between darktable and krita but I can think of a few reasons why these color shifts show up:

1. the linear rec2020 color space of the OCIO config and the one I actually used are a little different
2. filmic in darktable and OCIO introduce different color shifts
3. my monitor profile messes stuff up.

this probably means I have to create a custom ocio config.
how do I start with that? are there easy ways to do this?

[Lynx3d]

Well OpenEXR does support a “chromaticities” attribute to store the primaries/whitepoint. Assuming linear colors, you could construct a color profile from that.

Matching an existing ICC profile based on that is a bit tricky however, you’d have to go through all available profiles and fuzzy compare their primaries (among other things to decide if they are suitable for RGB images in the first place) to find a best fit.

I don’t think EXR has a standardized way to name a specific color space like Rec. 2020 from a list of known standards (something that HEIF/AVIF does using the NCLX portion of H.273), nor does it support emedding ICC profiles (which is understandable given that those are still kind of unsuitable for HDR outside of linear profiles where you just assume they have unbound value range)