bugGNU Octave - Bugs: bug #30715, imread fails to read uint16 tif...

 
 

bug #30715: imread fails to read uint16 tif image

Submitter:  None
Submitted:  Mon 09 Aug 2010 02:54:50 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Paolo Prosperi Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.2.4
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 21 Aug 2013 02:28:29 AM UTC, comment #21: 

Carne, I can't verify this because my QuantumDepth is set at 8.  But if you have verified this then go ahead and close it.

Rik <rik5>
Group administrator
Fri 02 Aug 2013 06:35:02 PM UTC, comment #20: 

Testing with a set of tiff, gif and lsm pcitures I had from work, I have found that the depth () method returns the original image bitdepth. I have changed imread () to use it instead of moduloDepth (). Can this bug be closed? There was also the issue of trying to make the warning about being limited to specific bit depth bigger.

Carnë Draug <carandraug>
Group Member
Wed 15 Jun 2011 03:01:47 PM UTC, comment #19: 

Two updates on my side.
I was able to overcome the imread bug I notified  last year by using a tiffread.m script (v2.9), that can be found here:
http://www.embl.de/~nedelec/misc/index.html
Now in Octave I can correctly read in and use uint16 type of images.
As for writing them back, I found imwrite does work (Rik wrote it didn't), but only if "-depth 16" option is used (i.e., providing the input image is uint16, imout=imwrite('filename',image,"-depth 16") ).
It would be good if this and the other imwrite options were mentioned in the Octave manual. You need to open the imwrite.m file and read through imagemagick documnetation to find that out.

paolo prosperi <pprosp>
Tue 05 Oct 2010 07:47:47 PM UTC, comment #18: 

I dropped an email to -email is unavailable- asking whether 1) it is possible to add "or any later version" to the GPL license and 2) if the attribution/advertisement clause could be removed from the GPL licensing option.

That was 17 September, and I still haven't gotten a reply.

Swensen: I'm glad to hear you work on this.  The image I/O routines are in badly need of love.

David Grundberg <grundberg>
Tue 21 Sep 2010 03:15:54 AM UTC, comment #17: 

My problem with the FreeImage library is that it doesn't have support for all the formats needed for ML compatibility.  *Magick actually has the functionality, it is just a matter of lighting the fire under the the package maintainers to enable the needed functionality.  I have actually worked a little bit with GraphicsMagick in the last week or so and I actually like the interface and the documentation.  I actually think that in terms of a library that provides so much functionality, it is quite well done.

I also did a search for other possible open source libraries with image IO capabilities.  It seems FreeImage comes the closest to meeting the needs, but I think the API and format capabilities still lag behind *Magick significantly.

John Swensen <jpswensen>
Tue 21 Sep 2010 02:55:33 AM UTC, comment #16: 

I don't think either *Magick is the best solution. ImageMagick is nicer because its default QuantumDepth is 16, but once someone tries to read a 32-bit image this "bug" will pop up again.

Jonathan Thomson <jthomson>
Mon 20 Sep 2010 10:18:04 PM UTC, comment #15: 

Is there a reason Octave switched from ImageMagick to GraphicsMagick?  Was it because of some of the speedups for GraphicsMagick?  If we are simply using the *Magick for image reading and writing and not for image transformations, I don't think any of the GraphicsMagick speedups are pertinent. 

I looked at the configure script for ImageMagick and verified the default QuantumDepth for ImageMagick is 16.  I also compiled and ran gm_ver against ImageMagick on Ubuntu 10.04 and verified the QuantumDepth is actually 16.

Then, I did a quick modification of Octave's configure.ac to use ImageMagick includes and libraries and Octave compiled with no modifications necessary.  It reads your subset.tif image perfectly fine.

All this being said, I think imread and imwrite need a lot of work to be ML compatible.  This mostly involves a lot of modifications to allow options for the various file formats and better inference of output file properties (e.g. bit depth, etc) based on the variable type passed in.  Currently the only option that is handled is the quality option for JPG images.  I have a paper due Wed Sept 22, but plan on working on this soon after it is submitted.

JWE, you can assign this bug to me (if you want) and I will make a monolithic patchset that includes a switch back to ImageMagick and the additional ML compatibility mods.  If anyone else has started on this already, let me know so we don't duplicate effort.




John Swensen <jpswensen>
Tue 14 Sep 2010 05:19:18 PM UTC, comment #14: 

I would consider a switch to another image library.  I don't know anything about freeimage, so I can't say whether that is the right choice.  It may be distributed under the terms of GPLv2 or any later version, so that's good.  However, I'm curious about the following statement on the freeimage web site (http://freeimage.sourceforge.net/license.html):

  When using FreeImage in your open source or commercial application, you are REQUIRED to:

  * provide a suitable acknowledgement, either in the program's "About" box or in the user's manual (or both), for example :

    This software uses the FreeImage open source image library. See http://freeimage.sourceforge.net for details.  FreeImage is used under the (GNU GPL or FIPL), version (license version).

I don't object to giving credit, but doesn't that additional requirement conflict with the terms of the GPL?

John W. Eaton <jwe>
Group administrator
Thu 09 Sep 2010 08:38:29 PM UTC, comment #13: 

It's too bad that the overall design of GraphicsMagick makes it very hard to do what I (and I suspect many others) want.  I basically want the matrix returned to be the same bitdepth as it was stored.  As it stands now, you can have a 8-bit rgb image, imwrite it, and have a 1-bit bitmap saved on file because the matrix just so happened to be just black and white.

The freeimage library may be an alternative.

David Grundberg <grundberg>
Fri 03 Sep 2010 03:38:49 AM UTC, comment #12: 

This is from an email from Bob Friesenhahn, GraphicsMagick Maintainer.

[begin e-mail]

> Is there any way at all, in GraphicsMagick, to determine that the precision of an image has been down-scaled?


Not that I am aware of.  With over 100 subformats, accomplishing that could be challenging.  With quite a lot of effort, additional attributes could be added to the image which provide more origin information.  It is not always possible to know the actual depth.
Useful attributes could be added for just a few important subformats.

The easiest solution is to always use the Q16 build.  This does take more memory and is slower, but it is also the build that I spend most of my time optimizing.  There is also a Q32 build for fanatics.

Even with the Q16 or Q32 build there are some formats which will still lose information, such as formats containing 32 or 64 bit floats.

Bob
[end e-mail]

I believe the QuantumDepth limitation stems from the fact that GraphicsMagick is not just an image reader but is an integer math image manipulation program. Perhaps there is some other library (better suited for Octave) that's purpose is to simply read and write image data without loss of precision.

Jonathan Thomson <jthomson>
Fri 03 Sep 2010 03:16:15 AM UTC, comment #11: 

If GraphicsMagick is compiled with a Quantum Depth of 8 (Q8) then modulusDepth() will never return a value greater than 8. There is currently no function in GraphisMagick to get an image's original bit depth. It is normal behaviour for a 16 bit TIFF to be degraded to 8 bits if GraphicsMagick is Q8.

>>Should Octave's configure script check to see whether the GraphicsMagick libraries were compiled with 8 or 16 bit quantum depth? If we detect 8 bits, what should we do?


I suggest throwing a warning and strongly recommend Q16.

>> ... a patch for magick_read.cc so we can have a better error message for images that GraphicsMagick won't be able to read.

The problem isn't that the image can't be read. The problem is that GraphicsMagick will happily read images with bit depths greater than the QuantumDepth and imread returns the lower precision image data without error. The solution should be for Octave to throw an error if the image can't be read without lowering it's precision. However the method to determine that precision will be lost eludes me.

>> Is there a way to give a better error message when 16 bit images can't be read properly?

My idea was to compare the original bit depth of the image to QuantumDepth and if bit depth is greater than QuantumDepth then precision has been lost. However gm has no method to return the images original bit depth. Graphicsmagick might have some other means of reporting that precision has been lost, but I'm doubtful it does. Therefore the #if (QuantumDepth > ?) macros don't do anything and are unnecessary. Including the QuantumDepth in an error message might be useful but is not necessary.
#include <magick/magick_config.h>
...
error ("__magic_read__: index depths bigger than %d-bit not supported", QuantumDepth);



As Octave should undoubtedly be able to read medical and scientific images, which are often 16 bits, using the Q8 libraries of GraphicsMagick should be considered unacceptable. Perhaps even Q32 should be required. However, greater quantum depth results in more resources being used.

Jonathan Thomson <jthomson>
Wed 01 Sep 2010 12:55:36 AM UTC, comment #10: 

The QuantumDepth is defined in the header magick/magick_config.h so the QuantumDepth can be easily given to _magick_read_.cc simply by including that header.

Unfortunately images with bit depths higher than the QuantumDepth are still being incorrectly read or throwing an error even with the #if (QuantumDepth > ?) statements added because gm is incorrectly reporting the images bit depth, so case 8: is always run. From the post linked to below it sounds like min(depth,QuantumDepth) is returned from gm, but from the documentation modulusDepth() should be returning the image's depth. It's confusing. My investigation is on going.

http://sourceforge.net/mailarchive/message.php?msg_name=alpine.GSO.2.01.1008310926020.12887%40freddy.simplesystems.org

Jonathan Thomson

Jonathan Thomson <jthomson>
Sun 29 Aug 2010 02:35:44 PM UTC, comment #9: 

Thanks for the code snippets.  It would be helpful if someone would turn these into a proper changeset that provides an autoconf test so we can warn about this potential problem at configure time and also a patch for _magick_read_.cc so we can have a better error message for images that GraphicsMagick won't be able to read.

John W. Eaton <jwe>
Group administrator
Sun 29 Aug 2010 05:14:09 AM UTC, comment #8: 

Here's a test for the quantum depth.
#include <GraphicsMagick/wand/magick_wand.h>
#include <iostream>
using std::cout;
using std::endl;

int main ()
{
        unsigned long depth = 0;
        MagickGetQuantumDepth(&depth);
        cout << depth << endl;
        return depth;
}

g++ -Wall -pedantic gm_ver.cc -I/usr/include/GraphicsMagick -L/usr/lib -lGraphicsMagickWand -o gm_ver

I think a couple small changes to _magick_read_.cc can be used to add support for 16 bit images if it's available and give a friendlier error if not. GraphicsMagick can support a QuantumDepth of 32 bits so perhaps a case for 32 bit images should be added too.

#if (QuantumDepth > 8)
    case 16:
        ...
        break;
#endif
#if (QuantumDepth > 16)
    case 32:
        ...
        break;
#endif
    default:
    error ("__magic_read__: index depths bigger than %d-bit not supported", Qu

-----
Jonathan Thomson

Anonymous
Fri 27 Aug 2010 03:08:53 PM UTC, comment #7: 

Should Octave's configure script check to see whether the graphics magick libraries were compiled with 8 or 16 bit quantum depth?  If we detect 8 bits, what should we do?

Is there a way to give a better error message when 16 bit images can't be read properly?

John W. Eaton <jwe>
Group administrator
Tue 24 Aug 2010 04:18:21 AM UTC, comment #6: 

A request to compile graphics magick with --with-quantum-depth=16 for Debian was filed in November 2009, Severity: Wishlist. Until that change is made it will block a fix of the octave package. If you are interested in seeing this bug fixed please post a reply at the following bug report log.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557879

Anonymous
Sun 22 Aug 2010 04:11:17 AM UTC, comment #5: 

The "Unable to open file" errors are because octave was compiled with the 8 bit version libraries of libgraphicsmagick++1-dev and libgraphicsmagick1-dev. If you rebuild graphicsmagick from source with quantum depth of 16, then install the aforementioned dev libraries that resulted, and then rebuild octave from source you will get octave packages that properly read 16 bit images.

Here's a detailed explanation of how to do this on Debian Squeeze.
http://jethomson.wordpress.com/2010/08/22/enable-octave-to-read-16-bit-images/

This bug needs to be forwarded to the Debian maintainers to be resolved.

Anonymous
Wed 18 Aug 2010 05:33:27 AM UTC, comment #4: 

I rebuilt the graphics magick libraries from source with --quantum-depth=16 and now octave won't read 8 or 16 bit images. The graphics magick binary reads them correctly though. So the 16 bit image read error involves octave and the graphics magick library code, not just the graphics magick library.

I tested it on 8 bit JPEGs:
error: imread: invalid image file: Magick++ exception: Magick: Unable to open file (filename snipped) reported by coders/jpeg.c:955 (ReadJPEGImage)

16 bit PGMs:
error: imread: invalid image file: Magick++ exception: Magick: Unable to open file (filename snipped) reported by coders/pnm.c:275 (ReadPNMImage)

16 bit TIFFs:
error: imread: invalid image file: _magick_read_: invalid index vector

Anonymous
Sun 15 Aug 2010 10:57:01 PM UTC, comment #3: 

Actually, after looking around a bit more, I found that this not a bug, just the way GraphicsMagick is configured at compile time, with only 8-bits per quantum. If you run the command


gm -version


and you get Q8 on it (I get "GraphicsMagick 1.3.12 2010-03-08 Q8 http://www.GraphicsMagick.org/") then you need to recompile it with support for 16-bit (When you configure GraphicsMagick, add the --with-quantum-depth=16 configure option).

Carnë Draug <carandraug>
Group Member
Sun 15 Aug 2010 10:32:57 PM UTC, comment #2: 

This is not a bug in octace but in GraphicsMagick.

The following Graphicsmagick command (needs GraphicsMagick installed, not only the libraries) identifies the image attached by the reporter as an 8-bit image.

gm identify ./subset.tif
./subset.tif TIFF 207x179+0+0 DirectClass 8-bit 72.8K 0.000u 0:01

I have several other 16-bit images (the image source is  softWoRx® Suite connected to a DeltaVision microscope) that are identified as 8-bit images.

ImageJ (released under public domain), identifies the images correctly as 16-bit.

Carnë Draug <carandraug>
Group Member
Sun 15 Aug 2010 06:18:56 PM UTC, comment #1: 

Confirmed on a recent development tip (8/15/10). 

Apparently imwrite within Octave also fails to write 16-bit images.

Rik <rik5>
Group administrator
Mon 09 Aug 2010 02:54:50 PM UTC, original submission:  

I'm newbie to Octave and not a programmer. I noticed that the imread function seems unable to correctly read the data type (int16) of the hereby attached tif image. Instead, it reads pixel values as unit8. Can anybody confirm this circumstance and provide a solution to that?

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #21178:  subset.tif added by None (73KiB - 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 pprosp (Posted a comment)
  • -email is unavailable- added by jpswensen (Posted a comment)
  • -email is unavailable- added by grundberg (Posted a comment)
  • -email is unavailable- added by jthomson (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by carandraug (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by None (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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-08-21 carandraug StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2010-08-15 rik5 StatusNone Confirmed
        Summaryimread fails to read unit16 tif image imread fails to read uint16 tif image
    2010-08-09 None Attached File- Added subset.tif, #21178

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code