I woke up this morning realizing my message below had blurred some important
distinctions between the control point method of setting the cmap1 palette
and the direct method of doing the same thing. So here are some clarifying
points and additional wish list items.
Our current API does not save anything to do with control points. Instead,
it just uses them without storing them to create the cmap1 palette. So add
to my wish list some core API to set the control points (consisting of
number of control points, and the i, h, l, s, and rev arrays) and to get
them again with provision made for the case where no control points are used
at all to generate cmap1.
As an example of that latter case, the gray scale cmap1 palette in example 8
is currently established without recourse to control points. Of course, this
is a bit of a bad example because gray scale is so easy to represent with
control points. But we do need direct access (i.e., access by integer index
without the use of control points) to deal with, for example, the colour
palette of colour images. So also add to my wishlist a core routine to get
cmap1 palette values by *integer* index much like we can set them by integer
On Mon, 4 Feb 2002, Alan W. Irwin wrote:
> Maurice, could you please find a way to display the entire cmap0 colour
> palette GUI? Right now, the 16 default colour buttons overlap at the end,
> and I believe one of them is entirely covered up. Also, sure as anything
> you will have some user wanting to use more or less than 16 cmap0 colours so
> would you be willing to put in a user-selectable number of colours? Perhaps
> the solution is a slider which lets you look at various parts of cmap0 if
> there are more than say 12 colours.
> Similarly, I think the number of cmap1 control points should be user
> selectable with a slider for display so the number of control points could
> be much greater than 16 if the user desired. For example, the gray scale in
> example 8 is done with 256 cmap1 control points. It would be nice to be
> able to display and manipulate that palette or any colour image palette
> (with typically 256 colours) that you might run into when working with
> Finally, I noticed when checking example 8 that no attempt (as far as I
> could tell) was made to display the working palette. Instead when the cmap1
> palette was pressed, immediately the gray scale was turned into the default
> colour scheme.
> For now, even if your GUI won't support anything other than cmap1's with 6
> control points, it would still be worthwhile to be able to display and edit
> the current working palette (assuming it has the same number of control
> points as your default one). I could use that capability immediately to
> diagnose troubles with 6-control point palettes that are set up under
> programme control like restore_cmap1 in x08.tcl. In that case, my eyes tell
> me it is not quite restoring the default colours (I am trying to match your
> 6 points with my local copy of x08.tcl before I check in the results). It
> would be great to actually see the cmap1 numbers produced by restore_cmap1
> using your palette GUI, but right now it always just gives me the default
> regardless of what I do under programme control.
> So here is the wishlist summary:
> (1) User selectable number of colours for cmap0
> (2) User selectable number of control points for cmap1
> (3) If GUI would be too large use a slider to display parts of it
> (4) cmap1 colour palette displays the actual colour map when it starts
> and not the default colour map.
> (5) Make sure actual colour map is also used for cmap0 palette when it starts
> (I haven't played with it so I don't know the score there.)
> I will settle for (4) with number of control points fixed at 6, but I
> hope you do the rest as well.
> email: irwin@...
> phone: 250-727-2902 FAX: 250-721-7715
> Dr. Alan W. Irwin
> Department of Physics and Astronomy,
> University of Victoria, P.O. Box 3055,
> Victoria, British Columbia, Canada, V8W 3P6
> Linux-powered astrophysics
> Plplot-devel mailing list