bugGNU Octave - Bugs: bug #48689, Out of limits patches lead to...

 
 

bug #48689: Out of limits patches lead to corrupted figure printout

Submitter:  Vic Norton <vicnorton>
Submitted:  Wed 03 Aug 2016 12:44:53 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Confirmed Assigned to:  None
Originator Name:  Vic Norton Open/Closed:  * Open
Release:  * 4.0.3 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 17 Feb 2019 01:07:02 AM UTC, comment #19: 

I made "-loose" the default for 5.1 here https://hg.savannah.gnu.org/hgweb/octave/rev/3a10bdbe6839.

I merged the change on to the development branch and then immediately reverted the change only on the development branch.  I figure we have a year to fix this before the 6.1 release.

Rik <rik5>
Group administrator
Sat 16 Feb 2019 09:08:08 AM UTC, comment #18: 

@Rik: No this should not gate the 5.1 release, but yes I'd like to revert to "-loose" by default.

Pantxo Diribarne <pantxo>
Group Member
Fri 15 Feb 2019 07:36:49 PM UTC, comment #17: 

@Pantxo: I agree that I would love to have our OpenGL code reviewed by someone who is an expert in this domain.  It's not that we are bad coders, its just not my area of expertise and I'm sure somebody who does graphics all the time would have lots of small fixes.

Should this bug gate the 5.1 release?  I lean towards "No".  The reasoning is that I think this will be a difficult fix, deeply embedded in Octave, and the chance for side effects is large.

The onely thing I can think of trivially would be to revert to '--loose' by default so that if there are problems, they are encountered less frequently.

Rik <rik5>
Group administrator
Thu 07 Feb 2019 08:40:09 PM UTC, comment #16: 

@Rik:

>> And the eventual fix has to take place upstream, and may never come.


I think we'd better bet on Octave moving to modern opengl, and abandoning the GL_FEEDBACK mode among many other deprecated features.
Isn't there some game developers forum where we could go and do some advertisements for GSOC? After all when you compare to modern video games, writing Octave's opengl renderer doesn't look like a big challenge :-).

>> Is there a documentation fix that we can use in the short term for the 5.1 release?


"Printing patches or surfaces that are not entirely included in their parent axes limits (e.g. after zooming) is known to cause problems with vector formats (see bug #48689). The workaround is to use "axis auto" before printing or adjust the size of the objects to fit in the axes box."


Pantxo Diribarne <pantxo>
Group Member
Thu 07 Feb 2019 05:16:54 PM UTC, comment #15: 

This is quite far-reaching.  And the eventual fix has to take place upstream, and may never come.

@Pantxo: Is there a documentation fix that we can use in the short term for the 5.1 release?  For example, saying something about using axis limits which include all data.

In the medium term, we might be able to at least warn about it by adding checks on the axis limits and the extent of the data.


Rik <rik5>
Group administrator
Sun 24 Jun 2018 08:49:52 PM UTC, comment #14: 

This bug affects not only Mac OS's implementation of opengl library but also the state of the art Mesa gallium implementation. Windows mxe binaries are thus also affected (since they now link to Mesa gallium based "llvm-pipe" by default) and all the most recent linux distributions.

Can we rename this bug report to something like "Out of limits patches lead to corrupted figure printout"?

Pantxo Diribarne <pantxo>
Group Member
Sun 07 Aug 2016 10:11:56 PM UTC, comment #13: 

Thanks for your comments, Dan. I have absolutely no problems with the gnuplot qt terminal and its export functions. I wouldn't think of using anything else to produce Octave graphics for PDF presentation---which is what I plan to do with my original example.

Vic Norton <vicnorton>
Sun 07 Aug 2016 07:11:58 PM UTC, comment #12: 

A couple comments about this specific example.

1) I don't know how recent your version of Octave is, but there's been an attempt to bring back some functionality of gnuplot that was lost in 4.0.  The approach in 4.0 was to print to an EPS file and then convert that result to whatever the desired output format is.  That lost the wealth of gnuplot term options, some of which make much nicer outputs than converting some bit image.

2) Tessellation issues have come up several times now with the Mesa library, and I think those are outside of Octave's control.  The only solution is to get the latest version of Mesa and see if the issue has been solved.  I've tried fixing some issues in one of the OpenGL drivers and posting to that project's bug-report system.  Didn't get much traction though.  They seem to be a small, insular community, but there is lots of traffic in terms of patch sets so hopefully things get fixed.

A more general comment is that the closest one will get to WYSIWYG for gnuplot is the Qt terminal and using its export functions.  Otherwise, gnuplot uses lots of different drivers and libraries to create its terminals.  Good and bad, I suppose.  The good aspect is the flexibility to create some format that some user is historically used to using.  For example, I've always had an interest in post-processing my figures using LaTeX so that I can have math symbols/fonts/formulas matching the output of a LaTeX manuscript.  Manually overlaying formulas in the manuscript itself is too tedious.  Writing the formulas in Octave (even though it looks bad in other displays and prints) is an OK compromise.  The reason gnuplot isn't WYSIWYG focused is because it began years before that notion and things like Display PostScript which was popularized by NeXT.  For gnuplot the model has been a "terminal" at the end of some printer cable.

One last comment is that Apple is the least-well supported platform for open-source projects, for whatever reason.  There aren't that many users testing open-source software.  Variations in compilers, system libraries, etc. complicate things and it usually takes a while to work the kinks out of Apple builds.

Dan Sebald <sebald>
Sun 07 Aug 2016 01:49:24 PM UTC, comment #11: 

Observations based on the images in file #38126
0. All images were produced on a Mac OS X 10.11 system.
1. There are two graphical systems represented by these images.
  a. graphics_toolkit gnuplot; setenv GNUTERM qt;
  b. graphics_toolkit qt;
2. Both systems can save graphical PGF output with the print
   function, e.g.,
     print sergX.pdf;
   but system "a" can also "export" graphical output from its
   "gnuplot-qt" window.
3. Of the three ways to produce and save graphical output from an
   octave script to a PDF file,
     gnuqt-export, gnuqt-print, qt-print,
   only the first way creates an exact representation of the screen
   image on my Macintosh screen.
4. The most serious problem illustrated by Dmitri Sergatskov's
   "simplified test" is seen by comparing
     sergA_qt_screen.pdf  and  sergA_qt_print.pdf.
   The print image is an ugly distortion of the screen image.
   On the other hand, if one backs away a bit, as in
     sergB_qt_screen.pdf  and  sergB_qt_print.pdf,
   the print image is a more accurate representation of the code.

Vic Norton <vicnorton>
Sat 06 Aug 2016 12:43:15 PM UTC, comment #10: 

I'm attaching two variations of Dmitri Sergatskov's simplified test with examples of Macintosh output in the file sergatskov-example-mac.tar.gz.

(file #38125)

Vic Norton <vicnorton>
Fri 05 Aug 2016 12:58:24 AM UTC, comment #9: 

Good catch, great that you are able to reproduce on any Gallium based driver. And good analysis and test case, so it looks like this may occur when a patch extends outside of the axes area.

Mike Miller <mtmiller>
Group Member
Fri 05 Aug 2016 12:42:38 AM UTC, comment #8: 

A simplified test:


>> demo patch 1
patch example 1:
 %% Patches with same number of vertices
 clf;
 t1 = (1/16:1/8:1)' * 2*pi;
 t2 = ((1/16:1/8:1)' + 1/32) * 2*pi;
 x1 = sin (t1) - 0.8;
 y1 = cos (t1);
 x2 = sin (t2) + 0.8;
 y2 = cos (t2);
 patch ([x1,x2], [y1,y2], 'r');
>> axis([-0.9,0.9,-0.9,0.9], "equal")
>> print t4.eps

the result is attached.

If I do:

>> axis([-2,2,-2,2], "equal")
>> print t4.eps


(i.e. the entire patch is displayed)
the eps looks OK.

Dmitri.
--


(file #38115)

Dmitri A. Sergatskov <dasergatskov>
Thu 04 Aug 2016 11:09:23 PM UTC, comment #7: 

AMD /Gallium 04 has a similar problem.
Intel/Sandybridge OK (well similar to Mike's -- the colors look wrong).

Gallium problem?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 04 Aug 2016 09:44:37 PM UTC, comment #6: 

On Fedora 24 /4.1.0+
changeset:   22197:e43d83253e28
bookmark:    @
tag:         tip
user:        John W. Eaton <jwe@octave.org>
date:        Mon Aug 01 12:40:18 2016 -0400
summary:     refill multi-line macro definition

(nouveau/Gallium 0.4 driver)

it produces unreadable eps (attached).
I still think the GL driver is the problem.
(tried both qt and fltk).

svg is readable (by chrome) and shows problem similar to
Vic's. (also attached)

Dmitri.


(file #38112, file #38113)

Dmitri A. Sergatskov <dasergatskov>
Thu 04 Aug 2016 04:10:41 PM UTC, comment #5: 

Attaching the eps file provided by the OP to this bug report here. It shows the same symptom, which seems to point at gl2ps. I'm also attaching the eps file obtained on my Debian system with the same input. The difference is visible in the files, and possibly identifiable by comparing the eps produced by gl2ps on each system.

(file #38105, file #38106)

Mike Miller <mtmiller>
Group Member
Wed 03 Aug 2016 09:22:18 PM UTC, comment #4: 

Vic, sorry but you cannot reply via email to the bug tracker, please use the comment box on the web page.

Quoting your email:

> I have changed the code to reflect Mike Miller’s concerns.
> Everything looks the same except two of the “straight_qt”
> points now are colored and much smaller. There is no
> correlation between the color of X and the yellow
> shading/interpolation.
>
> BTW, I’m not sure where this bug got its description. The black
> and yellow shading problem only occurs when you try to “print"
> the straight qt image to a PDF. The screen shot of the straight
> qt has no yellow (except for the X point), but this image is
> pretty terrible too.


I set the bug title to what I perceive to be the biggest problem in your plot comparison.

In my experience, a bug report that says "a dozen things are different between A and B" is impossible to follow and get resolution on, so please try to keep each bug report to one distinct problem. If you think the line quality is poor in the qt toolkit, please report that as a distinct bug. If you think the font quality is poor, please report that as a distinct bug.

From my viewing angle, the main difference between "gnuplot_qt_Export_to_PDF.pdf" and "straight_qt_print_to_PDF.pdf" is the yellow/black shading garbage, which is why I set that as the focus of this bug report. If that were fixed, do you see other differences between the two PDF files that should be fixed? If so, please report separate bug reports for each such difference.

I asked for the same plot in eps and svg formats, can you please provide that? That should be as simple as


graphics_toolkit qt
macplotbug
print output.eps
print output.svg


Mike Miller <mtmiller>
Group Member
Wed 03 Aug 2016 06:06:24 PM UTC, comment #3: 

Just to confirm, is there a correlation between the color of that point marked X and the yellow shading/interpolation?  Can you change the color of that point and see if the unwanted shading changes color as well?

Dan Sebald <sebald>
Wed 03 Aug 2016 04:34:54 PM UTC, comment #2: 

And see bug #48208, as you were pointed to earlier, for a tip on fixing your script with respect to the marker color differences. You should be doing something like this to get a large marker with a colored region:


plot (1, 1, "o", "markeredgecolor", "black", "markerfacecolor", "red", "markersize", 12)


The syntax you are using may give you what you want in gnuplot, but it is not correct.

Mike Miller <mtmiller>
Group Member
Wed 03 Aug 2016 04:15:13 PM UTC, comment #1: 

Thanks for the report Vic. As I urged you to report this bug, I'm retitling it to be about what I see as the primary issue, the yellow shading region showing up in the output of your image from the qt toolkit.

Can you print the same figure to eps and svg using the qt toolkit and attach those files as well?

Mike Miller <mtmiller>
Group Member
Wed 03 Aug 2016 12:44:53 PM UTC, original submission:  

My code 'macplotbug.m' and five images are contained in the attached octave-graphics-problem-mac.tar.gz.

Vic Norton <vicnorton>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #38125:  sergatskov-example-mac.tar.gz added by vicnorton (74KiB - application/x-gzip - code and images from Mac)
file #38115:  t4.eps added by dasergatskov (7KiB - image/x-eps)
file #38113:  output_fc24_410_nouveau_qt.eps added by dasergatskov (832KiB - application/postscript)
file #38105:  output-mac.eps added by mtmiller (844KiB - application/postscript)
file #38106:  output-debian.eps added by mtmiller (827KiB - application/postscript)
file #38096:  octave-graphics-problem-mac.tar.gz added by vicnorton (766KiB - application/x-gzip - I've changed the code and images to reflect Mike Miller's comments.)
file #38091:  octave-graphics-problem-mac.tar.gz added by vicnorton (764KiB - application/x-gzip)

 

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 pantxo (Posted a comment)
  • -email is unavailable- added by dasergatskov (Updated the item)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by vicnorton (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 15 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-11-06 mtmiller Carbon-CopyRemoved 80942 -
    2018-11-06 pantxo Operating SystemMac OS Any
        Summaryprint to pdf shows black and yellow shaded regions not present on screen on macOS Out of limits patches lead to corrupted figure printout
    2018-06-24 pantxo StatusNeed Info Confirmed
    2016-08-06 vicnorton Attached File- Added sergatskov-example-mac.tar.gz, #38125
    2016-08-05 dasergatskov Attached File- Added t4.eps, #38115
    2016-08-04 dasergatskov Attached File- Added output_fc24_410_nouveau_qt.svg, #38112
        Attached File- Added output_fc24_410_nouveau_qt.eps, #38113
    2016-08-04 mtmiller Attached File- Added output-mac.eps, #38105
        Attached File- Added output-debian.eps, #38106
    2016-08-03 vicnorton Attached File- Added octave-graphics-problem-mac.tar.gz, #38096
    2016-08-03 mtmiller CategoryPlotting Plotting with OpenGL
        StatusNone Need Info
        SummaryOnly gnuplot-qt produces reasonable PDF graphics on my Mac system print to pdf shows black and yellow shaded regions not present on screen on macOS
    2016-08-03 vicnorton Attached File- Added octave-graphics-problem-mac.tar.gz, #38091

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code