bugGNU Octave - Bugs: bug #44118, imwrite saves wrong pixel values...

 
 

bug #44118: imwrite saves wrong pixel values into jpg file

Submitter:  Hartmut <hardy>
Submitted:  Thu 29 Jan 2015 04:20:58 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Duplicate Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 3.8.2 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 06 Feb 2015 09:09:52 AM UTC, comment #8: 

This might be a dublicate of bug #42474

Anonymous
Fri 30 Jan 2015 07:36:02 PM UTC, comment #7: 

For me it sounds reasonable that Octave uses some kind of library for the import and export of image files. And I don't  have enough expertise to judge if GraphicsMagick is the right library for Octave or not.

I also have not the knowledge and time to switch the Octave code over to a different image format library, nor the money to pay someone to do this.

I personally can live with this behavior, I'll just use a different file format then. But I also want Octave to be a useful and competitive tool for more other people, and do quite some advertising for it. That's why I like to look for feasable ways to improve Octave, and that's why I file bug reports here.

In my opinion properly saving a grayscale jpg file should be a routine task for an image file library, it doesn't sound too exotic. Therefore: Might there be a possibility that we can get the GraphicsMagick developers to change / correct this in their library? Can we file a useful bug report for GraphicsMagick somewhere and then hope?

(Or might there still be some parameter for GraphicsMagick that we do not use properly in our code, I guess it's in _magick_read_.cc ?)

Hartmut <hardy>
Fri 30 Jan 2015 03:33:17 PM UTC, comment #6: 

GraphicsMagick does all kind of smart things and converts images between types in a way that is not clear to me.  Sometimes converts RGB to indexed if it sees to few different colors. An RGB image may be shown as grayscale if all channels are the same. Sometimes does this, sometimes it does not. I know this is not acceptable for scientific computing where the exact numbers and image type matter. I feel that this means that GraphicsMagic is not a good choice for Octave anymore but replacing it is more work that what I can do.  If you can can do it, patchs are welcome, if you cannot and you need this, I am sure you can find people who will do it (although not for free).

If you have nothing to offer to anyone, I recommend you use tiff then, it seems to work better.  An alternative is to use bioformats. It is a Matlab package and you can make it work in Octave with half dozen changes in m files.

Carnë Draug <carandraug>
Group Member
Thu 29 Jan 2015 10:24:40 PM UTC, comment #5: 

I am sorry to correct myself: But even though the resulting jpg files with the suggested workaround LOOK fine, they are still WRONG in the sense that the resulting file is a RGB jpg file and not a proper GRAYSCALE jeg file. To me there seems to be no way to properly save grayscale jpg files with Octave, currently :(

Hartmut <hardy>
Thu 29 Jan 2015 10:08:47 PM UTC, comment #4: 

Yes, I can confirm that your proposed workaround (to repeat the same grayvalues for all 3 color channels) DOES work fine for my grayscale images.

Hartmut <hardy>
Thu 29 Jan 2015 07:47:31 PM UTC, comment #3: 

You are correct, the intensity values on the saved image are much lower.

I think I know what may be happening. When an image in GraphicsMagick is grayscale, the intensity values are stored in the red channels. This is true for reading and writing.  However, for writing a jpeg grayscale, seems like it looks into the green and blue channels. These seem to default to zero which is why it is darker. The whole point of using GraphicsMagick is avoid coder specific code but seems that it won't do.

Maybe I am wrong about the reason, but the following seems to be a workaround:


A = uint8 ([0 50 255; 1 3 6])
file = "new.jpg";
imwrite (repmat (A, [1 1 3]), file);
B = imread (file)



Carnë Draug <carandraug>
Group Member
Thu 29 Jan 2015 06:40:57 PM UTC, comment #2: 

It's right, that saving into a jpeg file inherently can change the very numbers a bit. But my short script with those simple numbers was only to easily show the behavior.

If you save a "real" grayscale image into a jpeg, then the resulting file (in my case) turnes out to be of roughly half the brightness. This is NOT only due to the jpeg format, there's something significantly going wrong here.

Hartmut <hardy>
Thu 29 Jan 2015 05:37:33 PM UTC, comment #1: 

Changing the data type for double will never help. If anything, will make things worse since GraphicsMagick only handles integers.

I am unsure why this is happening (I tried setting quality to 100 but still got back something different) but if you are interested on saving the exact numbers to the image file, you should not be saving jpeg in the first place.

Carnë Draug <carandraug>
Group Member
Thu 29 Jan 2015 04:20:58 PM UTC, original submission:  

Here is a short script to demonstrate the behavior:


A = uint8([0 50 255; 1 3 6])
file='new.jpg';
imwrite(A,file);
B = imread(file)


As you can see on the output of the command window, the values of B are not equal to the values of A. Actually, the wrong pixel values are already saved into the jpg file.

This error does NOT happen with png or tif image files.

Changing the data type to double does NOT help.

This happesn with the latest release (3.8.2) of Octave. Under Linux as well as under Windows.

Hartmut <hardy>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by hardy (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-02-11 carandraug StatusNone Duplicate
        Open/ClosedOpen Closed
        Dependencies- Depends on bugs #41673

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code