imageio: Not loading properly EXR file

While loading an exr file, the output is filled with 0’s and this warning appears:

WARNING:root:imageio.freeimage warning: loading color model R as Y color model

I cannot seem to find much information about this. The image is a single-channel float32 exr, the warning comes from Freeimage that basically says that the image will be a single channel image. Does imageio supports this particular case ? Sadly I cannot share the image, let me know what I can do to help debug this. It’s for an urgent work project so if I can go ahead and fix this I will

About this issue

  • Original URL
  • State: open
  • Created 6 years ago
  • Comments: 24 (10 by maintainers)

Commits related to this issue

Most upvoted comments

So the code for EXR_FLOAT is 0x0001. I have generated an EXR F32 image with the following code:

import imageio
import numpy as np
img = np.random.uniform(0, 1, (32, 32))
imageio.imwrite('test_exr_f32.exr', img.astype(np.float32), flags=0x0001)

And loaded that image back into imageio, I get no error. Cannot reproduce it. It must be something due to the image metadata. Any idea how I can inspect that ?

How can I import the flags I need to pass to imageio ?

You’d have to hard-code them: put EXR_FLOAT = ... at the top of your module. The integer value you have to get from the docs or source code, probably the latter.

You should not harcode the EXR_FLOAT value, but use imageio.plugins.freeimage.IO_FLAGS.EXR_FLOAT instead

Since pyav (ffmpeg) supports exr, I thought I give this issue a try and see if it got resolved in the process. Unfortunately it is not solved, but I thought I will leave this here for future reference.

The problematic EXR can be found in this comment: https://github.com/imageio/imageio/issues/356#issuecomment-417322343

and the issue can be reproduced using the following snippet:

import imageio.v3 as iio
import numpy as np

img = iio.imread("displace_v.exr")
assert np.allclose(img, 0)  # should fail

The problem has been identified over in the freeimage repo; however, has not been fixed at the time of this writing:

The bug is really silly. FreeImage expects single and duo channel images to be named “Y” (“gray/luminance”) or “Yx” (x being any other channel that will be ignored) . Your image has a single channel named “R” as no channel Y is found and black is filled.

(Source: https://sourceforge.net/p/freeimage/bugs/283/)

PyAV is also able to read EXR files; however, it too fails to read the EXR … for the same reason that freeimage fails to do so:

>>> img = iio.imread("displace_v.exr", plugin="pyav") 
Missing green channel.
Missing blue channel.
Could not find codec parameters for stream 0 (Video: exr, none): unspecified size
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
Missing green channel.
Missing blue channel.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\Sebastian\Documents\Coding-Projects\imageio\imageio\v3.py", line 61, in imread
    return np.asarray(img_file.read(**call_kwargs))
  File "C:\Users\Sebastian\Documents\Coding-Projects\imageio\imageio\plugins\pyav.py", line 375, in read
    [
  File "C:\Users\Sebastian\Documents\Coding-Projects\imageio\imageio\plugins\pyav.py", line 375, in <listcomp>
    [
  File "C:\Users\Sebastian\Documents\Coding-Projects\imageio\imageio\plugins\pyav.py", line 459, in iter
    for frame in self._container.decode(video=0):
  File "av\container\input.pyx", line 187, in decode
  File "av\packet.pyx", line 87, in av.packet.Packet.decode
  File "av\stream.pyx", line 183, in av.stream.Stream.decode
  File "av\codec\context.pyx", line 522, in av.codec.context.CodecContext.decode
  File "av\codec\context.pyx", line 425, in av.codec.context.CodecContext._send_packet_and_recv
  File "av\error.pyx", line 336, in av.error.err_check
av.error.InvalidDataError: [Errno 1094995529] Invalid data found when processing input; last error log: [exr] Missing blue channel.

I had bugs with imageio/freemage when writing 32-bit FP EXR on Linux, and I’m not the only one, see https://github.com/imageio/imageio/issues/517

here’s an example where I wrote the same data as 32-bit TIFF and as EXR.

python -c "import skimage.io; img = skimage.io.imread('frames/xy.tif'); print(img[1799,265])"
[0.59474474 0.50933564 0.14748667 1.        ]
python -c "import skimage.io; img = skimage.io.imread('frames/xy.exr'); print(img[1799,265])"
# On macOS (correct result):
[0.59474474 0.50933564 0.14748667 1.        ]
# On Linux (wrong result, obtained on July 30 2020, newer imageio versions may give the right result):
[5.9474474e-01 5.0933564e-01 1.4748667e-01 2.2040519e-38]

So either use TIFF, wait for the bug to be fixed, or write your EXR from Python with OpenCV (which supports RGB but not RGBA for EXR).