bugGNU Octave - Bugs: bug #51264, imread incorrect results (vs...

 
 

bug #51264: imread incorrect results (vs python matlab results)

Submitted by:  mac cordel <markiko>
Submitted on:  Mon 19 Jun 2017 11:47:47 AM UTC  
 
Category: Octave FunctionSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: Need InfoAssigned to: None
Originator Name: markikoOpen/Closed: Open
Release: 4.0.0Operating System: GNU/Linux

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)

Thu 29 Jun 2017 04:15:11 PM UTC, comment #6:

If an image pixel has the same value in all colour channels, GM may
report it as being grayscale (I think this is coder, i.e. format,
dependent). If the number of unique colours is small enough, it may
even report it as being an indexed image. This is just how GM works,
it optimises for memory usage at the cost that we can't get the real
pixel values.

It is true that we can get back format specific values from GM but
then we are back at writing format specific code which defeats the
point of using GM in the first place. For what is worth, this is
already done in a few cases so more counter-guessing GM about an image
being grayscale/RGB/transparency should be done here:

http://hg.savannah.gnu.org/hgweb/octave/file/69a111259a2c/libinterp/corefcn/__magick_read__.cc#l430

Counter guessing GM about whether it is an indexed image should be
done here instead:

http://hg.savannah.gnu.org/hgweb/octave/file/69a111259a2c/libinterp/corefcn/__magick_read__.cc#l45

Carnë Draug <carandraug>
Project Member
Thu 29 Jun 2017 02:51:28 PM UTC, comment #5:

adding in a bit of matlab compatibility commentary, where this does seem to be an issue:

running the comment #4 commands and then loading the two images in Matlab 2017a:

Then in Octave 4.2.1 on Windows 7 64bit:

Nicholas Jankowski <nrjank>
Mon 19 Jun 2017 08:17:45 PM UTC, comment #4:

It looks to me like the image in question is actually a grayscale image, but the JPEG metadata declares that it is based on an RGB colorspace. This tag possibly tells applications to read the grayscale image and represent it internally as if it were full color RGB. GraphicsMagick does store this tag in the file metadata but doesn't appear to do anything with it automatically, this would be up to Octave to interpret and act on.

The two images written like this are very different:

When looking at the metadata with "gm identify" though, the first image is declared as a grayscale image with a JPEG grayscale colorspace tag. The second is grayscale but with a JPEG RGB colorspace tag. When Octave reads them using GraphicsMagick, it gets back a 100x100 array in both cases. I suspect we should be detecting the colorspace tag and expanding the grayscale data into RGB data for the user here.

So confirmed, I think, but need confirmation or more investigation with someone more familiar with GraphicsMagick and graphics file formats.

Mike Miller <mtmiller>
Project Administrator
Mon 19 Jun 2017 03:01:06 PM UTC, comment #3:

I made some experiments:

(1) Tried to display individual channels in matlab, and they look all the same. So I checked using sum(sum(x(:,:,1)==x(:,:,2))), etc. It sums to the number of pixels.

(2) I generated random 100x100 RGB image with channels different from each other, then I saved it as sample.jpg. Also, I created another 100x100 RGB image whose channels are equal, i.e. R channel = G channel = B channel, then I saved it as sample2.jpg.

(3) Using imread from Octave. Then, x=imread('sample.jpg') and y=('sample2.jpg'). Size of x is 100x100x3, size of y is 100x100 only.

mac cordel <markiko>
Mon 19 Jun 2017 02:14:12 PM UTC, comment #2:

So it looks to me it is a gray-scale image with wrong metadata.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 19 Jun 2017 02:07:31 PM UTC, comment #1:

I confirm that python read it a nm3 and octave n*m
x=np.array(Image.open('0594.jpg'))

>>> x.shape

(768, 1024, 3)
octave

>> q=imread("0594.jpg");
>> size(q)

ans =

768 1024

Doug Stewart <dastew>
Mon 19 Jun 2017 11:47:47 AM UTC, original submission:

I noticed the problem when processing large amount of images using octave. A very few of my images (3 so far out of 500) are read by Octave (via imread) as grayscale images (i.e. mxn) whereas I'm expecting all images as RGB images (i.e. mxnx3). It does not flag an error so I was not aware until I encounter some matrix dimension error in my post processing. I traced the root cause and found out indeed some images are read as grayscale images. I never encountered this error when I was using python and matlab so I tried to investigate for hours. Until now, I have no idea why Octave reads it as grayscale.

I verified again the dimension of these images using Python and Matlab, and they are indeed read as RGB images. I am attaching the actual image (0594.jpg) if you want to replicate my findings. Also some screenshots (output.pdf) to give you my results.

mac cordel <markiko>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #40935:  0594.jpg added by markiko (64KiB - image/jpeg - I added additional file "0081.jpg" for additional test data)
file #40936:  0081.jpg added by markiko (114KiB - image/jpeg - I added additional file "0081.jpg" for additional test data)
file #40937:  output.pdf added by markiko (794KiB - application/pdf - I added additional file "0081.jpg" for additional test data)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by nrjank (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by dasergatskov (Posted a comment)
  • -unavailable- added by dastew (Posted a comment)
  • -unavailable- added by markiko (Submitted the item)
  • -unavailable- added by markiko
  •  

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

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 19 Jun 2017 08:17:45 PM UTCmtmillerStatusNone=>Need Info
    Mon 19 Jun 2017 11:47:47 AM UTCmarkikoAttached File-=>Added 0594.jpg, #40935
      Attached File-=>Added 0081.jpg, #40936
      Attached File-=>Added output.pdf, #40937
      Carbon-Copy-=>Added -unavailable-

    Back to the top


    Powered by Savane 3.1-cleanup1