bugGNU Octave - Bugs: bug #49194, Surface color incorrect under...

 
 

bug #49194: Surface color incorrect under gnuplot 4.4.0

Submitted by:  Dan Sebald <sebald>
Submitted on:  Mon 26 Sep 2016 11:21:15 PM UTC  
 
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  3 - Low Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Thu 06 Oct 2016 04:41:37 AM UTC, comment #9: 

Yes, lots of changes going on.  The conditional statement was for the background.  I'll post a comment at https://savannah.gnu.org/bugs/?49223 .

Dan Sebald <sebald>
Thu 06 Oct 2016 12:25:28 AM UTC, comment #8: 

Ok, I guess that this error was due to a subsequent change. I updated to 0af4e27c50e0 explicitly to test this change only, and it does eliminate the yellow background. The surface is transparent rather than opaque, no change there, but no error message.

The error message I reported in comment #7 is due to the subsequent change for bug #49223. And that actually affects any plot, so that's a new and separate regression.

Consider this bug fixed if the intent was indeed to just eliminate the yellow background while still having a transparent surface.

Mike Miller <mtmiller>
Project Administrator
Thu 06 Oct 2016 12:13:28 AM UTC, comment #7: 

I get a slightly better looking plot with this change applied, but I now get the following error messages printed to the terminal:

>> graphics_toolkit gnuplot
>> demo waterfall 1
waterfall example 1:
clf;
colormap ("default");
Z = peaks ();
waterfall (Z);
title ("waterfall() plot of peaks() function");


gnuplot> if (GPVAL_TERM eq "qt") {set obj 1 rectangle from screen 0,0 to screen 1,1 behind fc rgb "#ffffff" fs solid noborder}
                                 ^
         line 0: invalid complex constant

>>
gnuplot> unset obj 1;
                    ^
         line 0: object not found

These messages did not appear before, when the surface had a yellow background. Now there is no yellow, but the surface is transparent instead of opaque as it is under gnuplot 4.6 or 5.

Mike Miller <mtmiller>
Project Administrator
Mon 03 Oct 2016 07:55:51 PM UTC, comment #6: 

I pushed your change to the stable branch here (http://hg.savannah.gnu.org/hgweb/octave/rev/0af4e27c50e0).  I tested with 5.0.1 and 4.6.6.  Maybe Mike can test with 4.4 since he has that setup available somewhere.

Rik <rik5>
Project Administrator
Fri 30 Sep 2016 07:44:41 AM UTC, comment #5: 

Sorry the last patch was missing a hunk (accidentally selected something in tortoise-hg).  New patch attached.

(file #38628)

Dan Sebald <sebald>
Fri 30 Sep 2016 07:38:43 AM UTC, comment #4: 

The attached patch does what I proposed below, i.e., adds the one surface color to the extended color map.  It's a very simple change.  Try

demo waterfall 1
kids = get(gca,'children')
set(kids(1),'facecolor',"cyan")

Note that I'm not sure things like 'facecolor' being "flat" works consistent with Matlab, but the description isn't clear to me.  Anyway, I think there isn't enough time to aim for 100% consistency before release 4.2.  This attached should do for now.

(file #38627)

Dan Sebald <sebald>
Fri 30 Sep 2016 01:14:43 AM UTC, comment #3: 

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 <daniel.sebald@ieee.org>
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.

Dan Sebald <sebald>
Thu 29 Sep 2016 09:16:01 PM UTC, comment #2: 

This was fine in Octave 4.0?  So, I must have changed something inadvertently.  I'll have a look.

An additional observation:

demo waterfall 1
colorbar

shows that yellow is the extreme max of the color bar, which should be a good hint about something having to do with a poorly extended colormap.

Dan Sebald <sebald>
Tue 27 Sep 2016 05:40:57 PM UTC, comment #1: 

Confirmed here with gnuplot 4.4, and confirmed that it did look correct with Octave 4.0, so regression is appropriate, as is low priority.

Affects mesh, meshz, and waterfall functions.

Mike Miller <mtmiller>
Project Administrator
Mon 26 Sep 2016 11:21:15 PM UTC, original submission:  

With all the changes that have happened for gnuplot toolkit as of late, the following demo is producing a surface with a yellow color.

demo waterfall 1

for gnuplot 4.4.0 on my system.  (See attached screen capture.)  More recent versions of gnuplot create the expected white surface under the gnuplot toolkit.

This is a low priority item as it could be a bug in gnuplot 4.4.0, but it might be that a simple syntax changes for setting up the surface color solves the issue.

Dan Sebald <sebald>

 

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

Attach Files:
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-10-06 rik5 StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2016-10-03 rik5 StatusConfirmed => Ready For Test
    2016-09-30 sebald Attached File- => Added octave-gnuplot_surf_facecolor_bug49194-djs2016sep30.patch, #38628
    2016-09-30 sebald Attached File- => Added octave-gnuplot_surf_facecolor_bug49194-djs2016sep29.patch, #38627
    2016-09-27 mtmiller Priority5 - Normal => 3 - Low
        StatusNone => Confirmed
    2016-09-26 sebald Attached File- => Added Screenshot from 2016-09-26 18:18:18.png, #38603

    Back to the top


    Powered by Savane 3.5