FL32 RGBA image reads look like scrambled RGB

[RichardKirk]

ImageMagick version

7.1.1-13 Q16-HDRI x86_64 21276

Operating system

MacOS

Operating system, version and so on

Ventura 13.4 on Intel Mac 2.6 GHz 6-Core Intel Core i7

Description

RGB and RGBA FL32 files written by 'convert' seem fine. I have generated both, and inspected them with my own tools. I can read RGB FL32 files, but the RGBA FL32 files appear as scrambled RGB. PNG RGBA file formats read correctly on my machine. The read and wrote code seems to support from 1 to 4 channels, and it seems to make sense.

FL32 is a very simple 32-bit float format used by FilmLight for image dumps that you guys have kindly supported. Baselight 6.0 now supports alpha throughout, so the RGBA files are going to be used. I was adding an option for using ImageMagick for file reads and writes in a tool of mine, and I spotted this. I upgraded to the latest build using homebrew today.

Steps to Reproduce

convert macbeth.fl32 macbeth.png

View Macbeth.png. File is RGB. Contents looks like scrambled RGB.

If RGB.png is any 3-channel PNG file, then...

convert RGB.png RGB temp.fl32
convert temp.fl32 temp.png

...gives a temp.png the looks like the original.

Images

macbeth.fl32.zip

[urban-warrior]

Thanks for the problem report. We can reproduce it and will have a patch to fix it in the GIT main branch @ https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @ https://imagemagick.org/archive/beta/ by sometime tomorrow.

[RichardKirk]

Built ImageMagick-7.1.1-15~beta20230722.tar.gz on Intel Mac --with-quantum-depth=32 and --with-quantum-depth=16. Fix works on both. Many thanks.

[RichardKirk]

I am going to look very silly, but it can't be helped. The problem as described seems to have come back.

I know this makes no sense. I had downloaded ImageMagick-7.1.1-15~beta20230722.tar.gz, and built it according to instructions. When it stopped working, I deleted the original build, removed my previous homebrew build to avoid any interference from that, unpacked the tar.gz file, and started again. This time /opt/bin/convert macbeth.fl32 temp.png gives me the scrambled file. I have checked /opt/bin/convert and it has the right -version and creation date. I have downloaded the Macbeth-fl32 file from this bug, and that is correct.

Should I open another bug, or what?

[RichardKirk]

I think I have something that works.

In fl32.c I took the lines around line 517...

  status=SetImageExtent(image,image->columns,image->rows,exception);
  if (status == MagickFalse)
    return(DestroyImageList(image));

...and moved them after the...
switch (image->number_channels) {...}

I am not confident I know what I am doing, but SetImageExtent() was changing the number of channels from 4 to 3, which stopped us reaching case 4:. This seems to handle 3-channel and 4-channel FL32 reads.

[RichardKirk]

Also in fl32.c, the writer needs to handle 4-channel files. At line 429 I added....

    case 4:
    {
      quantum_type=RGBAQuantum;
      break;
    }

Again, I am not confident I know what I am doing but it seems to fix 4-channel writes.

[RichardKirk]

This is a bit more complicated than I thought. Here are some odd things in the FL32 writer. I have attached my version of fl32.c and some PNG files. I have added an extra case to the writer as noted in my last comment. This made some images readable but some others still do not read. I have added an error message which gives the truncation. This is often 75%, indicating that the FL32 header is expecting 4 channels but is only getting three. The PNG read works, the FL32 write appears to work, but the FL32 writer sometimes generates a truncated file.

tRGB.png (RGB, no alpha) worked
English.png (RGB, no alpha) worked with the 4-channel modification
Goethe.png (RGB, no alpha) truncated at 75%
rippleTank.PNG (grey, no alpha) truncated at 50%

I have other test images. I have been working through a random collection after writing a book, and this throws up all sorts of strange things. But maybe this is enough to be going on with.

I will be doing my regular work tomorrow, but I am going to go on fiddling with this.

Cheers
Richard Kirk

FL32_TestData.zip

[snibgo]

Is there a definition / specification / standard of the fl32 format?

[RichardKirk]

I know I wrote a document, but I can't find it. The best I can find is an internal help message. If I cannot find one in a few days, I will write one. Here is something quick in the meantime....

FL32 is a very simple image format.

The file extension is typically .fl32 or FL32.

The header is 4 32-bit integers:
0: a FL32 'magic' number 842222662 = "FL32" on a big-endian machine
1: the line count Y
2: the row count X
3: the channel count C
This is followed by a block of 32-bit float data, equivalent to a C++ packed array float data[Y][X][C].
RGB data would be packed as RGBRGBRGB...
That's it.

There are no restrictions on the values Y, X, C other than they should be greater than zero. You can make a FL32 image with more than 4 channels, but most software will only supports 1-4 channels. There are no restrictions on adding your own data after the float array.

Image values are ranged from 0.0 to 1.0.

Advantages:

• It is easy to support. A fully functional reader or writer can be less than 10 lInes of code.
• The header is 16 bytes. A 4-channel image is 16 bytes per pixel.
• It has enough precision for almost all needs.
• It can preserve are data and NaN values straight from a GPU without conversions.

Drawbacks:

• It is not compact. There is no compression.
• It has no header information about viewing orientations, colour space, or anything else.

It is handy for R&D, and moving images between applications on the same machine. I can get images from Baelight into Octave or Matlab. It is not a sensible option for providing large amounts of images to a remote client.

Hope this makes sense. I have a migraine and I can hardly read what I am typing.

[snibgo]

The quick description doesn't specify an order of channels, eg RGBA or ARGB. If only one self-consistent package is used, this doesn't matter. But it may cause problems when one software writes files that some other software reads.

[RichardKirk]

That's right - it doesn't. The image could be BGR or YCrCb. The pixels could be in any orientation. I labelled the axes Y and X but this does not mean you have to display them like that. Image values are typically ranged from 0.0 to 1.0 rather than 0-255, but this is just a convention. Often we need to go outside this range. It won't clip.

We found we often need a completely 'no frills' image format when debugging some image process. When you are already doubting your sanity, you don't want to have to think whether the OpenEXR reader has converted your NaN values correctly, or compressed the image data, or fished out four channels from a possible seven. Or the image had an attached ICC profile. Or whether your TIFF reader supports 32-bit floats. Or whatever QuickTime is up to on your machine. It does not pass multiple frames: if you want to do that you can stick frame numbers in your filename.

Once you get things going, and your images are getting from A to B, then you can try other formats. Well, it is an approach that works for us.

[RichardKirk]

I have attached a zipped copy of my version of fl32.c. This writes all my test png images including ones with an alpha channel. I think your image structure may claim to have 4 channels even when the input image only had 3. I am guessing that we only have a 4th channel if alpha_trait is set to a valid value.

If this passes your code review, we have a fix.

fl32.c.zip

[urban-warrior]

Thanks for the problem report. We can reproduce it and will have a patch to fix it in the GIT main branch @ https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @ https://imagemagick.org/archive/beta/ by sometime tomorrow.

[RichardKirk]

I ran the test on my test images.

Your code is neater than mine, but I still get the truncated files on my Intel Mac.

At line 407 in fl32.c I now have...

  if (image->alpha_trait != UndefinedPixelTrait) {
      if (channels == 3) channels = 4;
  } else {
      if (channels >  3) channels = 3;
  }

With this, it works. It seems the some RGB PNG files seem to have 4 channels when read in, but do not have an alpha_trait set. I suspect fl32.c was correct, and the actual fault is whatever caused the RGB PNG files to think they have a 4th channel.

I am not sure what to do here. I could close this bug if the fault is elsewhere, and open another one with a better description. Presumably the round-trip tests passed, so this may be something peculiar to my machine (Intel MacBook Pro, Ventura 13.4). I could make my own fork and go chasing that like a grownup, instead of posting lines here. Thoughts?

[urban-warrior]

We added another patch to ensure the image is sRGB compatible and only enable 4 channels if the alpha trait indicates an alpha channel.

[RichardKirk]

Thanks. Almost there. This one looks good for RGB but I lose the alpha channel if there was one. This works for all my test images if I add the 'case 4:' line in fl32.c about line 430. If this is good for you we can close this.

    case 3:
    case 4:
    {
      if (image->alpha_trait != UndefinedPixelTrait)
        {
          quantum_type=RGBAQuantum;
	  channels=4;
          break;
        }
      quantum_type=RGBQuantum;
      channels=3;
      break;
    }
    default:

This was shown up by the attached image, which came out 3-channel black as a FL32. I have also attached a quick document I wrote identifying the FL32 image format, as I seem to have lost the one that was in our product.

FL32_ImageFormat.pdf

[RichardKirk]

One last minute thought: maybe we ought to do the same sort of thing for case1: and case2: ?

I haven't had to deal with mono + alpha as far as I know, but I have had an ST map in 2-channel OpenEXR format recently.