bugGNU Octave - Bugs: bug #49137, some grayscale images are...


bug #49137: some grayscale images are displayed badly

Submitted by:  Francesco Potortì <pot>
Submitted on:  Tue 20 Sep 2016 12:38:01 PM UTC  
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  4.0.3 Operating System:  GNU/Linux

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Fri 21 Oct 2016 04:44:52 PM UTC, comment #4:

@Carnë: Do you want to apply the small patch you wrote inline in comment #2 for imshow.m? It seems reasonable, and is a bug fix so it could go on the stable branch.

Rik <rik5>
Project Administrator
Tue 20 Sep 2016 02:44:37 PM UTC, comment #3:

Thanks of the clarifications of image vs. imshow. In fact, I had settled on using image in place of imshow because of bug #49140, whioch I was able to identify thanks to your comment on point 2) above.

Francesco Potortì <pot>
Tue 20 Sep 2016 02:14:12 PM UTC, comment #2:

This are two different issues. One of them is a bug:

1. call imshow with a filename

This is a bug, and the problem ins that imshow does:

but that's now how imread works. If the image is not indexed, then map is empty. This should be something like:

2. call image instead of imshow.

The call to subplot is irrelavant here. I don't think this is a bug. image() is not the function to display an image, it is meant to display a matrix as if it was a figure and needs a colormap. Because there is no colormap, it uses the default colormap which has only 64 indices. Because all values are higher than 64, then all pixels show up "saturated" (yellow in 4.1, red in 4.0)

Carnë Draug <carandraug>
Project Member
Tue 20 Sep 2016 01:35:58 PM UTC, comment #1:


I think the very first issue is that the image data we get from GraphicsMagick (imread) are not the original ones.
I tried to run "imfinfo" and "imread" in Octave and Matlab (R2016a on linux) and the main differences are :

  • imfinfo: the "ColorType" is "Grayscale" in Octave and "TrueColor" in Matlab
  • imread: consequently returns no cmap in both cases but a 19-by-19 matrix in Octave and a 19-by-19-by-3 Matlab

I think this problem has already been discussed by Carnë extensively (who I am ccing). AFAIR it boils down to GraphicsMagick does not give access to the actual original data.

Now a workaround for the first issue ("imshow (filename)") could be to treat the image as grayscale when imfinfo tels to do so.

Pantxo Diribarne <pantxo>
Project Member
Tue 20 Sep 2016 12:38:01 PM UTC, original submission:

This behaviour is the same with gnuplot and fltk, and happens with the attached file (which is the reduction of 1980x1980 original which exhibits the same problem).

The instructions marked as #bad both generate a flat picture with a single bordeaux colour.

The instruction marked as #good generates the correct picture, in different levels of grey.

As a workaround, for both #bad cases if I first convert the grey image to RGB then the display is correct:

im = repmat(im,1,1,3);

Francesco Potortì <pot>


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

Attach Files:

Attached Files
file #38562:  bug.jpg added by pot (1KiB - image/jpeg)


Depends on the following items: None found

Items that depend on this one: None found


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

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

    Only project members can vote.




    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-09-20 pantxo StatusNone => Confirmed
        Carbon-Copy- => Added carandraug
    2016-09-20 pot Attached File- => Added bug.jpg, #38562

    Back to the top

    Powered by Savane 3.3