Re-thinking RFC 6

[Frank Warmerdam]

Daniel Morissette wrote:
> Jan Hartmann wrote:
>> Perhaps converting the start and end color to HSV (Hue, Saturation,
>> Value) would give values that could be interpolated in a meaningful way.
>> For display, the interpolated colors could be converted back to RGB. The
>> algorithm is elementary, i believe.
>>
> 
> I don't know if interpolating on HSV is enough. Doing a quick Google 
> search turned up this page:
> 
> http://ozviz.wasp.uwa.edu.au/~pbourke/texture_colour/colourramp/

Folks,

I do agree with Daniel that single ramps will not ultimately satisfy
all requirements.  We could take an approach like RFC 21

   http://mapserver.gis.umn.edu/development/rfc/ms-rfc-21/

RFC 21 specifies a list of input and output values which are interpolated
to define a curve.

<lut_specification>=<in_value>:<out_value>,<in_value>:<out_value>[,<in_value>:<out_value>]*

resulting in stuff like:

   PROCESSING "LUT=0:0,128:150,255:255"

Or we could just declare that for now linear ranges are a big step forward,
and address non-linear ranges later.

Steve Lime wrote:
 > I agree on the naming. Will have to ponder that. I'd like an syntax that 
would accommodate colors and numbers in the same way:
 >
 >   PARAMETERLIMITS #FFFFFF #FF0000 or PARAMETERRANGE 1 10
 >
 > (we can handle that in mapfile.c) and then
 >
 >   ITEMLIMITS 1000.0 50000.0

This sounds pretty good to me.  Do we use the #FF0000 syntax for
colors anywhere else?

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