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.
|
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.
|
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.
|
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?
|
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.
|
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.
|
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.
|
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.
|
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)
|
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.
|