From: Alan W. I. <ir...@be...> - 2002-02-04 23:42:54
|
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 images. 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. Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2002-02-05 16:42:49
|
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 index now. Alan 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 > images. > > 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. > > Alan > > email: ir...@be... > phone: 250-727-2902 FAX: 250-721-7715 > snail-mail: > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Maurice L. <mj...@ga...> - 2002-02-06 02:20:31
|
Alan W. Irwin writes: > 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) Already exists -- plscmap1l(). > and to get > them again with provision made for the case where no control points are used > at all to generate cmap1. Yeah there should probably be a corresponding plgcmap1l(), if you want to add it feel free. As for the undefined control points case, that's not something I care to support as I find the control point model to do everything I need. Again, if someone else wants to do any work in this area, that's fine. -- Maurice LeBrun mj...@ga... |
From: Maurice L. <mj...@ga...> - 2002-02-06 02:13:48
|
Alan W. Irwin writes: > 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. They all appear just fine on my display. :) But I have a feeling I'll see what you mean when I try it on my notebook at 800x600 resolution. What resolution are you using? In any case, these kinds of sizing considerations will all be addressed in the revamp of the resources handling that I have brewing. I don't know if it will be coming any time real soon b/c I need to concentrate on other things for the next few weeks, but I'll try to fit it in as best I can. > 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. GUI control of these would be nice but I doubt I'll ever bother because there's a simple alternative method that works just fine -- edit the palette file. I recommend taking a look at each of the *.pal files. In fact, you should load each in and play with them. On x16c, edit the cmap0 palette to see that user settings are taken into account. The cmap0 palette file is of the form: <n> <color1> ... <colorn> where <n> is the number of colors, while cmap1 palettes are of the form: <n> <color1> <pos1> [<reverse>] ... <colorn> <posn> [<reverse>] where <n> is the number of control points. The positions here are given as integers from 0-100.. divide by 100 to get the ordinary position in cmap1 space. > 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 > images. Ugh.. I didn't realize that's what x08c was doing. I don't really like the plscmap1() way of initializing the palette. It was my first implementation and I didn't see the harm in keeping it in for odd situations. Definitely plscmap1l() with a small number of control points is to be preferred. In this case, the explicit initialization using 256 colors can be replaced with a cmap1 initialization that uses only 2 control points, which on my display looks the same. I'll probably go ahead and make the change to x08c to do it this way. > 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. Right, this is a side effect of the brute force initialization of the color map. It will go away after I change x08c to use plscmap1l() instead. > ... > 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. As per the above notes, these are all handled by existing functionality except for sizing concerns, which I'll address over the coming weeks/months. -- Maurice LeBrun mj...@ga... |
From: Alan W. I. <ir...@be...> - 2002-02-06 02:51:00
|
On Tue, 5 Feb 2002, Maurice LeBrun wrote: > Alan W. Irwin writes: > > 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. > > They all appear just fine on my display. :) But I have a feeling I'll see what > you mean when I try it on my notebook at 800x600 resolution. What resolution > are you using? 1024x768. > I don't really like the plscmap1() way of initializing the palette. Understood for ordinary use, but plscmap1() is invaluable for dealing with colour paletted images so this functionality should be retained. However, I agree we shouldn't demo plscmap1() in example 8, and generating gray scale with two control points is a more beneficial example for the newbie user. >> 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. > Right, this is a side effect of the brute force initialization of the color > map. It will go away after I change x08c to use plscmap1l() instead. Good. Thanks also for the additional information you gave re cmap0 and cmap1 palette files. Alan |
From: Maurice L. <mj...@ga...> - 2002-02-06 05:06:39
|
Maurice LeBrun writes: > Alan W. Irwin writes: > > 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. > > Right, this is a side effect of the brute force initialization of the color > map. It will go away after I change x08c to use plscmap1l() instead. I was wrong about this, even with my change the default map is still installed when bringing up the palette tool. I'll look into it.. probably a quick fix. -- Maurice LeBrun mj...@ga... |
From: Maurice L. <mj...@ga...> - 2002-02-06 14:43:31
|
Maurice LeBrun writes: > Maurice LeBrun writes: > > Alan W. Irwin writes: > > > 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. > > > > Right, this is a side effect of the brute force initialization of the color > > map. It will go away after I change x08c to use plscmap1l() instead. > > I was wrong about this, even with my change the default map is still installed > when bringing up the palette tool. I'll look into it.. probably a quick fix. OK, it works now, at least my test using x08c. I did notice that the plframe widget wasn't propagating the 'rev' flag correctly, not used in this test. Will get to that tomorrow. -- Maurice LeBrun mj...@ga... |
From: Maurice L. <mj...@ga...> - 2002-02-06 15:15:21
|
Maurice LeBrun writes: > Maurice LeBrun writes: > > Maurice LeBrun writes: > > > Alan W. Irwin writes: > > > > 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. > > > > > > Right, this is a side effect of the brute force initialization of the color > > > map. It will go away after I change x08c to use plscmap1l() instead. > > > > I was wrong about this, even with my change the default map is still installed > > when bringing up the palette tool. I'll look into it.. probably a quick fix. > > OK, it works now, at least my test using x08c. I did notice that the plframe > widget wasn't propagating the 'rev' flag correctly, not used in this test. > Will get to that tomorrow. Whoops, dunno what I was looking at, now it looks fine. :) So AFAIK am all done on this point for now. -- Maurice LeBrun mj...@ga... |
From: Alan W. I. <ir...@be...> - 2002-02-06 16:14:43
|
> Whoops, dunno what I was looking at, now it looks fine. :) So AFAIK am all > done on this point for now. Thanks very much for these changes. The non-default colour palette works for me as well. However, another problem seems to have been introduced on my system. ./x08c -dev tk *** PLPLOT WARNING *** Driver does not support hardware solid fills, switching to software fill. That software fill is really slow and ugly (;-) compared to the hardware fill we had before. Alan |
From: Maurice L. <mj...@ga...> - 2002-02-06 16:18:00
|
Alan W. Irwin writes: > > Whoops, dunno what I was looking at, now it looks fine. :) So AFAIK am all > > done on this point for now. > > Thanks very much for these changes. The non-default colour palette works > for me as well. > > However, another problem seems to have been introduced on my system. > > ./x08c -dev tk > > *** PLPLOT WARNING *** > Driver does not support hardware solid fills, switching to software fill. > > That software fill is really slow and ugly (;-) compared to the hardware > fill we had before. That's really strange. Could you try a complete rebuild to see if it's a dependency problem? -- Maurice LeBrun mj...@ga... |
From: Alan W. I. <ir...@be...> - 2002-02-07 02:48:13
|
On Wed, 6 Feb 2002, Maurice LeBrun wrote: > Alan W. Irwin writes: > > ./x08c -dev tk > > > > *** PLPLOT WARNING *** > > Driver does not support hardware solid fills, switching to software fill. > > > > That software fill is really slow and ugly (;-) compared to the hardware > > fill we had before. > > That's really strange. Could you try a complete rebuild to see if it's a > dependency problem? Thanks for that suggestion which was bang on. make clean ./configure .... make cd tmp; make x08c fixed the problem. I usually do go through a clean rebuild (sometimes even clean from a cvs checkout), but this one time I didn't do that, it bit me. Live and learn.... BTW, I played with the 2-point palette here, and you get an awesome looking silvery gray colour if you play with the black. I will probably put that in. Your other fix for ./plserver -f tk03 works fine here as well. Time for a new release?....;-) Alan |
From: Geoffrey F. <fu...@ga...> - 2002-02-07 05:51:10
|
Alan W. Irwin writes: > Thanks for that suggestion which was bang on. > > make clean > ./configure .... > make > cd tmp; make x08c > > fixed the problem. I usually do go through a clean rebuild (sometimes even make clean is supposed to be never necessary. Desuckifying the dependencies once and for all, is on the short list. I've been bitten by such things toooooo many times in PLplot. -- Geoffrey Furnish fu...@ga... |