merging imread and imwrite

[John W. Eaton]

I'd like to get imread and imwrite functions in Octave.  I see that
there are functions in Octave Forge, but they will need some work.

The core of imread is

    ## divert jpegs and pngs to "jpgread" and "pngread"
    if ( file_in_loadpath("jpgread.oct") &&
      (strcmp(ext, ".JPG") || strcmp(ext, ".JPEG")) )
      varargout{1} = jpgread(fn);
      break
    endif
    if ( file_in_loadpath("pngread.oct") && (strcmp(ext, ".PNG")) )
      varargout{1} = pngread(fn);
      break
    endif
   
    ## alternately, use imagemagick
    if ( file_in_loadpath("__magick_read__.oct") )
      [varargout{1:nargout}] = __magick_read__(fn, varargin{:});
      break
    endif

Why not use ImageMagick to do all the work instead of special-casing
jpg and png files?

Also, is there some other graphics library that we could wrap to
handle reading and writing image files that might be better, or is
ImageMagick a good choice?

I see that the Matlab docs claim the following formats are handled:

  imead  imwrite
  -----  -------
   bmp     bmp
           cur
   gif     gif
   hdf     hdf
           ico
   jpg     jpg
   pbm     pbm
   pcx     pcx
   pgm     pgm
   png     png
   pnm
   ppm     ppm
   ras     ras
   tif     tif
   xwd     xwd


Comments?

jwe

[Søren Hauberg]

man, 28 01 2008 kl. 17:56 -0500, skrev John W. Eaton:

> I'd like to get imread and imwrite functions in Octave.  I see that
> there are functions in Octave Forge, but they will need some work.
>
> The core of imread is
>
>     ## divert jpegs and pngs to "jpgread" and "pngread"
>     if ( file_in_loadpath("jpgread.oct") &&
>       (strcmp(ext, ".JPG") || strcmp(ext, ".JPEG")) )
>       varargout{1} = jpgread(fn);
>       break
>     endif
>     if ( file_in_loadpath("pngread.oct") && (strcmp(ext, ".PNG")) )
>       varargout{1} = pngread(fn);
>       break
>     endif
>    
>     ## alternately, use imagemagick
>     if ( file_in_loadpath("__magick_read__.oct") )
>       [varargout{1:nargout}] = __magick_read__(fn, varargin{:});
>       break
>     endif
>
> Why not use ImageMagick to do all the work instead of special-casing
> jpg and png files?

I guess if the user doesn't link against libmagick, but do link against
libpng then the above makes sense.

> Also, is there some other graphics library that we could wrap to
> handle reading and writing image files that might be better, or is
> ImageMagick a good choice?
I don't know if ImageMagick still insists on breaking their API on a
regular basis, but some time ago they did. If this is an issue then
GraphicsMagick might be a better choice (it's a fork of ImageMagick that
attempts to keep their API stable).

Søren

[John W. Eaton]

On 29-Jan-2008, Søren Hauberg wrote:

| > Also, is there some other graphics library that we could wrap to
| > handle reading and writing image files that might be better, or is
| > ImageMagick a good choice?
| I don't know if ImageMagick still insists on breaking their API on a
| regular basis, but some time ago they did. If this is an issue then
| GraphicsMagick might be a better choice (it's a fork of ImageMagick that
| attempts to keep their API stable).

Would using the GraphicsMagick++ library be a good choice?  Will that
cause trouble for Windows or OS X?  My goal is to simplify the
imread/imwrite functions.  Ideally, it seems that those functions
should be very simple, and we wouldn't need to have special cases for
the actual reading or writing various image types, though we would
need some logic to properly convert given image types/bitdepths to the
right data type for compatibility with Matlab's imread function.
Perhaps almost all of that could be handled in a .m file.

jwe

[Michael Goffioul-2]

On 1/30/08, John W. Eaton <jwe@...> wrote:
> Would using the GraphicsMagick++ library be a good choice?  Will that
> cause trouble for Windows or OS X?

>From their web site, it seems compilable under Windows, and even
with MSVC. However, Magick++ requires special initialization as
explained here: http://www.graphicsmagick.org/www/Magick++/index.html

Michael.

[John W. Eaton]

On 31-Jan-2008, Michael Goffioul wrote:

| On 1/30/08, John W. Eaton <jwe@...> wrote:
| > Would using the GraphicsMagick++ library be a good choice?  Will that
| > cause trouble for Windows or OS X?
|
| >From their web site, it seems compilable under Windows, and even
| with MSVC. However, Magick++ requires special initialization as
| explained here: http://www.graphicsmagick.org/www/Magick++/index.html

Yes, that says you need to pass the location of the GraphicsMagick
DLLs to the function InitializeMagick.  I think that should be easy
enough to arrange.

jwe

[John W. Eaton]

On 30-Jan-2008, I wrote:

| Would using the GraphicsMagick++ library be a good choice?  Will that
| cause trouble for Windows or OS X?  My goal is to simplify the
| imread/imwrite functions.  Ideally, it seems that those functions
| should be very simple, and we wouldn't need to have special cases for
| the actual reading or writing various image types, though we would
| need some logic to properly convert given image types/bitdepths to the
| right data type for compatibility with Matlab's imread function.
| Perhaps almost all of that could be handled in a .m file.

It seems that the __magick_read__ function in Octave Forge does what I
was expecting (and more).  Since ImageMagick can read jpeg and png
files, why do we have separate functions for reading and writing these
formats?  Is it just so that we can read them if ImageMagick is not
availble?  If so, then I think we should just drop them and require
ImageMagick in order to read/write image files.

Also, it might be useful to make some of the other ImageMagick
funtions available in Octave.

jwe

[David Bateman]

John W. Eaton wrote:

> On 30-Jan-2008, I wrote:
>
> | Would using the GraphicsMagick++ library be a good choice?  Will that
> | cause trouble for Windows or OS X?  My goal is to simplify the
> | imread/imwrite functions.  Ideally, it seems that those functions
> | should be very simple, and we wouldn't need to have special cases for
> | the actual reading or writing various image types, though we would
> | need some logic to properly convert given image types/bitdepths to the
> | right data type for compatibility with Matlab's imread function.
> | Perhaps almost all of that could be handled in a .m file.
>
> It seems that the __magick_read__ function in Octave Forge does what I
> was expecting (and more).  Since ImageMagick can read jpeg and png
> files, why do we have separate functions for reading and writing these
> formats?  Is it just so that we can read them if ImageMagick is not
> availble?  If so, then I think we should just drop them and require
> ImageMagick in order to read/write image files.
>  

There were some issues a few years back with changing APIs in
imagemagick and so Paul chose to make the older png and jpeg read
functions the default to ensure that at least png and jpeg could be read
even if the user had incompatible versions of imagemagick installed. One
disadvantage with this is that pngread doesn't treat the transparency
whereas the imagmagick version of the function does..

If the API stabilized then this workaround can be dropped...

D.


--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

[Thomas Treichl]

David Bateman schrieb:

> John W. Eaton wrote:
>> On 30-Jan-2008, I wrote:
>>
>> | Would using the GraphicsMagick++ library be a good choice?  Will that
>> | cause trouble for Windows or OS X?  My goal is to simplify the
>> | imread/imwrite functions.  Ideally, it seems that those functions
>> | should be very simple, and we wouldn't need to have special cases for
>> | the actual reading or writing various image types, though we would
>> | need some logic to properly convert given image types/bitdepths to the
>> | right data type for compatibility with Matlab's imread function.
>> | Perhaps almost all of that could be handled in a .m file.
>>
>> It seems that the __magick_read__ function in Octave Forge does what I
>> was expecting (and more).  Since ImageMagick can read jpeg and png
>> files, why do we have separate functions for reading and writing these
>> formats?  Is it just so that we can read them if ImageMagick is not
>> availble?  If so, then I think we should just drop them and require
>> ImageMagick in order to read/write image files.
>>  
> There were some issues a few years back with changing APIs in
> imagemagick and so Paul chose to make the older png and jpeg read
> functions the default to ensure that at least png and jpeg could be read
> even if the user had incompatible versions of imagemagick installed. One
> disadvantage with this is that pngread doesn't treat the transparency
> whereas the imagmagick version of the function does..
>
> If the API stabilized then this workaround can be dropped...
>
> D.

There won't be a problem on MacOSX -- it's just a question about how many
library dependencies should be solved before building ImageMagick and use that
for Octave? Sure, the best thing would be 'all' but I think then we would at
least double the size of an Octave standalone binary application just because of
graphics libraries?! So I'm out of ideas here -- what is the best middle course?

   Thomas

[John W. Eaton]

On 31-Jan-2008, Thomas Treichl wrote:

| There won't be a problem on MacOSX -- it's just a question about how many
| library dependencies should be solved before building ImageMagick and use that
| for Octave? Sure, the best thing would be 'all' but I think then we would at
| least double the size of an Octave standalone binary application just because of
| graphics libraries?! So I'm out of ideas here -- what is the best middle course?

If we only linked the ImageMagick libraries with the .oct files that
need them, then the Octave binary itself would not be larger, but yes,
it is somewhat more complicated to build a fully functional Octave
distribution if there are more dependencies.

OTOH, if all we are doing is reading some image files, maybe ImageMagick
is more than we need.  Are there other portable libraries available
that support a reasonable number of image formats and that just read
and write without being full image processing libraries?

jwe

[Thomas Treichl]

John W. Eaton schrieb:

> On 31-Jan-2008, Thomas Treichl wrote:
>
> | There won't be a problem on MacOSX -- it's just a question about how many
> | library dependencies should be solved before building ImageMagick and use that
> | for Octave? Sure, the best thing would be 'all' but I think then we would at
> | least double the size of an Octave standalone binary application just because of
> | graphics libraries?! So I'm out of ideas here -- what is the best middle course?
>
> If we only linked the ImageMagick libraries with the .oct files that
> need them, then the Octave binary itself would not be larger, but yes,
> it is somewhat more complicated to build a fully functional Octave
> distribution if there are more dependencies.
>
> OTOH, if all we are doing is reading some image files, maybe ImageMagick
> is more than we need.  Are there other portable libraries available
> that support a reasonable number of image formats and that just read
> and write without being full image processing libraries?
>
> jwe

If eg. the libpng, libtiff and libjpeg libraries could be used directly then I
think this would be a great thing because they are very small and can be build
easily (are there any other famous pixel formats, eg. like .bmp on Windows? On a
Mac I noticed that most apps do want a .tiff format). For Gnuplot.app I need to
compile gdlib - it seems to be a layer above png, jpeg and others but I actually
can't tell any details about it...

   Thomas

[Søren Hauberg]

tor, 31 01 2008 kl. 15:50 -0500, skrev John W. Eaton:
> OTOH, if all we are doing is reading some image files, maybe ImageMagick
> is more than we need.  Are there other portable libraries available
> that support a reasonable number of image formats and that just read
> and write without being full image processing libraries?
I remember looking for such a library some time ago, and I've never been
able to find anything :-(

Søren

[John W. Eaton]

On 31-Jan-2008, Thomas Treichl wrote:

| If eg. the libpng, libtiff and libjpeg libraries could be used directly then I
| think this would be a great thing because they are very small and can be build
| easily (are there any other famous pixel formats, eg. like .bmp on Windows? On a
| Mac I noticed that most apps do want a .tiff format). For Gnuplot.app I need to
| compile gdlib - it seems to be a layer above png, jpeg and others but I actually
| can't tell any details about it...

I haven't looked, but I would bet that a problem with using the
individual libraries directly is that you have to use N different ways
of calling the read functions for N different image formats.  It would
be nice if someone had already done the work to package these things
up in a simple interface.

Has anyone looked at DevIL (http://openil.sourceforge.net)?  It is
LGPL and there are Debian packages and apparently RPM files and a
Windows build.  What about the licenses of the dependencies?  They
must also be GPL compatible.

It also seems to have functions available for displaying images with
OpenGL, which I assume would fit nicely with the new graphics
features.

jwe

[John W. Eaton]

On 31-Jan-2008, John W. Eaton wrote:

| Has anyone looked at DevIL (http://openil.sourceforge.net)?  It is
| LGPL and there are Debian packages and apparently RPM files and a
| Windows build.  What about the licenses of the dependencies?  They
| must also be GPL compatible.
|
| It also seems to have functions available for displaying images with
| OpenGL, which I assume would fit nicely with the new graphics
| features.

OK, I looked, and while it is smaller than the Magick++ library, it
also uses an unusual method of managing images.  I think I would much
prefer to work with the classes provided by Magick++.  Using reference
counted images seems much more natural to me than having a database of
images indexed by names.

Maybe the Magick++ library could be split into smaller pieces?  Or
maybe it doesn't really matter, as even with all the dependencies it
is just a few megabytes and memory is cheap these days (right?).

jwe

[shaiay]

On Feb 1, 2008 8:41 AM, John W. Eaton <jwe@...> wrote:

> On 31-Jan-2008, John W. Eaton wrote:
>
> | Has anyone looked at DevIL (http://openil.sourceforge.net)?  It is
> | LGPL and there are Debian packages and apparently RPM files and a
> | Windows build.  What about the licenses of the dependencies?  They
> | must also be GPL compatible.
> |
> | It also seems to have functions available for displaying images with
> | OpenGL, which I assume would fit nicely with the new graphics
> | features.
>
> OK, I looked, and while it is smaller than the Magick++ library, it
> also uses an unusual method of managing images.  I think I would much
> prefer to work with the classes provided by Magick++.  Using reference
> counted images seems much more natural to me than having a database of
> images indexed by names.
>
> Maybe the Magick++ library could be split into smaller pieces?  Or
> maybe it doesn't really matter, as even with all the dependencies it
> is just a few megabytes and memory is cheap these days (right?).

I'm not exactly sure how dynamic linking works, but is there no way to
add this to octave such that if someone does not use imread/imwrite
then the libraries don't get loaded to memory?
Shai

[John W. Eaton]

On  1-Feb-2008, Shai Ayal wrote:

| I'm not exactly sure how dynamic linking works, but is there no way to
| add this to octave such that if someone does not use imread/imwrite
| then the libraries don't get loaded to memory?

We can do this by just linking the Magick++ library to the
imread/imwrite/etc. .oct files and not to Octave itself.  This is
currently the way we handle several other libraries.  For example, see
the following lines in src/Makefile.in:

  ifeq ($(ENABLE_DYNAMIC_LINKING), true)
    ifdef CXXPICFLAG
      convhulln.oct : pic/convhulln.o octave$(EXEEXT)
            $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(QHULL_LIBS)
      __delaunayn__.oct : pic/__delaunayn__.o octave$(EXEEXT)
            $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(QHULL_LIBS)
      __voronoi__.oct : pic/__voronoi__.o octave$(EXEEXT)
            $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(QHULL_LIBS)
      regexp.oct : pic/regexp.o octave$(EXEEXT)
            $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(REGEX_LIBS)
      urlwrite.oct : pic/urlwrite.o octave$(EXEEXT)
            $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(CURL_LIBS)
      __glpk__.oct : pic/__glpk__.o octave$(EXEEXT)
            $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(GLPK_LIBS)
    else
      ...
    endif
  endif

The $(QHULL_LIBS), $(REGEX_LIBS), $(CURL_LIBS), and $(GPLK_LIBS)
should not be linked to Octave itself, or
liboctinterp/liboctave/libcruft.

jwe

[shaiay]

On Feb 1, 2008 9:53 AM, John W. Eaton <jwe@...> wrote:

> On  1-Feb-2008, Shai Ayal wrote:
>
> | I'm not exactly sure how dynamic linking works, but is there no way to
> | add this to octave such that if someone does not use imread/imwrite
> | then the libraries don't get loaded to memory?
>
> We can do this by just linking the Magick++ library to the
> imread/imwrite/etc. .oct files and not to Octave itself.  This is
> currently the way we handle several other libraries.  For example, see
> the following lines in src/Makefile.in:
>
>   ifeq ($(ENABLE_DYNAMIC_LINKING), true)
>     ifdef CXXPICFLAG
>       convhulln.oct : pic/convhulln.o octave$(EXEEXT)
>             $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(QHULL_LIBS)
>       __delaunayn__.oct : pic/__delaunayn__.o octave$(EXEEXT)
>             $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(QHULL_LIBS)
>       __voronoi__.oct : pic/__voronoi__.o octave$(EXEEXT)
>             $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(QHULL_LIBS)
>       regexp.oct : pic/regexp.o octave$(EXEEXT)
>             $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(REGEX_LIBS)
>       urlwrite.oct : pic/urlwrite.o octave$(EXEEXT)
>             $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(CURL_LIBS)
>       __glpk__.oct : pic/__glpk__.o octave$(EXEEXT)
>             $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(GLPK_LIBS)
>     else
>       ...
>     endif
>   endif
>
> The $(QHULL_LIBS), $(REGEX_LIBS), $(CURL_LIBS), and $(GPLK_LIBS)
> should not be linked to Octave itself, or
> liboctinterp/liboctave/libcruft.
>

well, it looks like a good compromise -- those needing the
functionality will be happy to pay the (memory) price for
imread/imwrite, while others will not pay anything.
The only problem is then for packagers who want to provide a complete
octave distribution, which will now have to provide the new library/

Shai

[Michael Goffioul-2]

On Fri, Feb 1, 2008 at 7:41 AM, John W. Eaton <jwe@...> wrote:
> OK, I looked, and while it is smaller than the Magick++ library, it
> also uses an unusual method of managing images.  I think I would much
> prefer to work with the classes provided by Magick++.  Using reference
> counted images seems much more natural to me than having a database of
> images indexed by names.
>
> Maybe the Magick++ library could be split into smaller pieces?  Or
> maybe it doesn't really matter, as even with all the dependencies it
> is just a few megabytes and memory is cheap these days (right?).

Given the common origin of ImageMagick and GraphicsMagick, I'm
alwo wondering if the code could be made compilable with one or
the other?

Michael.

[Thomas Treichl]

Shai Ayal schrieb:

> On Feb 1, 2008 9:53 AM, John W. Eaton <jwe@...> wrote:
>> On  1-Feb-2008, Shai Ayal wrote:
>>
>> | I'm not exactly sure how dynamic linking works, but is there no way to
>> | add this to octave such that if someone does not use imread/imwrite
>> | then the libraries don't get loaded to memory?
>>
>> We can do this by just linking the Magick++ library to the
>> imread/imwrite/etc. .oct files and not to Octave itself.  This is
>> currently the way we handle several other libraries.  For example, see
>> the following lines in src/Makefile.in:
>>
>>   ifeq ($(ENABLE_DYNAMIC_LINKING), true)
>>     ifdef CXXPICFLAG
>>       convhulln.oct : pic/convhulln.o octave$(EXEEXT)
>>             $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(QHULL_LIBS)
>>       __delaunayn__.oct : pic/__delaunayn__.o octave$(EXEEXT)
>>             $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(QHULL_LIBS)
>>       __voronoi__.oct : pic/__voronoi__.o octave$(EXEEXT)
>>             $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(QHULL_LIBS)
>>       regexp.oct : pic/regexp.o octave$(EXEEXT)
>>             $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(REGEX_LIBS)
>>       urlwrite.oct : pic/urlwrite.o octave$(EXEEXT)
>>             $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(CURL_LIBS)
>>       __glpk__.oct : pic/__glpk__.o octave$(EXEEXT)
>>             $(DL_LD) $(DL_LDFLAGS) -o $@ $< $(OCT_LINK_DEPS) $(GLPK_LIBS)
>>     else
>>       ...
>>     endif
>>   endif
>>
>> The $(QHULL_LIBS), $(REGEX_LIBS), $(CURL_LIBS), and $(GPLK_LIBS)
>> should not be linked to Octave itself, or
>> liboctinterp/liboctave/libcruft.
>>
> well, it looks like a good compromise -- those needing the
> functionality will be happy to pay the (memory) price for
> imread/imwrite, while others will not pay anything.
> The only problem is then for packagers who want to provide a complete
> octave distribution, which will now have to provide the new library/

Adding another library to the scripts that run in the background and that are
used for building eg. Octave.app is not so hard - it just needs some time until
finished. When this has been done the automation procedure can also be used for
the following releases without big modifications. And it doesn't matter if
machine compiles 3h or 4h while I'm sleeping ;) That's ok.

However, I still think that all backends of ImageMagick are not needed for an
standalone Octave pack and some compromise about which backend should be added
and which one should be left away must be done (eg. ?jbig, lcms, lqr, openexr? -
I actually have never heard of them before - are they needed?)...

   Thomas

[Daniel J Sebald]

John W. Eaton wrote:
> On  1-Feb-2008, Shai Ayal wrote:
>
> | I'm not exactly sure how dynamic linking works, but is there no way to
> | add this to octave such that if someone does not use imread/imwrite
> | then the libraries don't get loaded to memory?
>
> We can do this by just linking the Magick++ library to the
> imread/imwrite/etc. .oct files and not to Octave itself.  This is
> currently the way we handle several other libraries.

The "convert" technique does work now.  Interconnecting smaller programs is the "unix-y" way of doing things.

At work today I may (repeat *may*) have found a bug in reading a particular PNG file.  It could be the file is not encoded correctly, but it does appear correct in "display" and in "gthumb".  Similar images read through "imread" work correctly.  But this one horizontally is too short and then repeats a portion (1/3) of the image.

Looking at "imread" I notice that JPEG and PNG files are actually handled separate from ImageMagick, via pngread() and jpgread().  So if there is a bug, it is in pngread().  I see that pngread() is a C++ file.  I typed "type pngread" and Octave spits out all the ASCII characters in computer hieroglyphics.  Is it supposed to do that for .cc functions?

Anyway, as it currently stands, it appears that ImageMagick isn't all that would be needed for the port you are discussing.  Two of the significant formats are handled differently.  Does that have any significance to the discussion?

Dan

[John W. Eaton]

On  1-Feb-2008, Daniel J Sebald wrote:

| Looking at "imread" I notice that JPEG and PNG files are actually
| handled separate from ImageMagick, via pngread() and jpgread().  So
| if there is a bug, it is in pngread().

By using Magick++ to read all image files, I would hope to eliminate
most problems like this.

| I see that pngread() is a C++ file.  I typed "type pngread" and
| Octave spits out all the ASCII characters in computer hieroglyphics.
| Is it supposed to do that for .cc functions?

No, that's a bug.  Thanks for reminding me about it.

| Anyway, as it currently stands, it appears that ImageMagick isn't
| all that would be needed for the port you are discussing.  Two of
| the significant formats are handled differently.  Does that have any
| significance to the discussion?

They don't have to be handled differently.  We can use Magick++ to
read png and jpeg files, though I think it ultimately uses libpng and
libjpeg to actually read them.

I think the original intent of the imread code was to work for jpeg or
png files even if Magick++ libraries were not installed, but the logic
there seems a bit backward.  I think I would have had it try Magick++
first.

In any case, I think I'd like to just use Magick++ to read and write
image files when we move this code from the Octave Forge image package
to Octave.

jwe