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

 
 

bug #49137: some grayscale images are displayed badly

Submitter:  Francesco Potortì <pot>
Submitted:  Tue 20 Sep 2016 12:38:01 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 03 Mar 2019 07:22:16 AM UTC, comment #5: 

I made the small change suggested in comment #2.  Marking as fixed and closing report.

Rik <rik5>
Group administrator
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>
Group 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:


  ## Get the image.
  if (ischar (im))
    [im, map] = imread (im);
    indexed = true;
    colormap (map);
  endif


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


  ## Get the image.
  if (ischar (im))
    [im, map] = imread (im);
    if (isempty (map))
      indexed = false;
    else
      indexed = true;
      colormap (map);
    endif
  endif


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>
Group Member
Tue 20 Sep 2016 01:35:58 PM UTC, comment #1: 

Hi,

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>
Group 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).


> imshow bug.jpg   # bad
> im = imread("bug.jpg");
> imshow(im)       #good
> close all
> subplot(3,2,1)
> image(im)        #bad


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:
   
   
Comment:
   

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)
  •  

    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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-03 rik5 CategoryPlotting Octave Function
        StatusConfirmed Fixed
        Open/ClosedOpen Closed
        Release4.0.3 dev
    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.13-4448.
    Corresponding source code