bugGNU Octave - Bugs: bug #39249, imread and 32 bit (float) TIFF...

 
 

bug #39249: imread and 32 bit (float) TIFF images

Submitted by:  Carnë Draug <carandraug>
Submitted on:  Thu 13 Jun 2013 09:11:00 PM UTC  
 
Category: Octave FunctionSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: NoneAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating System: GNU/Linux

Add a New Comment (Rich MarkupRich 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 18 Oct 2013 04:12:14 PM UTC, comment #9:

I don't think GM's behavior of scaling the image is correct. The min/max sample value are not required tags, and if they are set, they do not mean the image cannot have pixel values outside the corrsponding range.

From the TIFF specification about MaxSampleValue:

"This field is not to be used to affect the visual appearance of an image when it is
displayed or printed. Nor should this field affect the interpretation of any other
field; it is used only for statistical purposes.

Default is 2**(BitsPerSample) - 1."

If an image is floating point, Octave should return an array of the single-precision floating point values unmodified. This is how Matlab behaves.

I'm not sure if GM can be modified to work this way, or if we need to handle loading floating-point TIFFs specially (i.e. use libtiff directly).

Either way, I don't think the bug should be closed. I would like to work on this at some point.

Patrick Noffke <pnoffke>
Fri 18 Oct 2013 03:21:25 PM UTC, comment #8:

So, should we close this bug? It can always be found through searching, but there doesn't appear to be anything we need to change in Octave's code base.

Rik <rik5>
Project Administrator
Fri 18 Oct 2013 04:47:53 AM UTC, comment #7:

It's not so much a bug in GraphicsMagick, it's just the way GM behaves when there's weird information on the image. It has been discussed that it may make sense to change that https://sourceforge.net/p/graphicsmagick/bugs/241/ but it's not something that we can change other than using something else than GM.

Carnë Draug <carandraug>
Project Member
Thu 17 Oct 2013 09:46:22 PM UTC, comment #6:

Do we need to fix anything here, or is this a bug for GraphicsMagick?

Rik <rik5>
Project Administrator
Thu 08 Aug 2013 11:55:05 PM UTC, comment #5:

The problem with the TIFF file is that the tags that specify the minimum and maximum values are both set to zero. When this happens, GraphicsMagick assumes range of 0-1.

See https://sourceforge.net/p/graphicsmagick/bugs/241/ for more details.

Carnë Draug <carandraug>
Project Member
Fri 02 Aug 2013 03:18:04 PM UTC, comment #4:

I am now attaching the image mentioned on the previous comments and how Matlab reads it.

I'm pretty sure this must also be a bug in GM, one that we have already fixed in Octave for the development version. "gm display" displays the wrong thing and so does imshow() in Octave 3.6.2 using the matrix from Matlab. However, imshow() in the current development version displays the correct image.

Carnë Draug <carandraug>
Project Member
Wed 31 Jul 2013 09:03:50 PM UTC, comment #3:

I have pushed a change that allows us to read images with floating point and the images originally attached on this bug report are now read correctly.

The problem is that when GraphicsMagick (GM) reads an image, it converts the values to whatever quantum depth it was built with. In the case of a floating point image with GM built with quantum 32, the values get converted to uint32. I'm dividing by intmax("uint32") to get a matrix in the range of [0 1] which is what Matlab as valid image of floating point. However, it seems that Matlab is not always following this. The attached image is read (in Matlab) as a matrix with the range [-0.038814 82.092]. It doesn't seem to be possible to access the original image values through GM.

Carnë Draug <carandraug>
Project Member
Thu 18 Jul 2013 03:50:09 AM UTC, comment #2:

That's interesting. My build of GraphicsMagick (quantum 32) reports a depth of 32. So apparently there's no way to find out the actual bit depth of an image, the value reported is capped by the build.

I think the problem of incorrectly identifying images with only two values as logical can be fixed. The issue seems to come from using modulusDepth() instead of depth(). And at first glance, implementing the reading of floating point images seems to not be a lot of trouble.

Carnë Draug <carandraug>
Project Member
Thu 13 Jun 2013 09:35:47 PM UTC, comment #1:

The attached files (gmtest.cpp and SimpleMakefile) can be used to test loading a TIFF with GraphicsMagick++. For the attached TIFFs, this program reports Depth = 16.

(file #28312, file #28313)

Patrick Noffke <pnoffke>
Thu 13 Jun 2013 09:11:00 PM UTC, original submission:

Octave does seem to deal well with 32 bit images. The two attached images don't load correctly. "32bit-logical.tif" is a black square with white lines and "32bit-gray.tif" is a black square with gray lines of different intensities.

The "logical" image is read as binary image in Octave, when graphicsmagick is built with quantum 32 or 16 (quantum of 8 not tested). I believe this may be because GraphicsMagick only "see" 2 values.

Interestingly the "gray" image is read as 16bit in Octave if graphicsmagick is built with quantum depth 16 (issuing the typical warning about being limited by graphicsmagick quantum depth) but gives an error "imread: invalid image file: magick_read_: image depths greater than 16-bit are not supported" when graphicsmagick is built with quantum depth 32 (the one that should be able to read it).

In matlab both images are read as "single".

The first problem may go deeper and come from some problems with GraphicsMagick. I think the second is some hard coded limitation on our code but I'll need to look into this.

Carnë Draug <carandraug>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #28312:  gmtest.cpp added by pnoffke (641B - text/x-c++src - Simple file to test loading 32-bit TIFFs with GraphicsMagick++.)
file #28313:  SimpleMakefile added by pnoffke (107B - application/octet-stream - Simple file to test loading 32-bit TIFFs with GraphicsMagick++.)
file #28310:  32bit-binary.tif added by carandraug (625kB - image/tiff)
file #28311:  32bit-gray.tif added by carandraug (625kB - image/tiff)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by pnoffke (Updated the item)
  • -unavailable- added by pnoffke
  • -unavailable- added by carandraug (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 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 13 Jun 2013 09:35:47 PM UTCpnoffkeAttached File-=>Added gmtest.cpp, #28312
      Attached File-=>Added SimpleMakefile, #28313
    Thu 13 Jun 2013 09:18:48 PM UTCpnoffkeCarbon-Copy-=>Added pnoffke
    Thu 13 Jun 2013 09:11:00 PM UTCcarandraugAttached File-=>Added 32bit-binary.tif, #28310
      Attached File-=>Added 32bit-gray.tif, #28311

    Back to the top


    Powered by Savane 3.1-cleanup