Re-thinking RFC 6

[Frank Warmerdam]

Attila Csipa wrote:
> On Friday 15 June 2007 17:02, Frank Warmerdam wrote:
>> I do agree with Daniel that single ramps will not ultimately satisfy
>> all requirements.  We could take an approach like RFC 21
> 
> There has been some discussion about this at/around roughly a month ago. I 
> would second Franks suggestion, RFC21 seems a far more natural solution for 
> RFC6/19, too. If anyone is concerned about simplicity, we can have 
> pregenerated curves or a converter which would translate from a perhaps 
> simpler, so in the end
> 
>     MINNUMBER 1
>     MAXNUMBER 10
>     MINVALUE 1000.0
>     MAXVALUE 500000.0
> 
> comes out something like 
> 
>     PROCESSING "LUT=1000:1,500000:10"
> 
> or, for colours
> 
>     PROCESSING_R "LUT=1000:255,500000:255"
>     PROCESSING_G "LUT=1000:0,500000:255"
>     PROCESSING_B "LUT=1000:0,500000:255"
> 
> Still not sure whether colour components should be processed separately, we 
> could theoretically use the second parameter as an encoded RGB(A) value and 
> have a PROCESSINGCOLOUR item, but colour distances become tricky real quick 
> and I would like to keep a format compatible with existing curve editors.

Folks,

I'd stress that RFC 21 only addresses input raster preprocessing.  So
I'm not suggesting that it's implementation superceeds the need for RFC 6.
Just that a vaguely similar approach could be used for irregular colormap
or other mappings.

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