On Wed, Aug 19, 2009 at 4:55 PM, Andrew Ross<andrewr...@users.sourceforge.net> wrote: > 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?
These links may provide a better/more easily viewable example. Here is a similar color bar: http://www.srh.noaa.gov/srh/sod/radar/radinfo/clearair.gif and here is the context, with the color bar and an example plot a little over 3/4 of the way down the page: http://www.srh.noaa.gov/srh/sod/radar/radinfo/radinfo.html >> 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 Yes, that is precisely what I would like to have. > 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. I ran in to this difference when I attempted to blindly implement this locally and got some strange errors due to the implicit double array -> int array :-) The work-around I used is to multiply the 0.0-1.0 R, G and B values by 255 before feeding them to plscmap1a. The 0.0-1.0 scale used in the v2 cmap1 files is probably more future-proof. > 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. I've tried this. In a situation like this I like the appearance of the plscmap1a results more since it gives a distinct break between colors rather than a blurring at color borders. > 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. Sounds good. I will make the change and commit it. Thank you both for the feedback! Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science ------------------------------------------------------------------------------ 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
