Bugs involving imread, imwrite, and GraphicsMagick

[John W. Eaton]

On 20-Sep-2010, John Swensen wrote:

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

As I recall, the decision to use GraphicsMagick was all about the
promised stability of the API and had nothing to do with performance.

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

GrahpicsMagick can also use QuantumDepth of 16, right?  So I don't see
that the default matters much.  We just need to get people to use 16
if they want to get things right with Octave.  WE also have no way of
knowing whether the default used by ImageMagick will change in the
future, so this issue alone does not seem to me to be sufficient to
switch to ImageMagick.

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

By "better" do you mean just that it uses 16 bits by default instead
of 8?  If you compile GraphicsMagick with QuantumDepth = 16, is there
any significant difference?

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

Why "monolithic"?  Is there any reason individual bugs can't be fixed
one at a time?  It would certainly make evaluating patches easier.

jwe