24 bit to 8 bit gd conversion

[assefa]

e-mail conversation on the dev list

Assefa : 

We were doing few tests last week on the possiblity to do 24 bit 
rendering using png24 and convert the output to 8 bit at the end. The 
main reason being that we had issues with the color limitation on some 
of the maps we were using. And also the fact that antialising was only 
available in 24bits.
  We were experimenting with the gd function 
gdImageCreatePaletteFromTrueColor(img, 0, 256);  to achieve that, 
calling the fucntion just before the save.
  It seems to give decent results, although I think we need to do more 
tests and there seems to be an issue with transparencies.
  The idea was that if It was a good enough, It could make it into 
something like an outputformat option.

 Steve Lime :

 So you're basically talking about a 24-bit GIF or PNG outformat block correct?
Seems like a reasonable idea to me. 

As an aside I also wish we could do auto quantization with a format like PNG 
that 
supports both 8 and 24-bit pixels. For example, many applications allow you to
set background imagery and in that case you need true color output. However,
you typically need to use the 24-bit format when that imagery is off as well 
resulting
in uncessarily large files.

Perhaps we might consider a parameter like:

  QUANTITIZE TRUE|FALSE|AUTO

[assefa]

Adding myself in cc.

[assefa]

Please review Bug 1701 (commen 2 though 7 refer to this bug).

[fwarmerdam]

I have implemented this for only the GD/PNG driver for now. 

An example output format declaration setup for this looks like:

OUTPUTFORMAT
  NAME png8_t
  DRIVER "GD/PNG"
  EXTENSION "png"
  MIMETYPE "image/png"
  IMAGEMODE RGBA
  TRANSPARENT OFF
  FORMATOPTION "QUANTIZE_FORCE=ON"
  FORMATOPTION "QUANTIZE_DITHER=OFF"
  FORMATOPTION "QUANTIZE_COLORS=10"
END

By default QUANTIZE_FORCE is OFF and the other options are ignored.
If it is ON then the QUANTIZE_DITHER defaults to ON, and QUANTIZE_COLORS
defaults to 256. 

The GD/PNG IMAGEMODE must be RGB or RGBA so that the rendering all takes
place in 24bit or 32bit mode.  Quantization is done at the very last
second in msImageSaveGD() (mapgd.c).  

This was only implemented for the PNG driver because it is the only GD
driver that supports RGB/RGBA and PC256 modes.  For other GD drivers
we would need to revisit other assumptions.  

I would add that the true color to palette code had a bug with the colors
being left open (unallocated) and I had to work around this with a loop
to set all the color table entries in the gdImg to open[] = 0.   I have
filed a bug report with Boutell.com on this topic though we don't need the
fix. 

I have added one simple test of the functionality in the msautotest
suite (msautotest/gdal/force_pc256.map). 

I am leaving this open for the time being till we decide how to document
the change. 

[assefa]

I have tested this locally and works as adverized.

Frank, you mention ".. until we decide how to document ...". I think what you 
wrote in the comment #3 could be the main part of the documentation.  You 
expressed concern about confusion between this and the raster 24-8 dithering, 
should that be added to the documentation ? Are there any other issues ?
 I would also add that mentionning the lowlevel gd function used would be a 
good addition in the doc.

 In any case, I will assign this to Jeff he would update mapserver docs at one 
point.  
 Thanks for adding this.

[tbonfort]

this is implemented and documented now.