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

Submitter:  Qianqian Fang <fangq>
Submitted:  Wed 28 Apr 2010 02:23:37 AM UTC
   
 
Category:  Libraries Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Qianqian Fang Open/Closed:  * Closed
Release:  * 3.2.3 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group 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>
Group 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>
Group 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 Files:
   
   
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
  • -email is unavailable- added by hauberg (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by fangq (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-08-02 carandraug StatusNone Fixed
        Open/ClosedOpen Closed
    2010-04-28 fangq Attached File- Added head.tif, #20354

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code