forced palette for RGBA images

Paul Spencer pspencer at DMSOLUTIONS.CA
Wed Dec 12 20:10:22 EST 2007 

Sweet, thanks Thomas.  I had missed the subtlety of rgb vs rgba.

Paul

On 12-Dec-07, at 1:32 PM, thomas bonfort wrote:

> Paul,
>
> short answer:
> it works on rgba images. the gd one does not, as can be seen on the
> last attached link
>
> long answer:
> I think you're confusing the palette method and the quantize method
> (actually the palette method calls gd quantization to if the supplied
> palette contains less than 256 colors). I agree that it should'nt be
> enabled by default for non-rgba images as it is much slower. It does
> produce vastly superior results than  gd if requesting an image with
> very little colors (quantize_colors=64 or less , roughly), as in that
> case the gd algorithm tends to be very buggy (its created palette
> contains nearly only whites).
>
> cheers,
> thomas
>
> On Dec 12, 2007 6:50 PM, Paul Spencer <pspencer at dmsolutions.ca> wrote:
>> Thomas, Assefa,
>>
>> how is this approach different from the quantization that Steve/ 
>> Assefa
>> implemented?
>>
>> I believe we are currently using the gd-based quantization with a
>> limited palette of primary colours that we want to preserve and a
>> number of open colour slots that are filled by gd for covering the
>> antialiasing values, and that it works quite well to reduce image  
>> size
>> to better level without causing horrendous loss of image quality.
>>
>> Does this new algorithm work the same way?  Why would it be used over
>> the gd method?  It seems to be substantially slower than the gd
>> quantization.  One use case for quantization that we have is in
>> generating map tiles for a large, static cache.  This additional
>> overhead would be pretty substantial for this use case.
>>
>> Cheers
>>
>> Paul
>>
>>
>> On 12-Dec-07, at 12:02 PM, Daniel Morissette wrote:
>>
>>> Could we please have a ticket for this referred from the SVN change
>>> comment, summarizing the info from this thread, just so that we have
>>> a place to point users to when they ask about this change in a few
>>> months?
>>>
>>> Personally I'd like to see tickets for anything that's not a trivial
>>> bugfix... but that's just me of course.
>>>
>>> Daniel
>>>
>>>
>>> Steve Lime wrote:
>>>> Thomas, these are great additions. I'm looking forward to using
>>>> them myself as I'm dealing
>>>> with image size issues with AGG/OpenLayers. On your questions, if
>>>> you think it might be disruptive then perhaps users should opt in
>>>> (e.g.
>>>> --enable-experimental-png).
>>>> I'd go ahead and commit. No sense waiting and that gives more folks
>>>> a chance to test.
>>>> Steve
>>>>>>> On 12/12/2007 at 2:46 AM, in message
>>>> <d2b988930712120046n1c0dce28ye568b9c693040f0d at mail.gmail.com>,
>>>> thomas bonfort
>>>> <thomas.bonfort at GMAIL.COM> wrote:
>>>>> A quick update on this.
>>>>> I've now also added quantization for rgba images ( based on the
>>>>> median
>>>>> cut implementation of pngquant / ppmquant:
>>>>> http://www.libpng.org/pub/png/apps/pngquant.html ).
>>>>>
>>>>> examples here (the first two images are actually transparent.  
>>>>> you'd
>>>>> have to open them in an image editor to see that):
>>>>>
>>>>> the full rgba png:
>>>>> http://www.terriscope.fr/ms_tmp/rgba.png : 129k
>>>>>
>>>>> the quantized rgba png (may look funny under oldish MS IEs)
>>>>> http://www.terriscope.fr/ms_tmp/palette.png : 39k
>>>>>
>>>>> the output produced with the current gd quantization
>>>>> http://www.terriscope.fr/ms_tmp/rgbapalettegd.png
>>>>> I'd personally enable the pngquant quantization for rgb images
>>>>> to , as
>>>>> it produces higher quality results, but there's a tradeoff on
>>>>> rendering speed (rough times for quantization only: 1.5 sec for
>>>>> pngquant vs 0.3 sec for gd, on a 2000x2000 image). Or this could  
>>>>> be
>>>>> yet another formatoption selectable option.
>>>>>
>>>>> Dan: all this will be documented. We've talked with Assefa about
>>>>> either writing a complete reference on the different  
>>>>> formatoptions,
>>>>> and/or a howto on reducing image size with agg (palette,
>>>>> quantization,
>>>>> and tradeoffs beween speed/imagesize/flexibility)
>>>>>
>>>>> Now for the questions:
>>>>> * how should I add this? I'd go for a configure option
>>>>> (--disable-experimental-png) with ifdef'd code as I don't know how
>>>>> disruptive this would be on all platforms.
>>>>> * can I add this soon? It's stable on my setup, but there might be
>>>>> issues on other platforms. I'd like to have it tested as much as
>>>>> possible before 5.2
>>>>>
>>>>> cheers,
>>>>> thomas
>>>>>
>>>>> On Dec 7, 2007 10:46 PM, Daniel Morissette
>>>>> <dmorissette at mapgears.com> wrote:
>>>>>> Sounds like a cool feature. We'd need to make sure it is well
>>>>>> documented
>>>>>> and not just hidden in the source. A short RFC or ticket for this
>>>>>> maybe?
>>>>>>
>>>>>> Daniel
>>>>>>
>>>>>>
>>>>>>
>>>>>> thomas bonfort wrote:
>>>>>>> hello list,
>>>>>>>
>>>>>>> I've added the possiblity to force a color palette for RGBA
>>>>>>> images. As
>>>>>>> gd does not support this kind of images, I had to resort to
>>>>>>> directly
>>>>>>> use libpng functions for the actual saving of the file.
>>>>>>>
>>>>>>> The steps needed to actually use this would be:
>>>>>>> - create a 24 bit rgba image representative of a typical image
>>>>>>> that
>>>>>>> would be produced
>>>>>>> - use an external program to create an rgba paletted version of
>>>>>>> the
>>>>>>> image (pngquant, pngnq, photoshop...)
>>>>>>> - extract the palette from the created image and save the values
>>>>>>> in
>>>>>>> the form r,g,b,a in a text file (one per line)
>>>>>>> - use palette_force and palette formatoptions in the
>>>>>>> outputformat block.
>>>>>>>
>>>>>>> This is rather complicated, but usefull on production setups to
>>>>>>> minimize image size when using clients that overlay layers (eg
>>>>>>> openlayers).
>>>>>>>
>>>>>>> There are still a few quirks I'd have to work on before the code
>>>>>>> is
>>>>>>> robust enough for inclusion in the trunk, so I'd like to know if
>>>>>>> this
>>>>>>> is a feature we'd definitely like to have before putting too  
>>>>>>> much
>>>>>>> effort into that.
>>>>>>>
>>>>>>> cheers,
>>>>>>> thomas
>>>>>>
>>>>>> --
>>>>>> Daniel Morissette
>>>>>> http://www.mapgears.com/
>>>
>>>
>>> --
>>> Daniel Morissette
>>> http://www.mapgears.com/
>>
>> +-----------------------------------------------------------------+
>> |Paul Spencer                          pspencer at dmsolutions.ca    |
>> +-----------------------------------------------------------------+
>> |Chief Technology Officer                                         |
>> |DM Solutions Group Inc                http://www.dmsolutions.ca/ |
>> +-----------------------------------------------------------------+
>>

+-----------------------------------------------------------------+
|Paul Spencer                          pspencer at dmsolutions.ca    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+

More information about the mapserver-dev mailing list