Re: Bugs involving imread, imwrite, and GraphicsMagick

[John Swensen]

On Sep 20, 2010, at 8:15 PM, John W. Eaton wrote:

> On 20-Sep-2010, John Swensen wrote:
> 
> | 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?
> 
By better, I simply meant that both MacPorts and Ubuntu 10.04 packages of 
ImageMagick use QuantumDepth=16 by default so Octave automatically has support 
for 16 bit depth image reading and writing.  Had GraphicsMagick been built with 
QuantumDepth=16, Octave's imread and imwrite would work equally well.  The only 
problem I see is that bug reports/wish lists have been reported to 
Ubuntu/Debian and MacPorts year(s) ago and the package maintainers seem to be 
dragging their feet about making QuantumDepth=16 the default for the official 
package distributions.  This means that any user that wants to have 16 bit 
depth support has to not only compile GraphicsMagick themselves, but they have 
to compile Octave also.  That may be a pretty daunting task for someone just 
getting started with Octave.

I would propose that we switch to ImageMagick (as there are no changes required 
other than updating configure.ac) to have QuantumDepth=16 support until the 
various package maintainers for standard distributions get around to changing 
their mind.  Or alternatively we could simply have GraphicsMagick the default 
and allow a user to specify they want to use ImageMagick as an option to 
configure.  This will at least allow the Octave package maintainers for 
Debian/Ubuntu and MacPorts to have the ability to have QuantumDepth=16 in any 
packages that are released prior to the change in the GraphicsMagick build 
settings by its respective package maintainers.

**** Note: MacPorts does have a variant for QuantumDepth 16 and 32, but 8 is 
still the default.

> | 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.
> 
The reason I said monolithic is because I expect that a careful refactor of 
imread and imwrite to be ML compatible may take care of all of the bugs 
simultaneously.  I plan on making a single patch to make them ML compatible and 
see if that closes all the outstanding imread/imwrite bugs.

John Swensen