[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #51264] imread incorrect results (vs python ma
From: |
Mike Miller |
Subject: |
[Octave-bug-tracker] [bug #51264] imread incorrect results (vs python matlab results) |
Date: |
Mon, 19 Jun 2017 16:17:45 -0400 (EDT) |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0 |
Update of bug #51264 (project octave):
Status: None => Need Info
_______________________________________________________
Follow-up Comment #4:
It looks to me like the image in question is actually a grayscale image, but
the JPEG metadata declares that it is based on an RGB colorspace. This tag
possibly tells applications to read the grayscale image and represent it
internally as if it were full color RGB. GraphicsMagick does store this tag in
the file metadata but doesn't appear to do anything with it automatically,
this would be up to Octave to interpret and act on.
The two images written like this are very different:
x1 = randn (100, 100);
imwrite (x1, "foo1.jpg");
x2 = repmat (x1, 1, 1, 3);
imwrite (x2, "foo2.jpg");
When looking at the metadata with "gm identify" though, the first image is
declared as a grayscale image with a JPEG grayscale colorspace tag. The second
is grayscale but with a JPEG RGB colorspace tag. When Octave reads them using
GraphicsMagick, it gets back a 100x100 array in both cases. I suspect we
should be detecting the colorspace tag and expanding the grayscale data into
RGB data for the user here.
So confirmed, I think, but need confirmation or more investigation with
someone more familiar with GraphicsMagick and graphics file formats.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?51264>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/