Re: 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

--------------------------------------------------------