Re: merging imread and imwrite

[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