[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #29359] file created with imwrite dowesn't mat
|
From: |
Ian Journeaux |
|
Subject: |
[Octave-bug-tracker] [bug #29359] file created with imwrite dowesn't match original data. |
|
Date: |
Fri, 09 Apr 2010 13:12:38 +0000 |
|
User-agent: |
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; SU 3.26; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.1; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; AskTB5.5) |
Follow-up Comment #10, bug #29359 (project octave):
I am using the version that runs under mingw.
After discussion and some tests with Bob Friesenhahn on the Graphmagick side,
I think the issue may be on the Octave side.
His comments
"...which causes me to suspect that perhaps Octave has a bug in that it
stores the low-order octet of a 16-bit gray value rather than dividing, or
storing the high-order octet. This would cause considerable confusion since
the image would often look almost correct (the low-order byte often matches
the high-order byte), but sometimes be terribly wrong."
We ran a bunch of tests on the GraphMagick side that seem to indicate that
outside of Octave the image read and saved are yte for byte identical. The
code that duplicates the problems is
I = imread('pickoutcentralin.png');
imwrite(I,'pickoutcentralout.png');
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?29359>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/