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


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

Submitter:  Carnë Draug <carandraug>
Submitted:  Thu 13 Jun 2013 09:11:00 PM UTC
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Wont Fix Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Thu 11 Nov 2021 09:14:03 PM UTC, comment #11: 

updating to note that after reaching out to the GM folks via @carandraug's initial bug report on this:


"The problem is that GraphicsMagick uses only integer values
internally. So the float needs to be scaled to an integer range and
so min/max are needed. The TIFF specification suggestion to use a
value based on BitsPerSample does not seem terribly helpful for float

If Octave can do better internally, then using libtiff directly for
floating-point TIFFs is reasonable." -- GM Maintainer

based on this and the lack of any progress on this (8 years since the last expression of interest), closing as a Won't Fix.  can always be reopened later if someone wants to revisit the issue.

Nicholas Jankowski <nrjank>
Project Member
Wed 04 Aug 2021 08:41:26 PM UTC, comment #10: 

notice the bug seems largely unchanged since 2013, and the GM issue hasn't been updated. comment #3 mentions a third test image that doesn't seem to be attached, so hard to tell if this issue is still occurring in Octave 6.3.0, but i suspect so.

recommend closing as a 'wont fix' unless someone wants to dive into verifying status and figuring out how octave can workaround GM behavior.

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

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 #28311:  32bit-gray.tif added by carandraug (625KiB - image/tiff)
file #28310:  32bit-binary.tif added by carandraug (625KiB - image/tiff)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by pnoffke (Updated the item)
  • -email is unavailable- added by pnoffke
  • -email is unavailable- added by carandraug (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 project members can vote.





    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-11-11 nrjank StatusNone Wont Fix
        Open/ClosedOpen Closed
    2013-06-13 pnoffke Attached File- Added gmtest.cpp, #28312
        Attached File- Added SimpleMakefile, #28313
    2013-06-13 pnoffke Carbon-Copy- Added pnoffke
    2013-06-13 carandraug Attached File- Added 32bit-binary.tif, #28310
        Attached File- Added 32bit-gray.tif, #28311

    Back to the top

    Powered by Savane 3.9