imread (repost)

[Thomas L. Scofield]

On Aug 6, 2008, at 11:55 AM, John W. Eaton wrote:

> On  5-Aug-2008, John W. Eaton wrote:
>
> | On  5-Aug-2008, Thomas L. Scofield wrote:
> |
> | | In Matlab:
> | |
> | |  >> im = imread('magnolia.png');
> | |  >> whos im
> | |    Name        Size              Bytes  Class    Attributes
> | |
> | |    im        480x640            307200  uint8
> |
> | Hmm.  that seems like a bug.  Or is it documented somewhere?  And  
> waht
> | version of Matlab are you using?  Can you send the image to me?
> |
> | |  >> [im, map, alpha] = imread('magnolia.png');
> | |  >> whos im map alpha
> | |    Name         Size              Bytes  Class     Attributes
> | |
> | |    alpha        0x0                   0  double
> | |    im         480x640            307200  uint8
> | |    map        250x3                6000  double
>
> OK, I think I see what is happening here.  In both cases, im is the
> same.  It's just that in the first case, you are not capturing the
> colormap.  Still, I does seem odd that when only one output value is
> requested, you are not getting an MxNx3 image, but maybe I just don't
> understand how imread is supposed to work, or how the GraphicsMagick
> image classifications correspond to those used by Matlab.
>
> In any case, I think it would be best to implement the missing parts
> of imread and imwrite in a Matlab-compatible way since I think that is
> what most users will expect.  Likewise for imwrite.  I've done about
> all that I think I can with these functions, and I don't personaly
> need much more funtionality that the current code provides.
>
> jwe


But does the current code---particularly that for imwrite---work?  It  
doesn't on my machine (Mac, with gcc 4.0.1).  If I send imwrite a  
color image stored as uint8, it writes it to a file as uint16.  That is,

octave:45> im = imread("~/images/generic/teddybear.jpg");
octave:46> whos im
Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  =====
        im        576x768x3                1327104  uint8

Total is 1327104 elements using 1327104 bytes

octave:47> imwrite(im, 'tbear.tiff');
octave:48> im2 = imread('tbear.tiff');
octave:49> whos im2
Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  =====
        im2       576x768x3                2654208  uint16

Total is 1327104 elements using 2654208 bytes

It seems that imshow cannot work with the resulting im2 (perhaps it  
is unable to display uint16 images).  If I run the shell command

  $ gm display tbear.tiff

I can only see a black image which, as best as I can tell, is because  
a 16-bit (or 48-bit, since 3 channels) image whose maximum value is  
255 will look entirely black.  I can display the image in Octave if I  
convert it to uint8---i.e.,

   imshow (uint8 (im2))

works fine.

I would like to fix all of this (not ask you to do it), but I do find  
working with GraphicsMagick frustrating.  I'm sure the main issue is  
that I don't know the API well.  But it's also that the obvious  
things don't seem to work---for example, I tried adding im.depth (8)  
at line 479 in __magick_read__.cc, and the result was that it wrote a  
1-bit image; im.depth(9) made it go back to 16-bit---and the sample  
codes are fairly limited in scope.  I've tried contacting the  
developer for more, but he has not responded.

Thomas L. Scofield
--------------------------------------------------------
Associate Professor
Department of Mathematics and Statistics
Calvin College
--------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.cae.wisc.edu/pipermail/octave-maintainers/attachments/20080806/dda3b183/attachment.html