Re: Writing a DIB image

Thanks for the reply.

I have opened a Ticket.

I will try your suggestions latter as I don't want local changes.

For now I have changed the code locally to obey image_info.

I need to be able to save a monochrome DIB with 1bit depth and 8bit depth.

The reason we use 8bit depth for monochrome is that we split the image up
into rectangle blocks for processing in multiple threads. The output block
size may be a lot bigger than the input block size so I can't guarantee
that the sizes align with an 8bit boundary in the output. Basically this is
a GIS raster re-projection from one Map Projection to another Map
Projection.

Once this process is complete we save the mask as 1bit depth.

The code is ancient in computing terms (+20yrs old) and quite obtuse so
modifying the code to use 1bit depth image would be difficult to say the
least.

Thanks
Damian



On 28 August 2016 at 01:32, Bob Friesenhahn <[email protected]>
wrote:

> 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/
>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Graphicsmagick-help mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/graphicsmagick-help
>

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

_______________________________________________
Graphicsmagick-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/graphicsmagick-help