[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bugs involving imread, imwrite, and GraphicsMagick
From: |
John Swensen |
Subject: |
Bugs involving imread, imwrite, and GraphicsMagick |
Date: |
Mon, 20 Sep 2010 18:38:00 -0400 |
I have started looking through the bug list to see if there is anything I could
knock off in a few hours time. I noticed that a lot of the bug involve imread,
imwrite, and GraphicsMagick. I thought it would be appropriate to repost my
comments on one of the bugs and get the maintainers opinions.
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 went back and
looked at some comments around the time things switched and there were
complaints that the ImageMagick maintainers were changing the API too regularly.
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. The
16 bit subset.tif image from the bug reads perfectly fine and when I try to
write a uint16 matrix it is written as a 16 bit TIFF. My feel is that the
ImageMagick++ API can't be changing that much if I am able to easily switch
just the include and library directories in the configure script and have
everything still work (and better than GraphicsMagick).
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.
I am willing to take the task of making a monolithic patchset that includes a
switch back to ImageMagick (if maintainers agree this is amenable) and the
additional ML compatibility mods. If anyone else has started on this already,
let me know so we don't duplicate effort.
Any comments or other thoughts.
John Swensen
- Bugs involving imread, imwrite, and GraphicsMagick,
John Swensen <=
- Bugs involving imread, imwrite, and GraphicsMagick, John W. Eaton, 2010/09/20
- Re: Bugs involving imread, imwrite, and GraphicsMagick, John Swensen, 2010/09/20
- Re: Bugs involving imread, imwrite, and GraphicsMagick, Jordi GutiƩrrez Hermoso, 2010/09/20
- Re: Bugs involving imread, imwrite, and GraphicsMagick, John Swensen, 2010/09/20
- Re: Bugs involving imread, imwrite, and GraphicsMagick, John W. Eaton, 2010/09/20
- Re: Bugs involving imread, imwrite, and GraphicsMagick, John Swensen, 2010/09/21
- Re: Bugs involving imread, imwrite, and GraphicsMagick, John Swensen, 2010/09/21
- Re: Bugs involving imread, imwrite, and GraphicsMagick, John W. Eaton, 2010/09/29