bugGNU Octave - Bugs: bug #29696, imread reads in multi-page TIFF...

 
 

bug #29696: imread reads in multi-page TIFF image as empty array with incorrect dimension

Submitted by:  Qianqian Fang <fangq>
Submitted on:  Wed 28 Apr 2010 02:23:37 AM UTC  
 
Category: LibrariesSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: FixedAssigned to: None
Originator Name: Qianqian FangOpen/Closed: Closed
Release: 3.2.3Operating 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)

Fri 02 Aug 2013 06:43:18 PM UTC, comment #8:

The only problem was getting everything zeros. I don't know when this was fixed exactly but I actually get a multi frame image when reading. The first and last frames are all zeros because that's the actual image (all black frames), but the ones in the middle have some white as well.

Carnë Draug <carandraug>
Project Member
Thu 29 Apr 2010 07:32:41 PM UTC, comment #7:

I don't think Octave should eliminate the third dimension automatically if reading multiple frames because then it is impossible to tell whether the result is one CMYK frame or 4 color frames.

If there is only one frame, then Octave will automatically chop the trailing singleton dimensions when it stores the matrix of values.

John W. Eaton <jwe>
Project Administrator
Thu 29 Apr 2010 06:50:23 PM UTC, comment #6:

thanks Søren for the comments, it makes sense to me now. the third dimension is reserved for the RGB components of the image. One can always squeeze it when the data is a gray-scale image. Or, Octave can squeeze it inside imread if size(img,3)==1 is detected, but that's optional.

Qianqian Fang <fangq>
Thu 29 Apr 2010 06:11:56 PM UTC, comment #5:

OK, I agree with Søren. I think we just need to document this better. Patches, anyone?

But there is still the problem that even for something like

for i = 1:256
imread ('headseg.tif', i);
endfor

Octave seems to be incorrectly returning arrays of all zeros. It would be helpful if someone who knows more about GraphicsMagick than I do could look at this problem and determine whether it is our use of GraphicsMagick that is incorrect, or if the bug is in GraphicsMagick.

John W. Eaton <jwe>
Project Administrator
Thu 29 Apr 2010 05:55:25 PM UTC, comment #4:

I don't think Matlab allows you to read multiple frames in one call. It was, however, suggested (and possibly implemented, I can't remember) that Octave should allow you to read multible frames by returning a 4D array. So if you are reading 7 CMYK frames the idea would be to return a MxNx4x7 array. In the case of grey-scale images, I guess we then should return a MxNx1x7 array.

Søren Hauberg <hauberg>
Thu 29 Apr 2010 05:47:15 PM UTC, comment #3:

I didn't write imread, so I don't know the reason for unconditionally setting the third dimension to 1.

Where is it documented how Matlab stores the results from reading multi-frame TIFF images?

I see that it reads CMYK TIFF files into MxNx4 arrays.

How would you distinguish a binary TIFF file with 4 frames from a CMYK TIFF file with a single frame?

How would the data be stored for a multi-frame CMYK TIFF file (assuming there is such a thing)?

John W. Eaton <jwe>
Project Administrator
Wed 28 Apr 2010 03:06:31 AM UTC, comment #2:

I checked out the latest octave code and took a look at _magick_read_.cc, I found the third dimension, idim(2), was hardcoded as 1, I am wondering if there is a rationale for this setting?

also, I tested a binary multi-page TIFF file (bit-depth=1, attached), octave worked ok, except the dimension issue above.

I guess this bug is more specific for gray-scaled (bit-depth>1) multi-page TIFF file.

(file #20354)

Qianqian Fang <fangq>
Wed 28 Apr 2010 02:28:41 AM UTC, comment #1:

It looks like the link did not work in the original report. To download the file, you need to click the "download" link from this page:

https://orbit.nmr.mgh.harvard.edu/plugins/scmsvn/viewcvs.php/trunk/iso2mesh/sample/headseg.tif?root=iso2mesh&view=log

Qianqian Fang <fangq>
Wed 28 Apr 2010 02:23:37 AM UTC, original submission:

The 3.2.x versions of octave gave me incorrect results when reading a multi-page TIFF image.

  • Steps to reproduce:

1. Download the TIFF file in the attachment or from external link [1]

2. run the following command
brain=imread('headseg.tif',1:256);

3. clear brain, and run the following command:
for i=1:256
brain(:,:,i)=imread('headseg.tif',i);
end

  • Expected results:

For the above Step 2, the array brain is expected to have dimension 256x256x256 with many non-zero elements (the file is a segmented brain volume).

The same out come is expected for Step 3.

  • Actual results:

For step 2, octave returns an array with dimension 256x256x1x256, all elements are 0s.

For step 3, octave returns an array with the expected dimensions, but again, all elements are 0s.

[1] https://orbit.nmr.mgh.harvard.edu/plugins/scmsvn/viewcvs.php/checkout/trunk/iso2mesh/sample/headseg.tif?root=iso2mesh

Qianqian Fang <fangq>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #20354:  head.tif added by fangq (212KiB - image/tiff - a binary brain volume (dimension 256x256x256))

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by hauberg (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by fangq (Submitted the item)
  •  

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

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 02 Aug 2013 06:43:18 PM UTCcarandraugStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Wed 28 Apr 2010 03:06:31 AM UTCfangqAttached File-=>Added head.tif, #20354

    Back to the top


    Powered by Savane 3.1-cleanup1