#486 Allow variable color for more styles

open
nobody
None
5
2013-02-10
2010-06-24
No

Several plot styles allow specifying variable color via an additional datafile column, however, many of them don't.
This ticket intends to be a place to collect patches that add this capability to styles that don't have it yet.

(Newsgroup thread: http://groups.google.com/group/comp.graphics.apps.gnuplot/browse_thread/thread/927acc198f6c3180# )

Discussion

1 2 > >> (Page 1 of 2)
  • Péter Juhász

    Péter Juhász - 2010-06-24

    The first patch fixes jut the boxxyerrobars style.

     
  • Péter Juhász

    Péter Juhász - 2010-06-26

    Further cleanup of old code for the new variable color mechanism

     
  • Péter Juhász

    Péter Juhász - 2010-06-26

    The second path is a continuation of #3021791.

     
  • Péter Juhász

    Péter Juhász - 2010-06-27

    varcolor_6_27jun10_jp.patch also belongs to #3021791, continuing the work to fully implement variable color for most styles.

     
  • Péter Juhász

    Péter Juhász - 2010-06-27

    Updated varcolor_6_27jun10_jp.patch

     
  • Péter Juhász

    Péter Juhász - 2010-06-27

    Extended demo to test new variable color features

     
  • Ethan Merritt

    Ethan Merritt - 2010-06-28

    I've commited almost all of this series to CVS. The demo reveals there are still some problems to be worked out with CANDLESTICKS (try "set style fill solid border -1" before running the demo). Also I'd like to see the bars drawn in the border color for all styles with filled boxes. Why don't you have a look at fixing that while I have a go at "tc variable".

     
  • Péter Juhász

    Péter Juhász - 2010-06-28

    Bugfixes for the new variable color mechanism, modified demo

     
  • Péter Juhász

    Péter Juhász - 2010-06-28

    Patch 7, uploaded just now, contains a fix for the CANDLESTICKS style, and changes the color of the error bar to that of the border in case of the BOXERROR style. Is there any other style where this would be relevant?

    The patch also contains an updated varcolor.dem, which should now test for more combinations of borders and fills.
    A nontrivial modification is that I changed the color column from 0 to 1 everywhere. This is because of the lc palette z section: with column 0 as color, auto-scaling on the color axis went from 0 to 9, while the data were displayed at 1 to 10, and I spent a considerable amount of time scratching my head wondering why this could be.

    Coming up: I was overly pessimistic about the LABELPOINTS style. What actually happens is that the new variable color mechanism is never activated in case of this style as of now. That would happen at the beginning of get_data(), if one of the conditions about the line properties were true, but none of them are true, because during earlier processing of the plot command not the line properties, but the text label properties are changed according to the variable color mode.
    This can be fixed, and fixing this would also fix the incorrectly auto-scaling color axis in case of this style (which also doesn't work as of now).

    Also now, that variable color is the norm rather than an exception, I think there should be a general article about it in the help system. I plan to write that too.

     
  • Péter Juhász

    Péter Juhász - 2010-06-28

    Bring the LABELPOINTS style in sync with the new variable color mechanism

     
  • Péter Juhász

    Péter Juhász - 2010-06-28

    Patch 8 contains the changes to make LABELPOINTS work with the new system. The "tc variable" colorspec option is now recognized. I'm not sure that the required change in parse_colorspec() doesn't break something somewhere else.
    Auto-scaling for 'tc palette z' also works.

    One case not covered is 'with labels tc {var | rgb var | pal z} point'. In that case the points are drawn in the default color. It is possible to give them a different (static) color, but as of now they don't respect the variable color specification.
    Should they have the same color as their corresponding labels? It would be kind of neat if it were possible to give a variable color to them separately from the labels, e.g. 'plot "data" u 1:2:3:4:5 with labels tc var point lc var' - or is this asking for too much?

     
  • Ethan Merritt

    Ethan Merritt - 2010-06-28

    Patch 7:
    Looks good. I have one question/quibble. At graphics.c line 3336 after patching we now have
    if (!need_fill_border(&plot->fill_properties))
    break;
    I don't think this can ever trigger, but if it does trigger then I think the action is wrong. "break" will cause it to skip all the remaining data points. Am I missing something?

    Patch 8:
    I think this should be done a little differently. The line properties, including variable color if specified via "lc variable", should pertain to the point symbol rather than to the text. In other words, it should be possible to control the color of the point independent of the color of the text; one, both, or neither might be variable.

    I've just introduced a separate colorspec flag TC_VARIABLE for a slightly different purpose. Let's see if we can use it for this also.

     
  • Péter Juhász

    Péter Juhász - 2010-06-28

    Update the documentation to mention variable color for the relevant styles

     
  • Péter Juhász

    Péter Juhász - 2010-06-28

    I uploaded a patch #9 which is just a few additions to the documentation.

    You're right about patch 7, I guess. That break may be replaced with a no-op.

    Patch 8: with this patch applied, "tc variable" et al. do what they should to the label colors. "lc variable" and friends don't do anything at the moment. The points, if switched on, are black by default. It would be good if "lc var" would work, probably separately from "tc var". However, this would necessitate two additional columns, doesn't it? I don't readily see how the present mechanism, which looks at exactly one column (the last one) could be extended to accommodate this.
    I think that if there is only one additional column, but two variable specifications ('tc var point lc var'), the point colors should get the same colors as the labels.

    If, however, a clean and generic method were found for the handlng of more than one optional columns, then the variable point sizes capability could be assimilated into it (and extended to cover all styles that have points).
    More than one arrays like the current varcolor one would have to be allocated for this (to begin with).

    Anyway, feel free to improve my patches.

     
  • Nobody/Anonymous

    Two observations (sadly, not patches, I didn't have time to work on this today):

    If one uses variable color with 3D plots, the key sample shows that in a very intuitive way. I think this ought to be back-ported to 2D styles, too.

    The LINESPOINTS style works imperfectly with splots in this regard: the points are colored properly with "lc var", but the line segments aren't.

    (I see that the other (two) tickets are closed now - excellent, thanks. This one should be kept open for future patches, though)

     
  • Ethan Merritt

    Ethan Merritt - 2010-06-29

    2D key samples
    ----------------
    not sure I understand what you have in mind. What specific types of plots?

    3D plots
    --------
    - yeah, we should make sure nothing broke inadvertently.
    - It would be possible to change variable color handling in 3D plots also, but I put a lower priority on it since that will not by itself save any space in the stored data.

    Other issues
    -------------
    Why does the second plot of varcolor.dem cause a colorbar to be drawn at the right side of the output?
    The keyword "lc" is now problematic in parsing the options to "plot ... with labels". On the other hand, even when it is parsed correctly it has no effect separate from "tc", so the fix is not trivial.

     
  • Péter Juhász

    Péter Juhász - 2010-06-29

    Key samples:

    Please look at 'splot '+' u 1:1:1:1 w points lc pal'. Instead of one point, there are now three differently colored points at the key sample, showing nicely that per-datapoint coloring is used for that data-source. Compare with 'plot '+' u 1:1:1 w p lc pal': one point, which is colored - misleadingly - as the last point plotted.
    Change 'points' to linespoints: now you get three colored points and a mulit-colored line segments for 'splot', but one point and one line segment - differently colored to boot - for 'plot'.

    As far as I can tell, this fancy key sample coloring works for all 'splot' styles except impulses. To make 2D key samples do the same trick: that was my proposal.

    3D plots:

    As far as I could tell from a very cursory glance at the code, variable color for 3D works rather differently from 2D. I suggest we leave it alone for the time being. Reasons:
    - don't fix what ain't broken (but fix what *is* broken, like linespoints)
    - it already works for all relevant splot styles.

    Color bar:
    Maybe because TC_Z turns on auto-scaling on the color axis?
    But it is a Good Thing that it appears! If we use color axis to map a continuously varying quantity to encode additional information on the plot, it is good practice to provide an explanation for that color mapping. One could say that the plot would be incomplete without it.

     
  • Péter Juhász

    Péter Juhász - 2010-06-29

    Addendum:

    The fancy key coloring for splots works for 'lc var' and 'lc pal z', but it doesn't for 'lc rgb var'.

     
  • Ethan Merritt

    Ethan Merritt - 2010-06-29

    > The fancy key coloring for splots works for 'lc var' and 'lc pal z', but it doesn't for 'lc rgb var'.

    Well yeah. For palette-based coloring it is reasonable to show the range of colors in the palette (although that doesn't necessarily work for custom palettes). But for "lc var" and even more for "lc rgb var", what colors would one show in the key? There is no obvious range of colors that would allow you distinguish one plot on the graph from another.

     
  • Péter Juhász

    Péter Juhász - 2010-06-29

    After some superficial testing: key coloring for 'splot ... lc pal' works with custom palettes!
    But it displays the same palette (the currently active one) for 'lc var' too - I agree that doesn't make sense.

    What would make a little more sense is displaying point - or line - samples in the colors available on the current terminal.
    Perhaps just three, with color 1, 2 and 3.
    In the case of 'lc var', color doesn't distinguish two plots on a graph (color is used for other information, that's the point), but the point style still does, and that is also shown in the key. So I wouldn't worry about this too much.

    For 'rgb var': perhaps a mini rgb color wheel, or just three points (if applicable), red, green and blue?

     
  • Péter Juhász

    Péter Juhász - 2010-06-29

    This latest patch (fix lc var for splot lines) is a not very graceful bugfix that corrects lines' coloring when 'lc variable' is used with 3D plots. By not very graceful I mean that it does its job, but further attention is needed to understand why it was broken in the first place. Why isn't check_for_variable_color used for lines, when it is used for points, vectors and impulses?

    This problem is - was - unrelated to the weekend's changes.

    Unrelated remark: I think lines 883-891 in plot2d.c are unnecessary now that LABELPOINTS works like the rest of the styles.

     
  • Ethan Merritt

    Ethan Merritt - 2010-06-29

    > Unrelated remark: I think lines 883-891 in plot2d.c are unnecessary now
    > that LABELPOINTS works like the rest of the styles.

    Heh. I was just looking at that. It _should_ be unnecessary, but in fact the code is still falling through to it for some reason. The problem seems to be that in the case of "with labels {lc|tc} variable" the code at line 330 is never triggering to reserve the space for the varcolor[] array. Then later on the presence of variable color isn't recognized and the index j is not decremented from 4 to 3. So in fact the labels code is still using the old mechanism, not the new one!

     
  • Péter Juhász

    Péter Juhász - 2010-06-29

    Oh. That.

    Please see my patch #8, especially the part where I vandalized eval_plots(): around line 2040, I added

    + /* Needed for variable color - June 2010 */
    + if ((this_plot->labels->textcolor.type == TC_RGB)
    + && (this_plot->labels->textcolor.value < 0)) {
    + this_plot->lp_properties.pm3d_color.type = TC_RGB;
    + this_plot->lp_properties.pm3d_color.value =
    + this_plot->labels->textcolor.value;
    + }
    + if (this_plot->labels->textcolor.type == TC_Z)
    + this_plot->lp_properties.pm3d_color.type = TC_Z;
    + if (this_plot->labels->textcolor.lt == LT_COLORFROMCOLUMN)
    + this_plot->lp_properties.l_type = LT_COLORFROMCOLUMN;
    +

    This is needed because these are the flags that will turn on variable plots at the beginning of get_data() (around line 330),

    Either do this, or modify the section at line 330 to check for textcolor variable flags. But that would mess up things. (check if the style is LABELPOINTS, and the associated label structure has the right flags)

    The funny thing is that 'lc variable' as opposed to 'tc variable' does trigger that section (at least it did when I last checked), but lc variable won't touch the label colors.

     
  • Péter Juhász

    Péter Juhász - 2010-06-29

    You inserted this_plot->lp_properties = this_plot->labels->lp_properties; at line 1881, but this does not do what you want.

    Instead you have to insert

        /\* Needed for variable color - June 2010 \*/
        this\_plot-&gt;lp\_properties.pm3d\_color = this\_plot-&gt;labels-&gt;textcolor;
        if \(this\_plot-&gt;labels-&gt;textcolor.type == TC\_VARIABLE\) 
            this\_plot-&gt;lp\_properties.l\_type = LT\_COLORFROMCOLUMN;
    

    at line 2048 or so.

    This makes the style work with the new mechanism, and all three flavors of var. color work.
    'lc var' et al. don't parse correctly now.

     
1 2 > >> (Page 1 of 2)

Log in to post a comment.