bugGNU Octave - Bugs: bug #42543, transparent surface using...

 
 

bug #42543: transparent surface using facealpha is not working

Submitter:  None
Submitted:  Wed 11 Jun 2014 10:13:07 PM UTC
   
 
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Confirmed Assigned to:  None
Originator Name:  Alexey Morozov Originator Email:  -email is unavailable-
Open/Closed:  * Open Release:  * dev
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 14 Dec 2017 05:31:12 AM UTC, comment #9: 

I wasn't aware of this bug report.  Doesn't seem like much has changed in the past couple years.  In addition to the behavior described in previous posts, I see for Qt gnuplot toolkit terminal that lines are still visible even after setting 'edgecolor' to 'none'.  (I'll investigate that one.)  However, in "pngcairo" display there are no edge lines, and transparency works.  So, the immediate solution is to use "pngcairo" instead of "png".  But similar to noted previously, the line is completely "covered" by the surface--actually I think what is happening there is the line is being segmented according to "hidden line removal" feature of gnuplot.  That is, the gnuplot algorithm thinks that line segment can be discarded because that part of the software probably doesn't understand the opacity concept.  (I'll investigate.)

Note also that Qt terminal driver in gnuplot has its own "save to file" feature which generates PNG files matching what is on screen.

Back in 2015 I wrote a patch meant to fine tune all these -d driver options that I'm not sure was ever used:

https://savannah.gnu.org/bugs/index.php?44187

It appears to have been updated by others.  Maybe equating "png" to "pngcairo" was part of that.  Another feature that was part of that patch, as best I remember, was a "demo print" which would create a list dialog of all the possible -d[driver] options and then print the figure with that driver and call some external app for viewing the final result, even if that meant having to run the result through latex and send the result to a secondary viewer.  It was a nice way to quickly observe driver feature support for most all terminals and a clue of the syntax needed for utilizing the output format.  (I'll look through the current code and see if any elements of the patch I'm referring to have found their way into the current tip.)

Dan Sebald <sebald>
Thu 14 Dec 2017 02:32:41 AM UTC, comment #8: 

The issue seems to be that not many gnuplot terminals actually support transparency.  "help transparent" from within gnuplot 5.0.3 returns


      terminal   solid pattern    pm3d
       --------------------------------
       gif           no     yes      no
       jpeg         yes      no     yes
       pdf          yes     yes     yes
       png    TrueColor   index     yes
       post          no     yes      no
       svg          yes      no     yes
       win          yes     yes     yes
       wxt          yes     yes     yes
       x11           no     yes      no


In particular, the eps terminal does not seem to support transparency.  This is an issue for Octave because printing generally relies on first creating a .eps file, and then using Ghostscript to transform from eps to just about anything else.

There are several workarounds.  First, use a terminal that supports transparency such as "svg".  Second, go through the cairo series of terminals if they are supported on your computer.


print -dsvg file.svg
print -dpngcairo file.png
print -dpdfcairo file.pdf
print -depscairo file.eps


I've added Dan Sebald to the CC list since he is the export on the gnuplot interface.  A longterm option for Octave might be to switch from using the "eps" terminal to the "epscairo" terminal to generate the initial eps file.  With that change, the rest of the backend plotting routines would work just fine.


Rik <rik5>
Group administrator
Wed 11 Mar 2015 10:08:00 PM UTC, comment #7: 

I'm now facing the same issue:

1. Alpha is not preserved when using `print` to an image file (e.g. -dpdf, or -dpng).

2. Alpha can be observed on-screen using gnuplot's qt terminal.

How are images generated with `print`?  Can that path inherently support alpha?

jpap <jpap>
Tue 17 Jun 2014 02:19:01 PM UTC, comment #6: 

Using "setenv GNUTERM qt" gives the correct result.

And if I save a PNG from the window's menu, it also contains the transparency.


setenv GNUTERM qt
figure(1);
clf;
hold on;
for i = 1:10
        h(i) = fill(rand(3, 1), rand(3, 1), rand(3, 1));
        set(h(i), 'facealpha', rand(1));
end
grid on
hold off;
pause


"print 'output.png'" still does not work.


Francisco Albani <falbani>
Tue 17 Jun 2014 01:41:50 PM UTC, comment #5: 

To clarify, I get the correct transparency on-screen using gnuplot's qt terminal, but not when the figure is printed to a PNG file.

Mike Miller <mtmiller>
Group Member
Tue 17 Jun 2014 01:40:13 PM UTC, comment #4: 

Both the OP's example and your example work fine for me in gnuplot 4.6 using the qt terminal but not the x11 terminal. Can you confirm if you "setenv GNUTERM qt" in octave and then run your example, you get the correct behavior?

Mike Miller <mtmiller>
Group Member
Fri 13 Jun 2014 06:10:24 PM UTC, comment #3: 

I should add that all I mentioned was done from an up-to-date Arch Linux.


# uname -a
Linux godel 3.14.4-1-ARCH #1 SMP PREEMPT Tue May 13 16:41:39 CEST 2014 x86_64 GNU/Linux



octave:2> version
ans = 3.8.1


Francisco Albani <falbani>
Fri 13 Jun 2014 04:10:03 PM UTC, comment #2: 

I have exactly the same problem. Monts ago it was working fine.

I'm using Gnuplot toolkit.

I tried this with gnuplot terminal: http://www.gnuplotting.org/?s=transparent and it worked fine.


graphics_toolkit ('gnuplot')
figure(1);
clf;
hold on;
h1 = fill([0 1 1 0], [0 0 1 1], 'red');
h2= fill([0.5 1.5 1.5 0.5], [0.5 0.5 1.5 1.5], 'blue');
set(h1, 'facealpha', 0.5);
set(h2, 'facealpha', 0.5);
hold off;
print 'output.png'


I have attached the output png.


Francisco Albani <falbani>
Thu 12 Jun 2014 01:29:28 AM UTC, comment #1: 

Thanks for your bug report. You have reported this as being with gnuplot, are you sure you are using the gnuplot backend and not fltk?

If gnuplot, then this could be specific to gnuplot's windows terminal.

If fltk, then this looks like a duplicate of bug #39535.

Mike Miller <mtmiller>
Group Member
Wed 11 Jun 2014 10:13:07 PM UTC, original submission:  


p = peaks(40);
f1 = figure(10);clf
s1 = surface(p)
view(3)
xlabel('x');ylabel('y');
hold on;plot3([0 40],[40 0],[-10 10],'k')
set(s1,'edgecolor','none')
set(s1,'facealpha',0.2)


produces a line that is completely obstructed by surface instead of being partially seen-through as shown here http://stackoverflow.com/questions/12072412/setting-transparancy-of-surface-plot-on-octave/24173227?noredirect=1

So facealpha just makes the plot lighter in color...

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #31572:  output.png added by falbani (136KiB - image/png)
file #31545:  output.png added by falbani (16KiB - image/png - Output of script.)

 

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 rik5
  • -email is unavailable- added by jpap (Posted a comment)
  • -email is unavailable- added by falbani (Updated the item)
  • -email is unavailable- added by None (Submitted the item)
  •  

    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 group members can vote.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-04-27 mtmiller Carbon-CopyRemoved 80942 -
    2018-04-27 mtmiller Release3.8.1 dev
    2017-12-14 rik5 Item GroupInaccurate Result Incorrect Result
        StatusNeed Info Confirmed
        Operating SystemMicrosoft Windows Any
    2017-12-14 rik5 Carbon-Copy- Added sebald
    2014-06-17 falbani Attached File- Added output.png, #31572
    2014-06-13 falbani Attached File- Added output.png, #31545
    2014-06-12 mtmiller StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code