Re: Writing a DIB image

On Sat, 27 Aug 2016, Damian Dixon wrote:
>
> The parameter image_info is ignored.
>
> which means that the lines around 1185 are executed instead of obeying what
> is in image_info.
>
>     if (characteristics.monochrome)
>        dib_info.bits_per_pixel=1;
>
> In fact the settings in image_info are not used very much at all in this
> method.
>
> I don't know enough about GraphicsMagik to known if this is expected
> behaviour. However I would expect if I say that the image is not monochrome
> then WriteDIBImage should respect my settings.

The monochrome setting is I think primarily used in the color 
reduction code.

> So is there another way of ensuring that I can write a DIB in the depth
> that I requested?

What is needed is a way to specify the depth.  There is an 
image->depth parameter but it is not used in this case.

If you look at the GraphicsMagick documentation you will find an 
option called '-define' and some format-specific (currently DPX and 
TIFF) defines for setting 'bits-per-sample'.  These exist in order to 
override the built-in useful default behavior.  An example of the 
supportive code can be found around line 4428 in tiff.c.

Most users are happy when their file is smaller but sometimes there is 
a need for specific control of the output.

> Yep I know that DIB's are ancient and a bit naff, but the software I am
> updating is riddled with them... so it has to be one change at a time.

DIB is important since it is part of other file formats.

I would appreciate it if you would open a bug in the SourceForge bug 
tracker with the excellent text that you wrote.

There does not seem to be a way to change the behavior in normal use 
other than modifying the code.

The trick of adding a third color (not black or white) to an existing 
black/white palette before requesting to write the image may solve the 
problem because GetImageCharacteristics() does not scan all the image 
pixels unless image_info->type == OptimizeType.  If the input image is 
PseudoClass then it only inspects the colormap values.  The output 
file would contain the extra palette value but the extra value is not 
likely to be noticed.

Be aware that the Image structure has 'is_monochrome' and 
'is_grayscale' members and these are used to cache if it is already 
known if the image is monochrome or grayscale in order to improve 
performance (it is very expensive to test all the pixels).  If your 
image is the output of a GraphicsMagick image processing operation or 
was just read from a file, then it may be necessary to at least set 
'is_monochrome' to MagickFalse.  Any modification to pixel values 
automatically (in ModifyCache()) sets these two members to 
MagickFalse. The way it works is if an algorithm knows that the output 
must fit a particular classification, it sets these parameters before 
it returns.  Also, an algorithm may remember the existing parameters 
and know that the processing operation does not impact monochrome or 
grayscale so it restores the previously existing values before 
returning.

Bob
-- 
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

------------------------------------------------------------------------------