On Wed, Aug 19, 2009 at 01:54:32PM -0700, Alan Irwin wrote:
> On 2009-08-19 15:11-0500 Hezekiah M. Carty wrote:
> 
> > I would like to add support for loading segmented colors scales with
> > plspal1, using plscmap1a rather than plscmap1la.  This way, the colors
> > would be separated by distinct cut-offs rather than continuous
> > transitions.  See the color bar used by the US National Weather
> > Service radar images as an example:
> >
> > http://radar.weather.gov/ridge/radar.php?rid=lsx&product=N0R&overlay=11101111&loop=no
> >
> > This is a fairly straightforward change, and I have prepared it
> > locally.  However, two approaches seem reasonable to me and I would
> > like to as for others' opinions before settling on one.
> >
> > The first, and the one I have implemented, is a new file format.
> > Rather than a "v2" header, this one has a "v2s" header (s =
> > segmented).  No reverse field is needed, as it is not applicable here.
> > This format is otherwise the same as the existing v2 format.
> >
> > The second option I thought of after implementing the v2s file format
> > code is to change the plspal1 API to take a second argument to
> > determine if the file should be interpreted as discrete values or
> > interpolation points.  Something similar to "plspal1(filename, true)"
> > for an interpolated color map and "plspal1(filename, false)" for a
> > segmented color map.
> >
> > I like the second option more because the same color palette files can
> > potentially be used for multiple purposes.  It does, however, require
> > a small API change to plspal1 (adding a PLBOOL parameter) which would
> > then have to be propagated to all the language bindings.
> >
> > Any thoughts?  I understand that this is rather poor timing, given the
> > number of "added plspaln to language X bindings" Subversion commits
> > there have been recently.  This has unfortunately been my first chance
> > to dig in to this section of code and see how it works.
> 
> I couldn't get the above link to work for me so I am having some trouble
> envisaging what you want to do.  Just to confirm I understand what you are
> proposing, will you be calling plscmap1a as an alternative to plscmap1la
> within plspal1 for the discrete case?
> 
> Assuming we all agree this is a worthwhile thing to do, now (i.e., before
> our first official release with plspal1) is the time to be changing the API
> rather than after the release.  I would be willing to help you with
> the propagation work so let's not be concerned about that prospect, and
> instead make sure we have the API we want.

I think the idea is to have a single colour representing a range of values 
rather
than having a continuously varying colour map. I can see the practical use for
this. Some comments

1) The current plscmap1 / plscmap1l difference is a rather ugly kludge in my 
   opinion - no doubt for historic reasons. They use two different methods 
   (PLINT 0-255 and PLFLT 0.0-1.0) for specifying RGB values. This makes it
   slightly more complicated than just calling plscmap1 rather than plscmap1l.

2) You can fudge what you want by using a suitable palette with 2 control points
   close together spanning the colour boundaries to allow a rapid change in 
colour
   and two identical colour points to span the range, e.g. 

   pos = [0.0, 0.4999, 0.5001, 1.0]
   {red, green, blue} = [0.0, 0.0, 1.0, 1.0]

   would give 2 bands with black / white colours. I realise this is not perfect.

Having said both of these, I can see the use of something like this and as Alan 
said
now is the time to decide before we release with the new plscmap1 API. 
Propagating
changes is not a big problem since this is a relatively straightfoward function 
and
only a simple modification to the API.

Andrew

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to