bugGNU Octave - Bugs: bug #49017, drawing grid uses RGBA color...


bug #49017: drawing grid uses RGBA color syntax incompatible with gnuplot 4.4

Submitter:  Mike Miller <mtmiller>
Submitted:  Tue 06 Sep 2016 09:23:00 PM UTC
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Thu 08 Sep 2016 06:42:29 PM UTC, comment #10: 

Yes this looks like it's working for me now with gnuplot 4.4 and 4.6.

Please closed as fixed if you think this is resolved.

Mike Miller <mtmiller>
Project Administrator
Thu 08 Sep 2016 03:59:23 AM UTC, comment #9: 

OK, let's consider the uint8() a temporary fix then.

I started placing uint8() throughout for all the color processing, but then I thought maybe it best to go back and check what the Octave property processing is doing first with color because there don't seem to be any errors, yet so many uses of color.

Dan Sebald <sebald>
Thu 08 Sep 2016 03:21:48 AM UTC, comment #8: 

For the color problems with trimesh, see bug #42561.

Rik <rik5>
Project Administrator
Thu 08 Sep 2016 03:20:23 AM UTC, comment #7: 

@Dan: I checked in your change here (http://hg.savannah.gnu.org/hgweb/octave/rev/25122f114a24).

Instead of

uint8 (round (255 * color))

I used

uint8 (255 * color)

The uint8 function automatically does a round operation.  It might be useful to replace round() with uint8() more generally in _gnuplot_draw_axes_.

This is Ready for Test.

Rik <rik5>
Project Administrator
Wed 07 Sep 2016 09:44:48 PM UTC, comment #6: 

Something like the following:

diff --git a/scripts/plot/util/private/__gnuplot_draw_axes__.m b/scripts/plot/util/private/__gnuplot_draw_axes__.m
--- a/scripts/plot/util/private/__gnuplot_draw_axes__.m
+++ b/scripts/plot/util/private/__gnuplot_draw_axes__.m
@@ -1011,7 +1011,7 @@ function __gnuplot_draw_axes__ (h, plot_
               colorspec = sprintf ("lc rgb \"#%02x%02x%02x\"",
-                                   round (255*color));
+                                   uint8 (round (255*color)));

             sidx = 1;
@@ -1946,7 +1946,7 @@ function [style, ltidx] = do_linestyle_c
   found_style = false;
   if (isnumeric (linecolor))
     color = linecolor;
-    if (isfield (obj, "alpha"))
+    if (isfield (obj, "alpha") &&  __gnuplot_has_feature__ ("alphablend_linecolor"))
       alphastr = sprintf ("%02x", round (255*(1-obj.alpha)));
       alphastr = "";
diff --git a/scripts/plot/util/private/__gnuplot_has_feature__.m b/scripts/plot/util/private/__gnuplot_has_feature__.m
--- a/scripts/plot/util/private/__gnuplot_has_feature__.m
+++ b/scripts/plot/util/private/__gnuplot_has_feature__.m
@@ -39,7 +39,8 @@ function res = __gnuplot_has_feature__ (
-                         "dashtype"};
+                         "dashtype",
+                         "alphablend_linecolor"};
   persistent has_features;

   if (isempty (has_features))
@@ -49,8 +50,8 @@ function res = __gnuplot_has_feature__ (
       ## Don't throw an error if gnuplot isn't installed
       gnuplot_version = "0.0.0";
-    versions = {"4.2.5", "4.2.5", "4.4", "4.4", "4.4", "4.2", "4.2", "4.4", "4.4", "4.4", "4.4", "4.3", "4.6", "4.6", "5.0"};
-    operators = {">=", ">=", ">=", ">=", ">=", ">=", ">=", ">=", ">=", ">=", ">=", ">=", ">=", ">=", ">="};
+    versions =  {"4.2.5", "4.2.5", "4.4", "4.4", "4.4", "4.2", "4.2", "4.4", "4.4", "4.4", "4.4", "4.3", "4.6", "4.6", "5.0", "4.6"};
+    operators = {   ">=",    ">=",  ">=",  ">=",  ">=",  ">=",  ">=",  ">=",  ">=",  ">=",  ">=",  ">=",  ">=",  ">=",  ">=",  ">="};
     have_features = false (size (features));
     for n = 1 : numel (have_features)
       has_features(n) = compare_versions (gnuplot_version, versions{n}, operators{n});

Seems to solve the functional issues.  Although the uint8() keeps the values within a valid range, the color scaling/translation is obviously off for "trimesh 1" demo (the negative numbers are a strong indicator).  I think this comment suggests that the code needs to be revisited:

              ## FIXME: This is the wrong thing to do as edgecolor,
              ## markeredgecolor and markerfacecolor can have different values
              ## and we should treat them seperately.  However, the code below
              ## allows the scatter functions to work as expected, where only
              ## one of these values is set.

Should we treat the trimesh example as a separate bug?

Dan Sebald <sebald>
Wed 07 Sep 2016 08:06:45 PM UTC, comment #5: 

I'll have a look.  The has-feature test is the right idea, but obviously Octave gnuplot toolkit isn't constructing the 8-bit field properly in some cases.  It should first limit between 0 and 255, and not treat numbers as signed as a couple examples herein indicate.

Dan Sebald <sebald>
Wed 07 Sep 2016 03:31:54 PM UTC, comment #4: 

Indeed, setting alphastr to an empty string unconditionally gets rid of the error for me.

There is a similar error, but not due to the same cause, in "demo trimesh 1". This error occurs with gnuplot 4.4 but not with gnuplot 4.6:

>> demo trimesh 1
trimesh example 1:
 colormap ("default");
 old_state = rand ("state");
 restore_state = onCleanup (@() rand ("state", old_state));
 rand ("state", 10);
 N = 10;
 x = 3 - 6 * rand (N, N);
 y = 3 - 6 * rand (N, N);
 z = peaks (x, y);
 tri = delaunay (x(:), y(:));
 trimesh (tri, x(:), y(:), z(:));

gnuplot> splot ..... ## extremely long command sequence
         line 2588: expected a known color name or a string of form "#RRGGBB"

I see several instances of what look to me like bad color specs throughout the gnuplot input:

lc rgb "#30b2391cb"
lc rgb "#30b239310"

Mike Miller <mtmiller>
Project Administrator
Tue 06 Sep 2016 10:48:57 PM UTC, comment #3: 

Okay, this makes sense then.  In _gnuplot_draw_axes_.m, do_linestyle_command ()

function [style, ltidx] = do_linestyle_command (obj, linecolor, idx,
                                                plot_stream, errbars = "")
  idx = idx + 8;
  style = {};
  ltidx = [];

  if (__gnuplot_has_feature__ ("linetype"))
    scommand = "linetype";
    scommand = "style line";
  fprintf (plot_stream, "set %s %d default;\n", scommand, idx);
  fprintf (plot_stream, "set %s %d", scommand, idx);

  found_style = false;
  if (isnumeric (linecolor))
    color = linecolor;
    if (isfield (obj, "alpha"))
      alphastr = sprintf ("%02x", round (255*(1-obj.alpha)));
      alphastr = "";
    fprintf (plot_stream, " linecolor rgb \"#%s%02x%02x%02x\"",
             alphastr, round (255*color));
    color = [0, 0, 0];

I guess there should be a _gnuplot_has_feature_ test for whether the RGBA syntax is accepted.  If it isn't then alphastr should be the null string.

Just guessing, something like

    if (isfield (obj, "alpha") && __gnuplot_has_feature__ ("RGBA"))
      alphastr = sprintf ("%02x", round (255*(1-obj.alpha)));
      alphastr = "";

Dan will know about this.

Rik <rik5>
Project Administrator
Tue 06 Sep 2016 10:33:43 PM UTC, comment #2: 

Ack. In addition, running "grid off" and "grid on" repeatedly shows the same error each time the grid lines are drawn. Same error with a line plot with "grid on".

Updating summary description to reflect the more accurate symptom.

Mike Miller <mtmiller>
Project Administrator
Tue 06 Sep 2016 10:29:30 PM UTC, comment #1: 

Offhand, it looks like the difference between RGB and RGBA with alhpa channel.  The grid is black with an opacity of 0.15.  0.15*255 = 38, which is 0x26, which is what I see in the color specification.

As a test, try

hold on
view (3)

This should have the grid turned off and it may work.  If it does, then it is clearly in the grid drawing routine.

Rik <rik5>
Project Administrator
Tue 06 Sep 2016 09:23:00 PM UTC, original submission:  

Plotting any 3D plot with gnuplot 4.4 results in the following error message from gnuplot

>> peaks

gnuplot> set style line 108 linecolor rgb "#d9262626" linetype 1 linewidth 0.500000;
         line 0: expected a known color name or a string of form "#RRGGBB"

A plot is shown and the colors look equivalent to later versions of gnuplot, but the surface is transparent. The same error message and the same color string is shown for any 3D plot.

Adding sebald in cc.

Mike Miller <mtmiller>
Project Administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mtmiller (Submitted the item)
  • -email is unavailable- added by mtmiller

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.





    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-09-08 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2016-09-08 rik5 StatusConfirmed Ready For Test
    2016-09-06 mtmiller StatusNone Confirmed
        Summary3d plotting uses colors incompatible with gnuplot 4.4 drawing grid uses RGBA color syntax incompatible with gnuplot 4.4
    2016-09-06 mtmiller Carbon-Copy- Added sebald

    Back to the top

    Powered by Savane 3.9