[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #37689] imread strange result
From: |
Rik |
Subject: |
[Octave-bug-tracker] [bug #37689] imread strange result |
Date: |
Mon, 25 Feb 2013 23:31:48 +0000 |
User-agent: |
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 |
Update of bug #37689 (project octave):
Status: Need Info => Confirmed
_______________________________________________________
Follow-up Comment #5:
Thanks for the example. I can verify what Octave is doing.
Quoting from the documentation for imread
-- Function File: [IMG, MAP, ALPHA] = imread (FILENAME)
Read images from various file formats.
The size and numeric class of the output depends on the format of
the image. A color image is returned as an MxNx3 matrix.
Gray-level and black-and-white images are of size MxN. The color
depth of the image determines the numeric class of the output:
"uint8" or "uint16" for gray and color, and "logical" for black
and white.
Octave notices that all zeros (black) or max intensity (255) can be
represented with just a boolean matrix. If you change the parameters of the
image away from this in any way then it will return a uint8 matrix. For
example, I made a completely white image (all 255) with a single pixel of
value (1) in the GIMP and this is read in as MxNx3 of uint8.
I suppose this is still a problem when you next want to do something with the
MxNx3 image because now you can't set the intensity to anything besides 0 or 1
without first calling
img = uint8 (img) * 255;
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?37689>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/