imread() returns different types on different platforms

[dfdx]

This issue started in one of my own repositories, so you can read the whole story there.

In short, for this image on my Linux Mint imread() returns 3-channel RGB image:

julia> img = imread(path)
RGB Image with:
  data: 640x480 Array{RGB{UfixedBase{Uint8,8}},2}
  properties:
    IMcs: sRGB
    spatialorder:  x y
    pixelspacing:  1 1

At the same time, for @dchun with his OSX imread() returns RGB4 image:

julia> img = imread(path)
RGB4 Image with:
  data: 640x480 Array{RGB4{UfixedBase{Uint8,8}},2}
  properties:
    imagedescription: <suppressed>
    spatialorder:  x y
    pixelspacing:  1 1

The last "color" (img[:, :, 4]) seems to be an alpha channel and is all ones.

1. Is it expected behavior? If so, what determines exact return type and how they can vary?
2. What is an appropriate way to get consistent behavior on all platforms?

---

My specs: Linux Mint 17.0 (Qiana), ImageMagick 6.7.7-10 2014-03-06 Q16
@dchun's specs: OSX Yosemite v10.10.2 (14C1514), ImageMagick 6.9.1-10 Q16 x86_64 2015-07-26

[SimonDanisch]

Probably not the best way to do it, but in FileIO I want to establish this pattern:
Image{RGBA{U8}}("image_path.png"), which then always loads the same type.
In general it would be nice to have a more consistent load behaviour, which is a little hard to achieve since we don't do the loading ourselves.
On OSX you quite likely use the OSX native image loader and on other platform you use ImageMagick, which from my experience also returns different types for different platforms.
So besides enforcing a convert, there is not much we can do for now.

[rsrock]

Yes, I was hoping no one would notice this, but that was unrealistic of me 😉

It turns out that OS X and ImageMagick disagree on some image formats. If you look in our IO tests, you'll see that some of them are disabled on OS X, and that there's a second set of OS X tests.

IIRC, most or all of these disagreements are on whether the image is RGB vs. RGB4. Which one is right? I don't know for certain, but if I'd hazard a guess I'd say that RGB4 is correct (the image is stored on disk as 32 bits with the 4th "alpha" channel as all 0xff), and that ImageMagick strips these values. At one point, I was digging into some image files with a hex editor, but I was in a rush at the time and never reached a conclusion.

You can work around this issue by disabling the OS X reader. Comment out this line: https://github.com/timholy/Images.jl/blob/9966872417ec273ea53fd4f715308a790979bd43/src/io.jl#L128. However, ImageMagick is substantially slower than the OS X reader.

@timholy, looks like it's finally time to sort this out. Any thoughts on the proper behavior here? I'd say if the alpha/padding bytes are in the file, they should probably be in the in-memory representation as well.

[rsrock]

Nevermind. After poking at @dfdx's image, it looks like it is misidentified in the OS X reader. The pixel values are packed 24 bits per pixel. Preview.app correctly identifies the image without alpha values. I'll look into it a bit more here.

[timholy]

Regardless of how that particular image worked out, I do agree with the general principle that, where possible, the in-memory representation should reflect the file representation. We may not be able to do that through ImageMagick.

[juliohm]

@Evizero another on imread, thanks for cleaning this up.

[Evizero]

I think this still applies for load? or at least it did a couple months ago when I ran into this.

[juliohm]

Oh, I didn't try with load, sorry. Maybe rename the title of the issue then? Thanks for double checking.

[Evizero]

Given the age I'll close this in favour of #693