From: phil r. <phi...@ya...> - 2012-08-10 10:04:28
|
Hi all I've come across a "feature" of the cmap1 colourscale that I wanted to check. According to the doumentation for plscmap1l "the hue is interpolated around the front of the colour wheel (red-green-blue-red) unless the rev flag is set to true. I've found however that this isn't always the case and that reversing the order of points on the coord arrays also reverses the direction. For example using HLS I set coord1 to {0,120} and rev to false which gives me a colourscale of red-yellow-green-turquoise-blue. If I then set coord1 to {120,0} I would expect to get a colourscheme from blue-purple-red, but instead I get blue-turquoise-green-yellow-red. I've called it a feature, because I'm not sure if this is a bug in the code or if it is the correct behaviour but the documentation isn't great. Any thoughts? Phil Rosenberg |
From: Andrew R. <and...@us...> - 2012-08-10 14:22:29
|
Hi Phil, I think it's a "feature". It's a question of which of rev and putting coord1 backwards you consider to be reversing the direction around the wheel and which you consider to be flipping the colourscheme. You could argue that it would make more sense to have it the other way round. Either way, I would suggest the best way forward is to ensure that the documentation is clearer and consistent with what is actually done rather than making a backwards incompatible change to code that has been around for a long time. Patches gratefully received! Andrew On Fri, Aug 10, 2012 at 03:04:22AM -0700, phil rosenberg wrote: > Hi all > I've come across a?"feature" of the cmap1 colourscale that?I wanted to check. According to the doumentation for plscmap1l "the hue is interpolated around the front of the colour wheel (red-green-blue-red) unless the rev flag is set to true. > ? > I've found however that this isn't always the case and that reversing the order of points on the coord arrays also reverses the direction. For example using HLS I set coord1 to {0,120} and rev to false which gives me a colourscale of red-yellow-green-turquoise-blue. If I then set coord1 to {120,0} I would expect to get a colourscheme from blue-purple-red, but instead I get blue-turquoise-green-yellow-red. > ? > I've called it a feature, because I'm not sure if this is a bug in the code or if it is the correct behaviour but the documentation isn't great. Any thoughts? > ? > Phil Rosenberg > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Maurice L. <mj...@br...> - 2012-08-12 05:41:31
|
Here is the behavior I see on a plplot build (a bit old but none of this stuff has changed recently AFAIK). BTW H=120 is green, blue is H=240. Cf. http://en.wikipedia.org/wiki/HLS_color_space Using a Hue range of {0,120} gives a Red - Yellow - Green shading. Using a Hue range of {120,0} gives a Green - Yellow - Red shading. Selecting rev=1 causes the interpolation to go around "the back side" of the color wheel, yielding in the latter case Green - Cyan - Blue - Magenta - Red. So from my perspective it's working as expected, aside from the "rev" misnomer ("back" or "wrap" would've been better -- my bad). Maurice On Friday, August 10, 2012 at 03:04:22 (-0700) phil rosenberg writes: > Hi all > I've come across a "feature" of the cmap1 colourscale that I wanted to check. According to the doumentation for plscmap1l "the hue is interpolated around the front of the colour wheel (red-green-blue-red) unless the rev flag is set to true. > > I've found however that this isn't always the case and that reversing the order of points on the coord arrays also reverses the direction. For example using HLS I set coord1 to {0,120} and rev to false which gives me a colourscale of red-yellow-green-turquoise-blue. If I then set coord1 to {120,0} I would expect to get a colourscheme from blue-purple-red, but instead I get blue-turquoise-green-yellow-red. > > I've called it a feature, because I'm not sure if this is a bug in the code or if it is the correct behaviour but the documentation isn't great. Any thoughts? > > Phil Rosenberg------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2012-08-12 15:17:30
|
On 2012-08-12 00:22-0500 Maurice LeBrun wrote: > Here is the behavior I see on a plplot build (a bit old but none of this stuff > has changed recently AFAIK). BTW H=120 is green, blue is H=240. Cf. > http://en.wikipedia.org/wiki/HLS_color_space > > Using a Hue range of {0,120} gives a Red - Yellow - Green shading. > Using a Hue range of {120,0} gives a Green - Yellow - Red shading. > > Selecting rev=1 causes the interpolation to go around "the back side" of the > color wheel, yielding in the latter case Green - Cyan - Blue - Magenta - Red. > > So from my perspective it's working as expected, aside from the "rev" misnomer > ("back" or "wrap" would've been better -- my bad). The name of that argument can be changed without causing an API disruption so if we can come up with a name that is a lot better, I would encourage a patch making the change (and also the associated change to the documentation). But I am not sure "back" or "wrap" are a _lot_ better than "rev". Just to throw another possibility into the pot and get some discussion going about the ideal name, how about "large" or "larger_angle" (for the choice of range corresponding to the larger hue angles). I also thought of cc (for counter-clockwise), but that is a similar misnomer to rev. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Maurice L. <mj...@br...> - 2012-08-12 17:33:00
|
On Sunday, August 12, 2012 at 08:02:20 (-0700) Alan W. Irwin writes: > On 2012-08-12 00:22-0500 Maurice LeBrun wrote: > > > Here is the behavior I see on a plplot build (a bit old but none of this stuff > > has changed recently AFAIK). BTW H=120 is green, blue is H=240. Cf. > > http://en.wikipedia.org/wiki/HLS_color_space > > > > Using a Hue range of {0,120} gives a Red - Yellow - Green shading. > > Using a Hue range of {120,0} gives a Green - Yellow - Red shading. > > > > Selecting rev=1 causes the interpolation to go around "the back side" of the > > color wheel, yielding in the latter case Green - Cyan - Blue - Magenta - Red. > > > > So from my perspective it's working as expected, aside from the "rev" misnomer > > ("back" or "wrap" would've been better -- my bad). > > The name of that argument can be changed without causing an API > disruption so if we can come up with a name that is a lot better, I > would encourage a patch making the change (and also the associated > change to the documentation). > > But I am not sure "back" or "wrap" are a _lot_ better than "rev". Just > to throw another possibility into the pot and get some discussion > going about the ideal name, how about "large" or "larger_angle" (for > the choice of range corresponding to the larger hue angles). I also > thought of cc (for counter-clockwise), but that is a similar misnomer > to rev. "large" & such variants don't work when the hue range exceeds 180, e.g. {0,240}. where the shorter angle is traversed by going around the back side. I agree "back" is poor also since "front" & "back" are arbitrary constructions. The most accurate mathematical description would be something like "path_includes_zero" as the interpolation is defined by going through the H=0=360 (red) point. So maybe that or something similar. Of course, this silliness could've been avoided if I'd merely chosen a default interpolation direction, like counterclockwise, and then used the flag to reverse polarity. That didn't occur to me at the time. The reason for the existing design probably reflects bias due to seeing the HLS wheel displayed in flattened form (red on the left). In that view, a default "front side" interpolation seems more intuitive. But so does driving on the RHS of the road. ;) -- Maurice LeBrun |
From: Alan W. I. <ir...@be...> - 2012-08-12 20:00:02
|
On 2012-08-12 12:32-0500 Maurice LeBrun wrote: > On Sunday, August 12, 2012 at 08:02:20 (-0700) Alan W. Irwin writes: > > The name of that argument can be changed without causing an API > > disruption so if we can come up with a name that is a lot better, I > > would encourage a patch making the change (and also the associated > > change to the documentation). > > > > But I am not sure "back" or "wrap" are a _lot_ better than "rev". Just > > to throw another possibility into the pot and get some discussion > > going about the ideal name, how about "large" or "larger_angle" (for > > the choice of range corresponding to the larger hue angles). I also > > thought of cc (for counter-clockwise), but that is a similar misnomer > > to rev. > > "large" & such variants don't work when the hue range exceeds 180, e.g. > {0,240}. where the shorter angle is traversed by going around the back side. Good point so forget that idea. > > I agree "back" is poor also since "front" & "back" are arbitrary > constructions. The most accurate mathematical description would be something > like "path_includes_zero" as the interpolation is defined by going through the > H=0=360 (red) point. So maybe that or something similar. "path_includes_zero" usually does describe the mathematical meaning, but that term is ambiguous for the special case when the hue range ends with zero or 360 since both path alternatives in that case include zero (or 360). To avoid ambiguity, how about dropping all special meaning from the name and using "alt_hue_path" instead (with appropriate docbook and doxygen documentation of exactly what that means in a mathematical sense)? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Maurice L. <mj...@br...> - 2012-08-12 23:03:49
|
On Sunday, August 12, 2012 at 12:59:53 (-0700) Alan W. Irwin writes: > "path_includes_zero" usually does describe the mathematical meaning, > but that term is ambiguous for the special case when the hue range > ends with zero or 360 since both path alternatives in that case > include zero (or 360). To avoid ambiguity, how about dropping all > special meaning from the name and using "alt_hue_path" instead (with > appropriate docbook and doxygen documentation of exactly what that > means in a mathematical sense)? Sounds good. -- Maurice LeBrun |
From: phil r. <phi...@ya...> - 2012-08-13 09:51:06
|
I've done a couple of other checks over the weekend. It seems to me that ignoring the rev parameter. The colourscale is traversed in the direction of the difference in hue; i.e. if I use 0-240 I get red, yellow, green, turquoise, blue, if I use 240-0 I get blue, turquoise, green, yellow, red. If I do 240-360 I get blue, purple, red. I seem even able to do 240-720 to cycle more than once around the colourwheel. It seems therefore that when specifying colours using the HLS colour model, the rev parameter isn't really needed. Renaming it alt_path and describing what this mean seems sensible. Something like "The hue is interpolated using the degree values provided and values >=360 or <0 can be used to ensure the interpolation travels the correct way around the colour wheel. If alt_hue_path is true then the interpolation goes the opposite way around the colour wheel. Something I hadn't realised until I looked at the code is that if you specify RGB colours, then these are transformed to HLS colours and the interpolation is performed in HSL space. I assume that the HSL colours are always in the 0-359.999 range and hence red will always have a hue of 0. In this case a red-blue or blue-red scale will cross green unless the rev (or alt_hue_path) is used. Overall a description something like the following could replace the two paragraphs immediately preceding Table 19-1: Each control point must specify the position in color map1 as well as three coordinates in HLS or RGB space. The first must correspond to position = 0, and the last to position = 1. If colors are provided in RGB space then these are converted to HLS space for the interpolation with the derived hue always in the range [0,360). When control points are provided in HLS space, values of hue outside the 0-360 degree range can be used to ensure the interpolation travels in the required direction around the color wheel. Also the alt_hue_path can be used to reverse the direction around the color wheel. When control points are provided in RGB space consideration must be given to the hue which will be generated (see plrgbhls) and hence the direction along which the color wheel will be traversed. Again alt_hue_path can be used to reverse the interpolation direction around the color wheel. Also adding an asterisk to the 0-360 range stating: Values outside the 0-360 range may be used to ensure correct interpolation around the color wheel. ________________________________ From: Maurice LeBrun <mj...@br...> To: Alan W. Irwin <ir...@be...> Cc: Maurice LeBrun <mj...@br...>; phil rosenberg <phi...@ya...>; "plp...@li..." <plp...@li...> Sent: Monday, 13 August 2012, 0:03 Subject: Re: [Plplot-devel] cmap1 colourscale direction On Sunday, August 12, 2012 at 12:59:53 (-0700) Alan W. Irwin writes: > "path_includes_zero" usually does describe the mathematical meaning, > but that term is ambiguous for the special case when the hue range > ends with zero or 360 since both path alternatives in that case > include zero (or 360). To avoid ambiguity, how about dropping all > special meaning from the name and using "alt_hue_path" instead (with > appropriate docbook and doxygen documentation of exactly what that > means in a mathematical sense)? Sounds good. -- Maurice LeBrun |
From: Alan W. I. <ir...@be...> - 2012-08-13 17:19:01
|
On 2012-08-12 18:03-0500 Maurice LeBrun wrote: > On Sunday, August 12, 2012 at 12:59:53 (-0700) Alan W. Irwin writes: > > "path_includes_zero" usually does describe the mathematical meaning, > > but that term is ambiguous for the special case when the hue range > > ends with zero or 360 since both path alternatives in that case > > include zero (or 360). To avoid ambiguity, how about dropping all > > special meaning from the name and using "alt_hue_path" instead (with > > appropriate docbook and doxygen documentation of exactly what that > > means in a mathematical sense)? > > Sounds good. Thanks, Maurice. Andrew, if you agree with this idea as well, I would be willing to do the rev ==> alt_hue_path name change wherever plscmap1l, plscmap1la, PLControlPt, or cmap1cp occurs in our code base (i.e, src, bindings, and examples, and also in the doxygen documentation that occurs in the C code). This change, although a bit time consuming, is pretty straightforward, and gives me a chance to contribute something to PLplot again. Note I would leave the corresponding rev ==> alt_hue_path docbook documentation changes to someone else who I assume would also make additional plscmap1l and plscmap1la documentation changes based on what Phil has said and also include the exact mathematical definition of a change in hue. That is currently expressed in C (see src/plctrl.c) as dh = plsc->cmap1cp[n + 1].h - plsc->cmap1cp[n].h; if ( plsc->cmap1cp[n].rev ) dh = ( dh > 0 ) ? dh - 360 : dh + 360; but should be reexpressed more generally in the docbook documentation since not everyone understands C. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2012-08-13 18:45:04
|
On Mon, Aug 13, 2012 at 10:18:52AM -0700, Alan Irwin wrote: > On 2012-08-12 18:03-0500 Maurice LeBrun wrote: > > > On Sunday, August 12, 2012 at 12:59:53 (-0700) Alan W. Irwin writes: > > > "path_includes_zero" usually does describe the mathematical meaning, > > > but that term is ambiguous for the special case when the hue range > > > ends with zero or 360 since both path alternatives in that case > > > include zero (or 360). To avoid ambiguity, how about dropping all > > > special meaning from the name and using "alt_hue_path" instead (with > > > appropriate docbook and doxygen documentation of exactly what that > > > means in a mathematical sense)? > > > > Sounds good. > > Thanks, Maurice. > > Andrew, if you agree with this idea as well, I would be willing to do > the rev ==> alt_hue_path name change wherever plscmap1l, plscmap1la, > PLControlPt, or cmap1cp occurs in our code base (i.e, src, bindings, and > examples, and also in the doxygen documentation that occurs in the C > code). This change, although a bit time consuming, is pretty > straightforward, and gives me a chance to contribute something to > PLplot again. > > Note I would leave the corresponding rev ==> alt_hue_path docbook > documentation changes to someone else who I assume would also make > additional plscmap1l and plscmap1la documentation changes based on > what Phil has said and also include the exact mathematical definition > of a change in hue. That is currently expressed in C (see > src/plctrl.c) as > > dh = plsc->cmap1cp[n + 1].h - plsc->cmap1cp[n].h; > if ( plsc->cmap1cp[n].rev ) > dh = ( dh > 0 ) ? dh - 360 : dh + 360; > > but should be reexpressed more generally in the docbook documentation since > not everyone understands C. I agree that sounds like a much better wording than "rev". If you are happy to make the code changes I'll attempt a more sensible rewording of the docbook documentation. Andrew |
From: Alan W. I. <ir...@be...> - 2012-08-13 21:35:35
|
On 2012-08-13 19:44+0100 Andrew Ross wrote: > I agree that [alt_hue_path] sounds like a much better wording than "rev". If you are > happy to make the code changes I'll attempt a more sensible rewording of > the docbook documentation. Thanks, Andrew, for your willingness to deal with the DocBook documentation side of this. With revision 12207, I have started the code changes by finding all files that mention the PLControlPt struct or its only example, cmap1cp using find -type f |grep -v svn|xargs egrep -l "(PLControlPt|cmap1cp)" and making the appropriate rev ==>alt_hue_path changes to PLControlPt and cmap1cp in all those files. That result has been successfully build tested (which should rule out any inconsistencies in my name changes). So far so good, but there is a lot more rev ==>alt_hue_path source code changes to come since plscmap1l (or cmap1l) is mentioned in quite a large number of different files in src, bindings, and examples. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2012-08-13 23:53:26
|
On 2012-08-13 14:20-0700 Alan W. Irwin wrote: > So far so good, but there is a lot more rev ==>alt_hue_path source > code changes to come since plscmap1l (or cmap1l) is mentioned in quite > a large number of different files in src, bindings, and examples. Revision 12212 finished off this change to our core C library, and the language bindings. These changes only build tested so far. @Jerry: The rev misnomer and bad documentation of that flag had propagated (through no fault of your own) to an extraordinary degree to the Ada bindings. So there were some fairly intrusive changes there. Those, in fact, constituted a minor API change so revision 12212 also includes the necessary changes to examples/ada, and Ada users will also have to make corresponding changes to their source code. But I think addressing this misunderstanding is well worth this minor pain. @Andrew: when you get around to updating the DocBook alt_hue_path documentation, you should look at my updated doxygen documentation in plctrl.c where I made a first attempt at that. Of course, if you can think of better wording, don't hesitate to change the doxygen documentation some more. @Everybody: there will be more to come (probably within a day or so as a break from my other work) with the remaining examples to finish off _all_ the rev ==>alt_hue_path code changes. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2012-08-14 12:33:13
|
On Mon, Aug 13, 2012 at 04:53:18PM -0700, Alan Irwin wrote: > On 2012-08-13 14:20-0700 Alan W. Irwin wrote: > > > So far so good, but there is a lot more rev ==>alt_hue_path source > > code changes to come since plscmap1l (or cmap1l) is mentioned in quite > > a large number of different files in src, bindings, and examples. > > Revision 12212 finished off this change to our core C library, and > the language bindings. These changes only build tested so far. > > @Jerry: The rev misnomer and bad documentation of that flag had > propagated (through no fault of your own) to an extraordinary degree > to the Ada bindings. So there were some fairly intrusive changes > there. Those, in fact, constituted a minor API change so revision 12212 > also includes the necessary changes to examples/ada, and Ada users > will also have to make corresponding changes to their source code. > But I think addressing this misunderstanding is well worth this minor pain. > > @Andrew: when you get around to updating the DocBook alt_hue_path > documentation, you should look at my updated doxygen documentation > in plctrl.c where I made a first attempt at that. Of course, if > you can think of better wording, don't hesitate to change the doxygen > documentation some more. > > @Everybody: there will be more to come (probably within a day or so as > a break from my other work) with the remaining examples to finish off > _all_ the rev ==>alt_hue_path code changes. I've updated the docbook documentation, including a short table of examples to hopefully make it clearer how this all works. Please shout if you think this is still not clear enough. Andrew |
From: Jerry <lan...@qw...> - 2012-08-15 05:20:53
|
On Aug 13, 2012, at 4:53 PM, Alan W. Irwin wrote: > On 2012-08-13 14:20-0700 Alan W. Irwin wrote: > >> So far so good, but there is a lot more rev ==>alt_hue_path source >> code changes to come since plscmap1l (or cmap1l) is mentioned in quite >> a large number of different files in src, bindings, and examples. > > Revision 12212 finished off this change to our core C library, and > the language bindings. These changes only build tested so far. > > @Jerry: The rev misnomer and bad documentation of that flag had > propagated (through no fault of your own) to an extraordinary degree > to the Ada bindings. So there were some fairly intrusive changes > there. Those, in fact, constituted a minor API change so revision 12212 > also includes the necessary changes to examples/ada, and Ada users > will also have to make corresponding changes to their source code. > But I think addressing this misunderstanding is well worth this minor pain. Thanks, Alan. I believe that Ada weirdness was a result of my finding a workaround to the C API calling for a null pointer in some cases. Ada-folk hardly know what a null pointer is. 8^) I'll make a note to make sure this is in the Ada docs. Jerry > > @Andrew: when you get around to updating the DocBook alt_hue_path > documentation, you should look at my updated doxygen documentation > in plctrl.c where I made a first attempt at that. Of course, if > you can think of better wording, don't hesitate to change the doxygen > documentation some more. > > @Everybody: there will be more to come (probably within a day or so as > a break from my other work) with the remaining examples to finish off > _all_ the rev ==>alt_hue_path code changes. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ |