Reading FLIF Images Throws Error

[xerohackcom]

Description

I'm trying to read FLIF images for image quality testing. I've used both Scikit.io as well as cv2 for trying to read the image using 'imread()', but it throws an error. Kindly help me on how to do it.

Way to reproduce

Use FLIF to encode any image (PNG) and generate the compressed .flif image
Try to read the flif image using skimage or cv2
Get error

Version information

scikit-image==0.18.1
scipy==1.6.2
numpy==1.19.3

Error Output

Traceback (most recent call last):
  File "quality.py", line 58, in <module>
    bb = Calculate_BRISQUEDIFF('original_image.jpg', 'compressed_image.jxl')
  File "/home/user/.local/lib/python3.8/site-packages/imquality/brisque.py", line 45, in __init__
    self.image = skimage.color.rgb2gray(self.image)
  File "/home/user/.local/lib/python3.8/site-packages/skimage/color/colorconv.py", line 778, in rgb2gray
    if rgb.shape[-1] > 3:
IndexError: tuple index out of range

I've a similar issue with JPEG-XL (.jxl) images and had posted an issue to the developers GitLab here: and they redirected me to get help from here.

Thanks.

[hmaarrfk]

are you able to provide us an image and the reproducing code?

[xerohackcom]

are you able to provide us an image and the reproducing code?

FLIF file upload is not supported by github, so I've a zip attached with a sample flif image instead. Able to open it using image viewers like ImageGlass that support flif.

sky1.zip

[hmaarrfk]

I realize that hte code is likely 2 lines long, but from your original bug report, you seem to be using a package called imquality

  File "/home/user/.local/lib/python3.8/site-packages/imquality/brisque.py", line 45, in __init__

Would you be able to reproduce bug in a few lines?
They likely start with

from skimage import io
io.imread('filename??????')
# But maybe you have other flags enabled?

My first instinct is to say that scikit-image relies on other libraries to do the image loading.

From what I see jpegxl isn't included on the conda-forge build:
https://github.com/cgohlke/imagecodecs/blob/master/setup.py#L385

I remember I was looking into building it, but I got distracted.

[xerohackcom]

I realize that hte code is likely 2 lines long, but from your original bug report, you seem to be using a package called imquality

  File "/home/user/.local/lib/python3.8/site-packages/imquality/brisque.py", line 45, in __init__

Would you be able to reproduce bug in a few lines?
They likely start with

from skimage import io
io.imread('filename??????')
# But maybe you have other flags enabled?

My first instinct is to say that scikit-image relies on other libraries to do the image loading.

From what I see jpegxl isn't included on the conda-forge build:
https://github.com/cgohlke/imagecodecs/blob/master/setup.py#L385

I remember I was looking into building it, but I got distracted.

Thanks for the help. Yes the issue is reproducable with just io.imread(). That brisque error is unrelated because skimage cannot perform rgb2gray specifically as shown in the error output. Brisque will not show error with anything that skimage can read, because brisque only converts/performs value convertions to test the blind quality.

Yes, skimage doesn't have support for many upcomming as well as older new image formats. I hope that JXL is supported before it becomes a standard so that experiments are possible with it. Right now we have to create our own reader for it.

[cgohlke]

Yes, skimage doesn't have support for many upcomming as well as older new image formats. I hope that JXL is supported before it becomes a standard so that experiments are possible with it. Right now we have to create our own reader for it.

I'm not sure skimage is the right place to expect support for the latest image formats. Have a look at specialized libraries and plugins:

• JPEG-XL: the standard is finished, but the jpeg-xl reference library is not. The older Brunsli library is not compatible with the final standard. The latest version of imagecodecs includes preliminary support on Windows and Linux. The conda-forge binaries do not yet include the codec.
• AVIF: The imagecodecs and Pillow-avif-plugin packages support the format.
• HEIF is supported by pyheif. I would not expect direct support in Pillow, imagecodecs, or imageio because of the restrictive license.
• FLIF is superseded by JPEG-XL. In principle PythonMagick supports FLIF, but I wasn't able to read the sky1.flif file. I haven't tried the imageio-flif plugin.

[xerohackcom]

Yes, skimage doesn't have support for many upcomming as well as older new image formats. I hope that JXL is supported before it becomes a standard so that experiments are possible with it. Right now we have to create our own reader for it.

I'm not sure skimage is the right place to expect support for the latest image formats. Have a look at specialized libraries and plugins:

* **JPEG-XL**: the standard is finished, but the `jpeg-xl` reference library is not. The older `Brunsli` library is not compatible with the final standard. The latest version of [imagecodecs](https://pypi.org/project/imagecodecs/) includes preliminary support on Windows and Linux. The conda-forge binaries do not yet include the codec.

* **AVIF**: The [imagecodecs](https://pypi.org/project/imagecodecs/) and [Pillow-avif-plugin](https://pypi.org/project/pillow-avif-plugin/) packages support the format.

* **HEIF** is supported by [pyheif](https://pypi.org/project/pyheif/). I would not expect direct support in Pillow, imagecodecs, or imageio because of the restrictive license.

* **FLIF** is superseded by JPEG-XL. In principle [PythonMagick](https://github.com/ImageMagick/PythonMagick) supports FLIF, but I wasn't able to read the `sky1.flif` file. I haven't tried the [imageio-flif](https://codeberg.org/monilophyta/imageio-flif) plugin.

Yes you're right. For FLIF I used ImageGlass on Windows 10. Had to add .flif in the settings and was able to read all flif formats. Yes, I guess I'll close the issue for now.

[cgohlke]

For FLIF I used ImageGlass on Windows 10

Current ImageGlass also reports sky1.flif to be corrupt. The only software that can open the file here is UGUI_FLIF, which is based on the long outdated version 0.1-alpha of the FLIF reference library.