[12.0] EXR encode/export produces swizzled image content (ABGR instead of RGBA) about love

[Froyok]

I wonder if the issue is here:

love/src/modules/image/magpie/EXRHandler.cpp

Line 310 in 657b3de

const char names[] = {'R', 'G', 'B', 'A'};

Looking around on other implementations (relying on tinyexr like Love), they note:
// Must be (A)BGR order, since most of EXR viewers expect this channel order. (from here, another example here).

[slime73]

Apple's EXR decoder they use is working as expected on my Mac (the default and swizzled results are the opposite of your pic), so that comment is probably right. I bet most EXR viewers on Linux are using the same decoding library that isn't handling RGBA channel order correctly.

[Froyok]

Looks like Godot had the same issue (and in this case Blender and Gimp expected the swizzled result too): godotengine/godot#55472

[Froyok]

I ran my example script on Windows and opened the exr resulting files in Substance Designer (Windows version too) and they show the same issue as in my original post.

I was pretty sure already that Designer wasn't relying on a system library like you mentioned, but I wanted to check just to be sure. On Designer we use FreeImage (which itself relies on OpenEXR).

I don't know what Apple is doing, but it seems to be going the opposite way of everybody (as usual 😁 ).

[slime73]

Yeah Apple often uses its own proprietary decoders rather than third party ones, for images. love is actually doing the right thing here as far as I know (it should even be decoding files correctly that display wrong in things that use FreeImage), but I'll still put in a workaround to make things display right when loaded with the broken decoders.

[Froyok]

According to OpenEXR doc:
Channels are stored in alphabetical order, according to channel names. Within a channel, pixels are stored left to right. (from here).

So my guess on what is happening here is that the order in which the channels are written in the file is not ABGR, and most decoders just get the list of channels as-is assuming that order (without looking at the actual channel name). If the Apple decoder doesn't do this assumption and properly check the name, then it explains why the result are inverted.

So I think the change should be quite simple here and require to just change the order (like they did on Godot).

If I use exrheader tool to print info on the exr files (with test file from Designer and Love), the channels are listed in the AGBR order.

[Froyok]

Another remark on this: would you consider exposing some parameters ?
Ideally it would be nice to specify the compression scheme. Saving a roughly 1024x512 pixels image on my side takes quite a few ms to do, I wonder if no compression could improve that (since in that case I don't care about the footprint).

[Froyok]

So I did more investigation and tests:

• I checked if Gimp was able to open EXR files from love. Gimp behave like many other applications out there and import the file incorrectly (swapped channels).
• Cuttlefish, the library I use to convert EXRs into DDS files also don't open Love's EXR files properly (relies on FreeImage).
• I looked into how we import EXR files in Substance Painter, and in this case we allocate memory with explicit named R, G, B, and A memory buffers that we then pass to the OpenEXR library (we don't use FreeImage anymore for this format) and it's also not imported correctly.

I have no idea what Apple does, but if even with the help of the official OpenEXR library we cannot easily open EXR files then in my opinion it is simply broken as-is. :(

I think I will look into using OpenEXR directly myself to export the data.