octave-maintainers
[Top][All Lists]
Advanced

[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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]