MS RFC 21: MapServer Raster Color Correction

Steve Lime Steve.Lime at DNR.STATE.MN.US
Tue Oct 17 17:44:38 EDT 2006


You are right of course. I'm +1 on the RFC as written. I really don't
have a problem
with the processing block. It's in wide-spread use now and unless the
block were
removed in it's entirety then having this one option outside of it would
be confusing.
Plus, we know there will be more processing extensions (perhaps some
vector, such
as buffer) to come in the future. There are enough reserved words as it
is.

Regarding PALETTE, I'll work up another RFC (although it may not be big
enough to
warrant one) for that. I'd lean to setting it as a format option as
opposed to a
stand-alone keyword.

Steve

>>> Frank Warmerdam <warmerdam at pobox.com> 10/16/06 11:09 PM >>>
Steve Lime wrote:
> I like the idea. 
> 
> One comment I have is related to an idea that has been floating around
> for overall map output, especially with tiled output. When Assefa and
> Paul where playing around with 24-bit to 8-bit quantitization (sp?)
they
> found that the GD functionality was not consistent- a big problem
> between tiles for something like ka-map. An idea was to allow the
> definition of a pallete that could easily be pre-computed with a tool
> like ImageMagick. You'd render a representative image (big enough to
> capture occurances of all features) in a 24-bit image and reduce to
> 8-bit and save the palette. The palette would be read as the output
> image is created. In the 8-bit context (e.g. 8-bit image in memory)
the
> palette would simply serve as a lookup table, in the 24-bit context
you
> would pre-load the output image (8-bit) with the palette and us
> gdImageColorClosest to convert individual pixels.
> 
> I was thinking of a MAP level parameter called PALETTE that would take
a
> filename. Could the same parameter be used at the LAYER level with
> handling as Frank describes?
> 
> My thought was not to allow definition within the mapfile, rather as
an
> external file with just a straight list of RGB values in the output
> file:
> 
> 0,0,0
> 255,0,0
> ...
> 
> So 0 would map to 0,0,0 and so on. The support at the MAP level could
be
> just a naive implementation 

Steve,

I think a PALETTE keyword that works as you suggest would be a good idea
for the map object.  In fact, it might also be nice to be able to apply
it to a raster layer as a short cut rather than creating many classes
for
some raster images.

However, such an activity is essentially orthagonal to the color
correction
proposal which applies individual 8bit lookup tables to each band prior
to
other processing.

PS. The proposed map level palette would fix the ka-map tile variation
problem.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo,
http://osgeo.org



More information about the mapserver-dev mailing list