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.
|
Tue 27 Aug 2013 05:36:59 AM UTC, comment #20:
I have just pushed the change. Testing is most welcome.
|
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?
|
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.
|
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)
|
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.
|
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)
|
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.
|
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
|
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)
|
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.
|
Wed 31 Jul 2013 10:13:12 AM UTC, comment #10:
With both your cases I get an uint8 matrix of 5125123, 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)
|
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)
|
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.
|
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)
|
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):
|
Sun 10 Apr 2011 02:33:01 AM UTC, comment #5:
It looks like bug could be related to bug #29696 and bug #30715
|
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.
|
Tue 05 Apr 2011 04:24:13 PM UTC, comment #3:
Actually, "img = imread('transparency_pic_gray2.png');" produces a zero matrix.
|
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)
|
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?
|
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)
|