merging imread and imwrite

[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