[Octave-bug-tracker] [bug #41584] .bmp / .png display error for saturated RGB image.

[Dan Sebald]

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/