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

 
 

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

Submitted by:  None
Submitted on:  Sun 15 May 2011 06:51:26 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: Works For MeAssigned to: None
Originator Name: Stefan GustavsonOriginator Email: -unavailable-
Open/Closed: ClosedRelease: 3.2.4
Operating 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)

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 -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>
Project 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>
Project Administrator
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>
Project Administrator
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:

Rik <rik5>
Project 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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jordigh (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by None (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 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 16 May 2011 04:50:49 PM UTCrik5Open/ClosedOpen=>Closed
    Sun 15 May 2011 10:50:29 PM UTCrik5StatusNone=>Works For Me

    Back to the top


    Powered by Savane 3.1-cleanup1