Re: merging imread and imwrite

[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                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

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