imread (repost)
John W. Eaton
jwe at bevo.che.wisc.edu
Wed Aug 6 11:35:01 CDT 2008
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
More information about the Octave-maintainers
mailing list