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

 
 

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

Submitter:  mac cordel <markiko>
Submitted:  Mon 19 Jun 2017 11:47:47 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  3 - Low Item Group:  Incorrect Result
Status:  Need Info Assigned to:  None
Originator Name:  markiko Open/Closed:  * Open
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 13 Apr 2022 10:06:58 PM UTC, comment #7: 

I just attached a patch file that solves this bug by checking for the RGB colorspace attribute that is mentioned earlier (although undocumented in the graphicsmagick library).
This is a partial solution though because other formats like "bmp" don't have these attributes. But I have been searching and reading through the source code of the graphicsmagick library and there seems to be no way to tell the original type of the image other than these attributes.

(file #53087)

Maged Rifaat <magedrifaat>
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>
Group 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:

x1 = randn (100, 100);
imwrite (x1, 'foo1.jpg');
x2 = repmat (x1, 1, 1, 3);
imwrite (x2, 'foo2.jpg');
foo1 = imread('foo1.jpg');
foo2 = imread('foo2.jpg');
whos
  Name        Size                Bytes  Class     Attributes

  foo1      100x100               10000  uint8
  foo2      100x100x3             30000  uint8
  x1        100x100               80000  double
  x2        100x100x3            240000  double


Then in Octave 4.2.1 on Windows 7 64bit:


>> whos
Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  =====
        foo1      100x100                    10000  uint8
        foo2      100x100                    10000  uint8
        x1        100x100                    80000  double
        x2        100x100x3                 240000  double

Total is 60000 elements using 340000 bytes



Nicholas Jankowski <nrjank>
Group Member
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:


x1 = randn (100, 100);
imwrite (x1, "foo1.jpg");
x2 = repmat (x1, 1, 1, 3);
imwrite (x2, "foo2.jpg");


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>
Group Member
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: 


gm identify -verbose 0594.jpg
Image: 0594.jpg
  Format: JPEG (Joint Photographic Experts Group JFIF format)
  Geometry: 1024x768
  Class: DirectClass
  Type: grayscale
  Depth: 8 bits-per-pixel component
  Channel Depths:
    Gray:     8 bits
  Channel Statistics:
    Gray:
      Minimum:                     0.00 (0.0000)
      Maximum:                 65535.00 (1.0000)
      Mean:                    11906.78 (0.1817)
      Standard Deviation:      16977.62 (0.2591)
  Filesize: 64.1Ki
  Interlace: No
  Orientation: Unknown
  Background Color: white
  Border Color: #DFDFDF
  Matte Color: #BDBDBD
  Page geometry: 1024x768+0+0
  Compose: Over
  Dispose: Undefined
  Iterations: 0
  Compression: JPEG
  JPEG-Quality: 75
  JPEG-Colorspace: 2
  JPEG-Colorspace-Name: RGB
  JPEG-Sampling-factors: 2x2,1x1,1x1
  Signature: 8716931ad3719934f61f26b027b31bfa5efff92bc2171f264c19856c2275d768
  Tainted: False
  Elapsed Time: 0m:0.012501s
  Pixels Per Second: 60.0Mi


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 n*m*3 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 Files:
   
   
Comment:
   

Attached Files
file #53087:  bug51264.patch added by magedrifaat (876B - text/x-patch)
file #53086:  bug51264.patch added by magedrifaat (876B - text/x-patch - This patch solves the bug by checking the attributes for an RGB colorspace.)
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)

 

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

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

    Date Changed by Updated Field Previous Value => Replaced by
    2022-10-06 rik5 Dependencies- bugs #63060 is dependent
    2022-04-13 magedrifaat Attached File- Added bug51264.patch, #53087
    2022-04-13 magedrifaat Attached File- Added bug51264.patch, #53086
    2019-02-26 mtmiller Priority5 - Normal 3 - Low
        Release4.0.0 dev
    2018-12-30 mtmiller Carbon-CopyRemoved 80942 -
    2018-12-30 mtmiller Dependencies- bugs #55340 is dependent
    2017-06-19 mtmiller StatusNone Need Info
    2017-06-19 markiko Attached File- Added 0594.jpg, #40935
        Attached File- Added 0081.jpg, #40936
        Attached File- Added output.pdf, #40937
        Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code