bugGNU Octave - Bugs: bug #33317, imwrite and/or imread rounds uint8...

 
 

bug #33317: imwrite and/or imread rounds uint8 values incorrectly

Submitter:  None
Submitted:  Sun 15 May 2011 06:51:26 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Works For Me Assigned to:  None
Originator Name:  Stefan Gustavson Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.2.4
Operating System:  * Microsoft Windows Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 16 May 2011 04:50:49 PM UTC, comment #6: 

One can't be absolutely certain that it is a problem with the build, but the 3.2.4 Windows binary build is old.  There were many really good changes that were incorporated into the 3.4.0 source code.  However, the small band of Octave volunteers does not have anyone who regularly builds in a Windows environment and we had no way of supporting that platform.  You can try compiling for yourself, and if you have success, at least send an e-mail to -email is unavailable- with the steps you took.  If you want to stay on Windows you might take a look at the Cygwin environment.  There have been a few people working in that area and they have an installer with version 3.4.0 working.  See the OctaveForWindows page of the wiki (http://wiki.octave.org/wiki.pl?OctaveForWindows).

Rik <rik5>
Group administrator
Mon 16 May 2011 02:09:55 PM UTC, comment #5: 

Brute force and persistence is what everyone else does. There isn't a textbook on how to compile Octave on Windows or any other system that someone can read to become an expert on Octave compilation. There are the indications in the Octave manual and that's all we have.

Jordi GutiƩrrez Hermoso <jordigh>
Group Member
Mon 16 May 2011 02:06:20 PM UTC, comment #4: 

Thanks for the offer. I would have liked to help out, but I am not your guy here. I have absolutely no experience with making binary installers or packaging Windows binaries for others to use. I can push most things through compilation on most platforms I have worked on, but that is more due to persistence than skill. Brute force and ignorance solve the problem for me personally, but when it comes to packaging stuff for others I think better skills than mine are needed.

Anonymous
Mon 16 May 2011 01:53:10 PM UTC, comment #3: 

Recompilation is an inconvenience for everyone, not just Windows users. If you manage to make a good Windows binary, do let us know. The Windows packagers have been having trouble doing so.

The Windows package is advertised because it works more often than not, and because it's the best we have. We do need help with Windows packaging. Can you offer it?

Jordi GutiƩrrez Hermoso <jordigh>
Group Member
Mon 16 May 2011 01:45:10 PM UTC, comment #2: 

OK, good to know. However, this was reproducible across multiple installs using the prepackaged binary installer at Octave Forge, prominently advertised on the main Octave page, so you might want to ask the maintainer of that binary installer to recompile and update the package.

FOr now, I guess I'll just recompile from source, as that seems very likely to solve the problem. Compilation is an inconvenience for most Windows users, though.

Anonymous
Sun 15 May 2011 10:50:29 PM UTC, comment #1: 

I can't reproduce this on Octave 3.2.4 or 3.4.0.  The issue might be with the GraphicsMagick library version you have installed since that is what Octave uses for the actual imwrite/imread functionality.  For reference, my version is 1.3.5-6.

Test code:


img = uint8 (0:255);
imwrite (img, 'test.png');
img2 = imread ('test.png');
any (img2 - img1)

ans = 0


Rik <rik5>
Group administrator
Sun 15 May 2011 06:51:26 PM UTC, original submission:  

When exporting an uint8 array to PNG, TIFF, BMP
or any other lossless 8-bit format by imwrite(),
and then reading it in using imread(), the values
change. Some of the read values, but not all, are
1 smaller than the original. The error accumulates
when the export-import sequence is repeated.
This means that 8-bit image export and/or import
is lossy, even downright destructive.

img1 = uint8(0:255);
imwrite(img1, 'test.png');
img2 = imread('test.png');
figure
subplot(211)
plot(img1, img1-img2); % Difference is 0 or 1
imwrite(img2, 'test.png');
img3 = imread('test.png');
subplot(212)
plot(img1, img1-img3); % Difference is 0, 1 or 2

This looks like a rounding error in the code.
I have not been able to locate it myself.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-05-16 rik5 Open/ClosedOpen Closed
    2011-05-15 rik5 StatusNone Works For Me

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code