bugGNU Octave - Bugs: bug #29359, file created with imwrite dowesn't...

 
 

bug #29359: file created with imwrite dowesn't match original data.

Submitted by:  Ian Journeaux <ijourneaux>
Submitted on:  Sat 27 Mar 2010 02:38:27 PM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: FixedAssigned to: None
Originator Name: Ian JourneauxOpen/Closed: Closed
Release: 3.2.3Operating System: Microsoft Windows

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 Jump to the original submission)

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.

Rik <rik5>
Project Administrator
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.

John W. Eaton <jwe>
Project Administrator
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');

Ian Journeaux <ijourneaux>
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

Shai Ayal <shaiay>
Thu 08 Apr 2010 03:43:17 PM UTC, comment #8:

Is it possible to upgrade just GraphicsMagick within Octave?

Ian Journeaux <ijourneaux>
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

Rik <rik5>
Project Administrator
Tue 06 Apr 2010 06:21:44 AM UTC, comment #6:

Rik,
what is the octave version which does not reproduce the bug?

Shai Ayal <shaiay>
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.

Rik <rik5>
Project Administrator
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

Shai Ayal <shaiay>
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.

Ian Journeaux <ijourneaux>
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.

Ian Journeaux <ijourneaux>
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.

John W. Eaton <jwe>
Project Administrator
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

Ian Journeaux <ijourneaux>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #20048:  Pickoutcentralin.tif added by None (40KiB - image/tiff - Here is a small test program to imwrite. )
file #20049:  imwritetest.m added by None (74B - text/plain - Here is a small test program to imwrite. )
file #20050:  pickoutcentralout.tif added by None (39KiB - text/plain - Here is a small test program to imwrite. )
file #20051:  Histogram Comparisons.jpg added by None (76KiB - image/pjpeg - Here is a small test program to imwrite. )

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by bpabbott (Updated the item)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by shaiay (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by ijourneaux (Submitted the item)
  •  

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 20 Aug 2013 09:20:21 PM UTCrik5StatusNeed Info=>Fixed
      Open/ClosedOpen=>Closed
    Sat 17 Sep 2011 05:04:29 PM UTCbpabbottStatusWorks For Me=>Need Info
    Tue 06 Apr 2010 05:16:48 AM UTCrik5StatusNeed Info=>Works For Me
    Sat 27 Mar 2010 04:57:33 PM UTCNoneAttached File-=>Added Pickoutcentralin.tif, #20048
      Attached File-=>Added imwritetest.m, #20049
      Attached File-=>Added pickoutcentralout.tif, #20050
      Attached File-=>Added Histogram Comparisons.jpg, #20051
    Sat 27 Mar 2010 04:33:09 PM UTCjweStatusNone=>Need Info

    Back to the top


    Powered by Savane 3.1-cleanup1