Fri 08 Dec 2017 05:10:10 AM UTC, comment #11:
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:
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:
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
which will effectively run "gm identify" from within Octave:
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
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:
|