[Octave-bug-tracker] [bug #49194] Surface color incorrect under gnuplot 4.4.0

[Dan Sebald]

Follow-up Comment #3, bug #49194 (project octave):

Writing some notes here for reference.  I'll think this over for a while to
see if I can dream up some simple solution:

I think this bug appeared with this changeset from a year ago (applied in
February):


changeset:   21373:21c3641422e0
user:        Daniel J Sebald <address@hidden>
date:        Sun Feb 28 20:58:56 2016 -0500
files:       scripts/plot/util/private/__gnuplot_draw_axes__.m
scripts/plot/util
description:
Fix gnuplot toolkit face/edgecolor and linestyle/width for surf() (bug
#34523)

* __gnuplot_has_feature__.m (__gnuplot_has_feature__): Add "linetype" and
"dashtype" to list of 'features' string cell array, "4.6" and "5.0" to
'versions' string cell array, and ">=", ">=" to 'operators' string cell
array.

* __gnuplot_draw_axes__.m (__gnuplot_draw_axes__): Keep hidden line removal
for case of line in 3D plot.  Get style index as part of do_linestyle_command
call.  Determine style command, 'linetype' or 'linestyle' depending on
gnuplot
feature support, and place in the withclause{} strings.  Move linestyle
property
translation to its own function gnuplot_linetype() and call that function. 
For
a surface, do not initialize withclause{} to pm3d and drop withpm3d logical
variable.  Move flat_interp_face, flat_interp_edge and
facecolor_none_or_white
definitions to sooner point in flow.  If the surface has a face color, set
the
fourth data column to the same 24-bit RGB face color value.  Consolidate
'unset
pm3d' at one location prior to conditional tests.  After using style{1},
remove
it from cell list.  If surface has no face color, add "nohidden3d" to the
withclause{}.  If surface has face color, set hidden_removal to true and use
pm3d with the "linecolor RGB variable" mode option in the withclause{}.  Move
"set pm3d explicit etc." to after the conditional statements and change the
first test to negative logic.  Condense the additional style{} processing
into
a for-loop.  Add "front nooffset" when setting hidden3d.  Place a newline
character at the end of the data sent to gnuplot.
(do_linestyle_command): Return the style indeces, ltidx, in addition to style
strings.  Add 8 to the index to keep first 8 linetypes intact.  Choose style
command according to gnuplot feature support, 'linetype' or 'line style'. 
Use
new function gnuplot_linetype() to generate line pattern command and send to
gnuplot if not empty.  Add index to ltidx[] when string is added to style{}.
(gnuplot_linetype): New function containing switch statements for translating
linestyle to a gnuplot command option, either 'dashtype', 'linetype' or empty
depending upon whether gnuplot has the recent dashtype or linetype features.


In particular, this change:

"If the surface has a face color, set the fourth data column to the same
24-bit RGB face color value."

is probably the source.  The above is a feature of current gnuplot (4.6+), but
I'm going to guess that gnuplot 4.4.0 doesn't allow "with pm3d linecolor rgb
variable".  Instead, under gnuplot 4.4.0 the fourth column (white, which is
0xFFFFFF or 16777215) is not treated as 24-bit true-color, but instead is
treated as an index into the colormap.  Clearly such a large value saturates
at 64 (63, 0-start), so that picks the largest color value which is yellow;
hence the image originally attached.

I suppose what I need to do is avoid the 24-bit column if not necessary (i.e.,
all one color surfaces) and instead use an extended colormap and set the
fourth column to the proper index value of the extended map.  Any Octave usage
that requires 24-bit surface data (e.g., projecting a photo image onto a
surface--not so common use) will simply be wrong under gnuplot 4.4.0.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?49194>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/