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

 
 

bug #42543: transparent surface using facealpha is not working

Submitted by:  None
Submitted on:  Wed 11 Jun 2014 10:13:07 PM UTC  
 
Category: Plotting with gnuplotSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: ConfirmedAssigned to: None
Originator Name: Alexey MorozovOriginator Email: -unavailable-
Open/Closed: OpenRelease: 3.8.1
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 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

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.

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>
Project 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.

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

(file #31572)

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>
Project Administrator
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>
Project Administrator
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.

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.

I have attached the output png.

(file #31545)

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>
Project Administrator
Wed 11 Jun 2014 10:13:07 PM UTC, original submission:

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 File(s):
   
   
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
  • -unavailable- added by sebald (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by rik5
  • -unavailable- added by jpap (Posted a comment)
  • -unavailable- added by falbani (Updated the item)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by None (Submitted the item)
  •  

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 14 Dec 2017 02:32:41 AM UTCrik5Item GroupInaccurate Result=>Incorrect Result
      StatusNeed Info=>Confirmed
      Operating SystemMicrosoft Windows=>Any
    Thu 14 Dec 2017 01:32:07 AM UTCrik5Carbon-Copy-=>Added sebald
    Tue 17 Jun 2014 02:19:01 PM UTCfalbaniAttached File-=>Added output.png, #31572
    Fri 13 Jun 2014 04:10:03 PM UTCfalbaniAttached File-=>Added output.png, #31545
    Thu 12 Jun 2014 01:29:28 AM UTCmtmillerStatusNone=>Need Info

    Back to the top


    Powered by Savane 3.1-cleanup1