Tue 20 Aug 2013 09:20:21 PM UTC, comment #12:
3 years have passed and somewhere in between this bug seems to have been fixed.
If I run the reporter's code, imwritetest.m, it produces two images which I can compare to be identical.
This is with a development build of Octave (hg id 2946888dfa56) and graphicsMagick 1.3.12 running on Linux.
|
Fri 09 Apr 2010 01:51:31 PM UTC, comment #11:
If the problem is with the way Octave is calling GraphicsMagick functions, then I need some help to fix the problem. Either someone who understands GraphicsMagick needs to submit a patch for Octave, or tell us precisely what is wrong with our current code, or give us some example code that clearly demonstrates how to properly read an image into an array using the GraphicsMagick API. If there is already some documentation for this somewhere, then point us to it.
|
Fri 09 Apr 2010 01:12:38 PM UTC, comment #10:
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');
|
Thu 08 Apr 2010 03:55:01 PM UTC, comment #9:
Well, I'm not sure that's possible on windows. What octave for windows version do you have (e.g. cygwin, mingw, or the "native" version)?
Can you find the library files (search for a filename containing "magic.*")
if you find the library file, you can try to replace it with another version (keep the old one just in case)
Shai
|
Thu 08 Apr 2010 03:43:17 PM UTC, comment #8:
Is it possible to upgrade just GraphicsMagick within Octave?
|
Tue 06 Apr 2010 04:50:12 PM UTC, comment #7:
hg tip 10491:077fef5da460 compiled today (4/6/2010) does not have the bug.
Other details:
O/S : Ubuntu Karmic x86_64
GraphicsMagick: libgraphicsmagick++1-dev, 1.3.5-5.1
CFLAGS : -march=native -msse4.1
|
Tue 06 Apr 2010 06:21:44 AM UTC, comment #6:
Rik,
what is the octave version which does not reproduce the bug?
|
Tue 06 Apr 2010 05:16:48 AM UTC, comment #5:
By contrast, the code runs perfectly fine on an Ubuntu Karmic install with GraphicsMagick 1.3.5 running hg tip.
Since the previous commenter was able to reproduce the bug on an hg tip but with GraphicsMagic 1.3.12 this probably indicates that it is not an Octave issue but a library issue with GraphicsMagick.
|
Mon 05 Apr 2010 05:45:32 PM UTC, comment #4:
I can confirm this behavior on a recent tip running on debian sid with GraphicsMagick version 1.3.12
I think I can narrow down the problem to imwrite since the following code:
I = imread ('pickoutcentralin.tif');
[nn, xx] = hist (I(:), 1:255);
plot (xx,log10 (nn));
produces the original ("good") histogram
|
Wed 31 Mar 2010 03:43:13 PM UTC, comment #3:
John
Was that sufficient information to duplicate the problem? I noticed I hadn't specified that I am using the Windows version of Octave.
|
Sat 27 Mar 2010 05:32:52 PM UTC, comment #2:
The imwritetest.m reads ia tiff image and writes it out immediately. When you compare the two images they wook similar but when you look at the histograms of the images, the differeces are quite clear.
A screen capture of the images and their histograms (via ImageJ) is shown in Histogram Comparisons.jpg.
|
Sat 27 Mar 2010 04:33:09 PM UTC, comment #1:
Please upload an example image or code to produce an image which will demonstrate the problem.
|
Sat 27 Mar 2010 02:38:27 PM UTC, original submission:
In trying to troubleshoot a possible difference between imrotate in Octave and in Matlab, I believe I have narrowed the problem to imwrite when writing bmp and tiff type output.
The easiest check is to read an original gray scale image in with imread and write it out immediately with imwrite. About 50% of the pixels are off by 1 gray level (I believe always low).
The easiest way to see the corruption of the image is to compare the histograms of the original image and output image. The histogram of the resulting image will have several bin where the pixel count will be zero.
I believe the pattern in the histograms looks like
gray level Original Image Saved Image
45 w w
46 x x+y
47 y 0
48 z z
|