bugGNU Octave - Bugs: bug #32986, imread() reads .png with alpha...

 
 

bug #32986: imread() reads .png with alpha channel as an unexpected array format

Submitted by:  None
Submitted on:  Sun 03 Apr 2011 02:02:20 PM UTC  
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  Carnë Draug <carandraug>
Originator Name:  Jeremy Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  dev
Operating System:  Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Sun 19 Jan 2014 11:26:02 PM UTC, comment #21:

This bug report sounds like it has been fixed in the 3.8.0 release, closing report. Please comment further if this is not the case.

Mike Miller <mtmiller>
Project Administrator
Tue 27 Aug 2013 05:36:59 AM UTC, comment #20:

I have just pushed the change. Testing is most welcome.

Carnë Draug <carandraug>
Project MemberIn charge of this item.
Tue 20 Aug 2013 09:28:02 PM UTC, comment #19:

Carnë,

Have you committed the fix to Mercurial? Can this bug report be closed now?

Rik <rik5>
Project Administrator
Tue 06 Aug 2013 07:33:31 AM UTC, comment #18:

Looks correct, thanks.

Will build a snapshot and test once you’ve gotten to the writing fix.

Tobias Wolf <towolf>
Fri 02 Aug 2013 01:35:54 PM UTC, comment #17:

Sorry for the failed attempts, fixing one bug, I regressed on the other. And until next week, I'm running Octave on a system without display so it's harder to test. This time seems to be correct. Could you compare with Matlab?

I will try to fix the writing next.

(file #28743)

Carnë Draug <carandraug>
Project MemberIn charge of this item.
Thu 01 Aug 2013 08:15:43 PM UTC, comment #16:

Maybe this is where the misunderstanding lies:

> 255 is fully opaque, 0 is fully transparent.


255 SHOULD BE fully opaque, 0 SHOULD BE fully transparent.

Tobias Wolf <towolf>
Thu 01 Aug 2013 08:13:01 PM UTC, comment #15:

Sorry, really appreciate us iterating here.

But I don’t think I was inconsistent. In the old comment and in the new comment I said essentially the same thing. No?

And your 3rd mat has all black, all zero alpha channels now (if c1 and c2 are again supposed to be alpha).

octave:1> load alpha_test-3rd.mat
octave:2> imshow(c2)
octave:3> imshow(c1)
octave:4> c1

octave:5> find(c1)
ans = [](0x1)
octave:6> find(c2)
ans = [](0x1)

Tobias Wolf <towolf>
Thu 01 Aug 2013 04:06:54 PM UTC, comment #14:

That's the opposite of what you said in comment #7 "White in the alpha channel should be taken as fully opaque and black refers to fullz transparent". While white and black are not values, in an image white is usually represented with the highest values, and black with lower.

Anyway, this is easy to fix, I have already fixed it when reading transparency for indexed images (the ones where I had a test case around). Will soon apply same fix for RGB, grayscale and CMYK.

Carnë Draug <carandraug>
Project MemberIn charge of this item.
Thu 01 Aug 2013 03:39:00 PM UTC, comment #13:

Ja, it’s exactly the wrong way around.

255 is fully opaque, 0 is fully transparent.

Compare here:
http://en.wikipedia.org/wiki/Alpha_compositing#Description

Tobias Wolf <towolf>
Thu 01 Aug 2013 03:27:39 PM UTC, comment #12:

Ah! I found the culprit. Should work now. I'm getting exactly the same alpha values for both images, which imshow displays as a black face on the center.

Higher values on alpha mean more transparency which seems to also be what matlab does. Could you double check with the attached file if it's the results you would expect?

(file #28735)

Carnë Draug <carandraug>
Project MemberIn charge of this item.
Thu 01 Aug 2013 11:55:56 AM UTC, comment #11:

The alpha seems to be completely corrupted in both cases.

In the first I get an all black image besides the first pixel which is 255.

The second one (c2) is just weird with repetitive patterns.

Tobias Wolf <towolf>
Wed 31 Jul 2013 10:13:12 AM UTC, comment #10:

With both your cases I get an uint8 matrix of 512*512*3, an empty colormap (class double), and a uint8 matrix of 512*512 for the alpha channel.

I have attached what imread is currently reading (it's in Octave binary format). Could you take a look and see if they match what you would expect? The image seems to match what GIMP shows, but I'm unsure about the alpha channel.

(file #28720)

Carnë Draug <carandraug>
Project MemberIn charge of this item.
Tue 30 Jul 2013 05:19:51 PM UTC, comment #9:

Thanks for your fixes. Can you test with the two attached images?

alpha.png has matching RGB and Alpha as Gimp would read it
alpha2.png has disjoint/unrelated RGB and alpha.

I'll look into building to test. But it might take some time before I get to it.

(file #28704, file #28705)

Tobias Wolf <towolf>
Tue 30 Jul 2013 12:04:06 PM UTC, comment #8:

I have been looking at this (and other related bugs) and have fixed the problem with the reading. However, I don't have many images for testing with opacity values and Matlab to test. Could you please try to build the development version and check if it's working correctly now (after cset 95055b814d35).

1. the matlab API compatibility [I, M, A] should be fixed;

2. problem about writing tthe opacity will be fixed next.

3. about the Alpha channel being reverse is because GraphicsMagick (the library that actually reads the images) reads them like that. In the two cases I could check with Matlab, it was inverted in one but not the other, so some tests cases would be welcome.

Carnë Draug <carandraug>
Project MemberIn charge of this item.
Mon 22 Aug 2011 03:13:44 PM UTC, comment #7:

This is a whole bug complex concerning image alpha, to be frank.

First, imread does not match the Matlab API concerning imread output Array format and [I, M, A] output variables (as already mentioned below)

Second, imwrite does not follow the Matlab API in only saving the Alpha channel when an image array has [:,:,4] layers if the 'Alpha' parameter has been given separately like so

imwrite(img(:,:,1:3), 'img-alphsep.png', 'Alpha', img(:,:,4))

If I give Octave a [:,:,4] image it saves alpha always.

Third and most importantly, Octave misinterprets the alpha channel polarity and inverts the alpha channel upon saving and loading. White in the alpha channel should be taken as fully opaque and black refers to fullz transparent. Octave mixes this up and actually reverses this channel on both imread and imwrite.

I've attached a Screenshot illustrating this. Left is Octave, right is Matylab.

Should I open separate bugs about parts 2 and 3, or is this one bug enough?

(file #23846)

Tobias Wolf <towolf>
Wed 13 Apr 2011 10:12:33 AM UTC, comment #6:

Behaviour of MATLAB R2010b, using the attached files (map is empty in all cases):

Anonymous
Sun 10 Apr 2011 02:33:01 AM UTC, comment #5:

It looks like bug could be related to bug #29696 and bug #30715

Anonymous
Tue 05 Apr 2011 08:28:45 PM UTC, comment #4:

Confirmed. I'm going to change the release to 'dev' since this affects all versions up to the present Mercurial tip.

The fix will need to be in _magic_read_.cc as imread.m merely calls that function.

Rik <rik5>
Project Administrator
Tue 05 Apr 2011 04:24:13 PM UTC, comment #3:

Actually, "img = imread('transparency_pic_gray2.png');" produces a zero matrix.

Anonymous
Tue 05 Apr 2011 04:01:03 PM UTC, comment #2:

I found another kind of strange inconsistent behavior, and have attached 'transparency_pic_gray2.png' to demonstrate this.

...produces an MxN array (alpha channel is silently dropped).

...produces an error message:

(file #23112)

Anonymous
Mon 04 Apr 2011 11:43:38 PM UTC, comment #1:

Can you upload 'transparency_pic.png' or any other file which demonstrates the problem so that we can verify the behavior?

Rik <rik5>
Project Administrator
Sun 03 Apr 2011 02:02:20 PM UTC, original submission:

"map" and "alpha" will be empty variables. "img" will be an MxNx2 array (if grayscale+alpha) or an MxNx4 array (if color+alpha) -- The manual entry for imread says that "img" should be either MxN (black and white, grayscale) or MxNx3 (color).

I'm guessing that the data for the alpha channel should be stored in the "alpha" variable, not as an extra dimension in "img".

...succeeds if transparency_pic.png is color+alpha, but fails if transparency_pic.png is grayscale+alpha:

Tested on both Ubuntu 10.10 (repository version, 3.2.4) and Windows 7 (Octave Forge version, 3.2.4)

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #28743:  alpha_test-4th.mat.tar.xz added by carandraug (217KiB - application/x-xz - imread results after 35a1bd41aa02)
file #28739:  alpha_test-3rd.mat.tar.xz added by carandraug (205KiB - application/x-xz - imread results after dcac71776ae8)
file #28735:  alpha_test-2nd.mat.tar.xz added by carandraug (217KiB - application/x-xz - imread results after 7066eec3431c)
file #28720:  alpha_test.mat.tar.xz added by carandraug (221KiB - application/x-xz)
file #28704:  alpha.png added by towolf (98KiB - image/png - two alpha test images)
file #28705:  alpha2.png added by towolf (117KiB - image/png - two alpha test images)
file #23846:  inverted alpha.png added by towolf (2MiB - image/png - Alpha inverted in Octave but not in Matlab)
file #23112:  transparency_pic_gray2.png added by None (2KiB - image/png - Treated inconsistently by different ways of calling imread())
file #23110:  transparency_pic_color.png added by None (4KiB - image/png - Two image files that cause the behaviour described in the original submission)
file #23111:  transparency_pic_gray.png added by None (5KiB - image/png - Two image files that cause the behaviour described in the original submission)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by towolf
  • -email is unavailable- added by towolf (Updated the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 20 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-01-19 mtmiller CategoryNone => Octave Function
        StatusConfirmed => Fixed
        Open/ClosedOpen => Closed
    2013-08-02 carandraug Attached File- => Added alpha_test-4th.mat.tar.xz, #28743
    2013-08-01 rik5 Carbon-CopyRemoved 72865 => -
    2013-08-01 carandraug Attached File- => Added alpha_test-3rd.mat.tar.xz, #28739
    2013-08-01 carandraug Attached File- => Added alpha_test-2nd.mat.tar.xz, #28735
    2013-07-31 carandraug Attached File- => Added alpha_test.mat.tar.xz, #28720
    2013-07-30 towolf Attached File- => Added alpha.png, #28704
        Attached File- => Added alpha2.png, #28705
    2013-07-30 carandraug Assigned toNone => carandraug
        Operating SystemGNU/Linux => Any
    2011-08-22 towolf Carbon-Copy- => Added towolf
    2011-08-22 towolf Attached File- => Added inverted alpha.png, #23846
    2011-04-05 rik5 StatusNeed Info => Confirmed
        Release3.2.4 => dev
    2011-04-05 None Attached File- => Added transparency_pic_gray2.png, #23112
    2011-04-05 None Attached File- => Added transparency_pic_color.png, #23110
        Attached File- => Added transparency_pic_gray.png, #23111
    2011-04-04 rik5 StatusNone => Need Info

    Back to the top


    Powered by Savane 3.3