[OctDev] Re: imread / imwrite status?

[Stefan v. d. W. <st...@su...>]

On Fri, Sep 09, 2005 at 08:34:26PM -0400, Paul Kienzle wrote:
> Octave-forge has {jpg,png}{read,write}.  imread could check if those=20
> functions are available and use them for the appropriate files,=20
> otherwise use imagemagick.

I've submitted changes that implement the above behaviour to
octave-forge CVS.  Please verify that everything still works smoothly.

Colour images should now be returned as MxNx3, with the appropriate
numeric class: logical for black & white, uint8 for grey-level/colour
and double for any other precision.  I reverted back to using
temporary files, because pipes were too slow.  One new "dependency" is
introduced: `identify', also from ImageMagick (installed along with
`convert' on most systems).

Currently, many imaging functions take r, g, and b as parameters --
this would now change to I(:,:,1), I(:,:,2), I(:,:,3).  There is,
however, no consistent interface which states whether images should be
in [0-255] or [0-1] -- using numeric classes addresses this.

Because of a bug in saveimage.m, black and white images may display
incorrectly (white stripes every 8th pixel).  Until that's fixed, a
simple workaround is to simply convert to a double:

x =3D imread('black_and_white.png');
imshow(double(x))

The next move would be to systematically work through all the imaging
functions and make sure they use the new format.  A good start would
probably be to write `im2gray'.

Regards
St=E9fan