On Fri, Jul 10, 2009 at 12:35:25AM -0700, Alan Irwin wrote: > On 2009-07-09 10:18+0100 Andrew Ross wrote: > > > [...]I suggest we go with floating point in the range 0-1 for the > > pos parameter. For consistency we should also ensure we do the same for the > > r, > > g, b values. While we are on (since this requires a new file format) > > perhaps we > > should also add support for the rev parameter and for HLS as well as RGB > > color > > spaces. I've committed a straw man implementation for comment. This > > supports the > > old format .pal files, but any file which starts with v2 is assumed to be > > in the > > new floating point format. I've also included a sample palette in the data > > directory (cmap1_blue_yellow.pal). This is one I've used in the past for > > various > > plots and I quite like. > > I made some important changes today (up to and including revision 10135). > > * Fixed a bug for the old format where the rgb colours were not properly > normalized (they ranged from 0 to 255 rather than 0. to 1.). This was the > reason the bindings/tk/cmap1*.pal files gave such bad looking results > before. (However, I agree that for the new format, the rgb colours in the > file should be normalized to the range from 0. to 1.) > > * Fixed bug in current directory pldebug information output for > plLibOpenPdfstr. > > * Dropped fopen logic that was screwing up the -cmap0 and -cmap1 options. > (It is possible I am missing something there, but I don't believe there > was any way for the old logic to work properly.)
Thanks - I noticed this wasn't working and I couldn't immediately see why. I'd not looked up a level to spot the fopen calls. Should be superfluous now the file error checking is in place. > * Dealt properly with two (!) old tk formats (one with and one without rev > information). bindings/tk/cmap1*.pal has the oldest format (without rev), > but current output from -dev tk GUI cmap1 palette editor outputs rev > information. My implementation demands the file stick to one or the > other of these old formats if it is not the v2 format. Thanks - I hadn't spotted this. > * Implemented range checking for most of the plspal0 and plspal1 values that > are set. Most of this range checking is routine, but now demand at least > 16 colours when setting cmap0. I have done this because I now call > plscmap0n from within plspal0. > > * Added cmap0_black_on_white.pal (black lines on white background) and > cmap1_gray.pal (gray scale). > > cmap0_black_on_white.pal works well (at least to my eyes) with > cmap1_blue_yellow.pal for the standard examples. (It is obviously a > matter of personal taste, but I find the default cmap0 colours or the > cmap0 colours in cmap0_white_bg.pal clash a bit with > cmap1_blue_yellow.pal. Furthermore, for light backgrounds I far prefer > the visibility of black lines to the coloured lines you get for the > standard examples with the default cmap0 colours or the cmap0 colours in > cmap0_white_bg.pal.) > > cmap1_gray.pal gives reasonable looking gray scale results for example 16, > and should be useful (along with cmap0_black_on_white.pal) for those > scientific journals who are still reluctant to publish colour figures. > > After these changes I am satisfied with the current status of our C library > palette support, and the v2 format for cmap1 files seems fine to me. Excellent. > I believe the next step is to change the -dev tk colour palette > editing GUI so the transparency can be edited, displayed and output for both > pal0 and pal1 (with the latter in v2 format). > > After a week or so delay to make sure we have finalized the API, we should > also propagate plspal0 and plspal1 to all the other languages One further addition would be to explicitly set a palette using these commands in one of the examples. I don't have a strong preference which. Perhaps example 16? One further point - if the user explicitly adds -cmap[0]1 to the command line should this override any explicit calls to plspal[01]? Andrew ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
