16bit/channel Krita-originating OpenEXR does not load

[virtualritz]

Calling open() on the attached OpenEXR does not work, the function fails with:

Error: Format error decoding OpenExr: image does not contain non-deep rgb channels

I opened the image in an OpenEXR viewer and saved it again and the copy (still f16/channel) opens as expected via open().

A quick glance seems to indicate this is an issue with expected channel names in the openexr.rs codec file.

Reproduction steps

Try loading attached image.

j0.3toD__F16_RGBA.zip

P.S.: the above error contains a superfluous double negative. How about:

Error: Format error decoding OpenExr: image contains deep rgb channels

instead?

[fintelia]

I think it might be more than just the channel names. Based on this comment, it seems to be an unimplemented feature:

https://github.com/image-rs/image/blob/5f4f5ec295748f2cea0f280cfd553b453cde421f/src/codecs/openexr.rs#L78

Please do open a PR for the error message improvement. This is the relevant line. The only thing I'm unsure of is whether the message should be "image contains deep rgb channels" or "image contains only deep rgb channels".

[virtualritz]

The logic is broken there. This image does not contain deep data, just RGBA, f16/channel.

OpenEXR is a complex format. My guess is that the way the image crate treats it is not sufficient to make the conclusions the code does re. what data the file contains or doesn't.

This image opens fine (as RGBA) in several apps or viewers I tried.

For example AfterEffects, Krita (do not support deep data btw) and 3Delight Display. The file came originally from 3Delight Display was saved there, opened in Krita, a color grade applied and the file saved again, from Krira. That's the file I attached.

I.e. RGBA OpenEXRs saved from Krita would maybe exhibit this behavior in general, when fed to the image crate?

P.S. as I wrote, opening and saving the file in 3Delight Display makes it readable by image. The former does not change the actual data in the file. I.e. the kind (normal/deep) or per-channel depth. This, again, seems to indicate this is a meta data misinterpretation bug re. the expected channel names, in the openexr.rs code.

[virtualritz]

I had a look at some old EXRs I have laying around and common channel names for RGBA data range from r, g, b to stuff like spaceship.red, spaceship.green, spaceship.blue and spaceship.alpha.

AFAIK OpenEXR itself (the old C++ resp. new C code base) has some good detection logic. I will have a look there and may find time to assemble a PR that fixes this.

[virtualritz]

I found a description of the logic OpenEXR uses:

RGB channels are present if the either (a) the names of the channels in their entirety or (b) following the "." character match one of the triplets defined in {params}. Order of the channels and case of the channel names are ignored.

• Example 1: "main.b", "main.g", "main.r" match
• Example 2: "MainR", "MainG", "MainB" do not match
• Example 3: "R", "G", "B" match
• Example 4: "red", "green", "blue" match