Closed Froyok closed 1 month ago
I wonder if the issue is here: https://github.com/love2d/love/blob/657b3de9d9cd585d2ff73a196e3fc66a15eb6267/src/modules/image/magpie/EXRHandler.cpp#L310
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).
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.
Looks like Godot had the same issue (and in this case Blender and Gimp expected the swizzled result too): https://github.com/godotengine/godot/issues/55472
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 :grin: ).
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.
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.
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).
So I did more investigation and tests:
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.
When exporting an EXR image from Love, the content of the file shows the wrong colors and transparency. All the image reader I tried (XnView, Substance Designer, Krita, Tacent view) show the EXR file incorrectly as well, so to me this is Love not exporting/writing the EXR properly. After investigating a bit, it seems the RGBA channels are swizzled as ABGR.
With the following example, I compensate the swizzle via the shader before hand which allows me to compensate the issue:
Results (converted in PNG to be visible here):
System details: