|
From: | Thomas L. Scofield |
Subject: | Re: imread (repost) |
Date: | Wed, 6 Aug 2008 12:12:52 -0400 |
On Aug 6, 2008, at 11:55 AM, John W. Eaton 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)) 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 -------------------------------------------------------- |
[Prev in Thread] | Current Thread | [Next in Thread] |