[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #41584] .bmp / .png display error for saturate
From: |
Dan Sebald |
Subject: |
[Octave-bug-tracker] [bug #41584] .bmp / .png display error for saturated RGB image. |
Date: |
Fri, 8 Dec 2017 00:10:11 -0500 (EST) |
User-agent: |
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0 |
Follow-up Comment #11, bug #41584 (project octave):
I've looked at this one a bit, experimenting with various parts of the
GraphicsMagick library. As Carnë postulated, there may be a bug in the
GraphicsMagick or underlying library code. I'm leaning that way, and I will
explain why a bit later.
However, the main issue is whether this approach should be used:
octave_idx_type depth = img.depth ();
std::cerr << "DEPTH=" << img.depth() << "\n";
if (depth == 8
&& img.channelDepth (Magick::RedChannel) == 1
&& img.channelDepth (Magick::GreenChannel) == 1
&& img.channelDepth (Magick::BlueChannel) == 1
&& img.channelDepth (Magick::CyanChannel) == 1
&& img.channelDepth (Magick::MagentaChannel) == 1
&& img.channelDepth (Magick::YellowChannel) == 1
&& img.channelDepth (Magick::BlackChannel) == 1
&& img.channelDepth (Magick::OpacityChannel) == 1
&& img.channelDepth (Magick::GrayChannel) == 1)
depth = 1;
My thought is to not do this because the ramification is something like
described in bug report https://savannah.gnu.org/bugs/?49140 . As described
in earlier posts, GraphicsMagick can compress it's internal representation if
the extremes are 0.0 and 1.0, e.g., 0x00 and 0xFF in 8-bit land thus
suggesting the channel depth is 1-bit when the original file was not 1-bit per
channel.
It's one of two bad-outcomes, but I lean toward treating 8-bit data as 1-bit
(the above code) is a worse outcome than treating 1-bit data as 8-bit--unless
there is some bad scaling effect I'm unaware of such that 0.0 and 1.0 aren't
mapped to 0 and 255. The thing is, it's really easy to convert from (0,255)
back to (0,1) after the fact with logical(img) at Octave's command line--not
as easy to go the other direction. Furthermore, if down the line there are
bug fixes in the GM Magick++ library, the issue will disappear on its own.
It could be a bug in the way Octave is accessing the Magick++ library (e.g.,
overlooked initialization, incomplete processing), but I've tried enough
things to start thinking it isn't Octave's problem.
Let's get some footing by observing Octave/Magick++ (with GraphicsMagick as
the library code) is /writing/ an image in 1-bit channel depth:
octave:1> img(:,:,1) = logical(ones (128));
octave:2> img(:,:,2) = zeros (128, "logical");
octave:3> img(:,:,3) = zeros (128, "logical");
octave:4> imwrite (img, "testbinary.bmp");
octave:5> exit
sebald@ ~/octave/bug_41584 $ gm identify testbinary.bmptestbinary.bmp BMP
128x128+0+0 PseudoClass 2c 8-bit 2.1Ki 0.000u 0:01
sebald@ ~/octave/bug_41584 $ identify testbinary.bmp
testbinary.bmp BMP3 128x128 128x128+0+0 1-bit sRGB 2c 2.11KB 0.000u 0:00.000
Notice in the above that I've used two different utilities to "identify" the
image that was created. The first "gm identify" is the *GraphicsMagick*
utility. The second "identify" is the *ImageMagick* utility. Right away we
see that GraphicsMagick can't properly identify a 1-bit image file (although
it can create one) while ImageMagick can.
I've experimented with a few code variations, most similar to the
"readImages()" of the STL.h Magick++ interface. Yet, I just get a depth of 8,
rather than 1, when reading testbinary.bmp. I even made use of the function
IdentifyImageCommand(image_info, 2, fnarg, &metadata, &exception_info);
which will effectively run "gm identify" from within Octave:
octave:1> img = imread ("testbinary.bmp");
/home/sebald/matlab/bug_41584/testbinary.bmp BMP 128x128+0+0 PseudoClass 2c
8-bit 2.1Ki 0.000u 0:01
which is the same result as gotten from the command line above.
The list of GM bug fixes appears to be here:
http://www.graphicsmagick.org/NEWS.html
I don't see much mention of 1-bit depth fixes. I have version
GraphicsMagick 1.3.23 2015-11-07 Q16 http://www.GraphicsMagick.org/
I suppose someone should get the latest version of GM and compile it. Then
test if the testbinary.bmp file is identified as 1-bit. If not, then file a
bug report at the GM SourceForge development site. Maybe it wouldn't be that
difficult to fix either...could be that no one ever noticed because 1-bit
images aren't used too much.
FWIW, my version of ImageMagick utilities is:
Version: ImageMagick 6.8.9-9 Q16 x86_64 2017-07-31 http://www.imagemagick.org
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?41584>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [Octave-bug-tracker] [bug #41584] .bmp / .png display error for saturated RGB image.,
Dan Sebald <=