octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: imread (repost)


From: John W. Eaton
Subject: Re: imread (repost)
Date: Wed, 06 Aug 2008 12:35:01 -0400

On  6-Aug-2008, Thomas L. Scofield wrote:

| 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.

My imwrite and __magick_write__ functions were written to show the
sort of structure I thought the code should have, and to provide some 
proof-of-concept code.  As I don't fully understand all the details of
precisely how imwrite is supposed to work (I think there are a lot of
cases to consider) or the GraphicsMagick library API, I didn't expect
that the code would be perfect or even fully functional.

| 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.

I think it would be better to use one of the mailing lists rather than
writing directly to the maintainer.

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]