bugGNU Octave - Bugs: bug #45494, Patches have spurious...

 
 

bug #45494: Patches have spurious (antialising) lines in vector printout

Submitted by:  Michael Godfrey <godfrey>
Submitted on:  Wed 08 Jul 2015 10:42:49 AM UTC  
 
Category: Plotting with OpenGLSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: ConfirmedAssigned to: None
Originator Name: GodfreyOpen/Closed: Open
Release: devOperating System: GNU/Linux

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 02 Nov 2017 11:15:56 AM UTC, comment #50:

This has become a VERY long and complex report.
Would it be possible to focus on just one issue:
Looking at Figure 15.2 of the Manual most users will
conclude that Octave cannot be used for plotting histograms.
This may well discourage to them from its use. Since this
apparent fact is actually incorrect it seems to me important
to at least correct the Manual. As an absolute minimum the
flow for generating Figure 15.2 could just be made a
special case so that the figure is directly generated
using the commands shown in the Manual. Of course, it
would be best if in general the figures were generated as
shown in the Manual. This was the original intent of
including the Octave text in the Manual for each figure.

Michael Godfrey <godfrey>
Project Member
Sun 03 Sep 2017 07:59:17 PM UTC, comment #49:

>> using botoom right alignment mode


I meant bottom left

Pantxo Diribarne <pantxo>
Project Member
Sun 03 Sep 2017 07:58:10 PM UTC, comment #48:

@Dan: Sorry I attached the patch this time.

>> Would it make sense to issue some type of warning message in the print() command if gl2ps < 1.4.0 about missing colorbar?


colorbars are quite common objects in a plot and pdf is probably the most widespread vector format nowadays. This would be a major regression which a warning would not forgive. Again I'd advocate for including a copy of gl2ps latest released version (as we used to do).

>> Can the text label placement be avoided by changing the alignment mode? Or is there some type of more fundamental issue in gl2ps?


Yes, this is actually what we currently do whenever we need to split a string into substrings with different size, font, ... (e.g. "e^x"): we position each string manually using botoom right alignment mode, the only mode that works for pdf before this cset
http://gitlab.onelab.info/gl2ps/gl2ps/commit/006ffbf6fec28bbb982826cb61c98bd5c6d0e5c6

(file #41723)

Pantxo Diribarne <pantxo>
Project Member
Fri 01 Sep 2017 02:41:06 PM UTC, comment #47:

Did you forget to attach the patch that enables PDF gl2ps for -dpdf?

My only thought is that there's no good solution, so might as well make such a change and allow gl2ps to eventually be fixed. The user can always generate a PS/EPS file and then externally convert to to PDF if s/he wants the current result.

Would it make sense to issue some type of warning message in the print() command if gl2ps < 1.4.0 about missing colorbar? Otherwise there will be many duplicate bug reports showing up on Savanah.

Can the text label placement be avoided by changing the alignment mode? Or is there some type of more fundamental issue in gl2ps?

Dan Sebald <sebald>
Fri 01 Sep 2017 12:25:09 PM UTC, comment #46:

The attached simple patch is enough to have Octave use the native gl2ps pdf output for "-dpdf" and "-dpdfwrite". Try

As you can probably see:

  • The text labels are misplaced. This bug has been solved in the latest dev version of gl2ps [1]
  • If you are using a version of gl2ps < 1.4, the image of the colorbar is missing [2].

On linux we can't expect that lts distributions will ship with gl2ps 1.4.0 (don't speak about 1.4.1 which will have text alignment fixed) before a few years from now. So I don't think it is an option to do the switch unless Octave itself includes its own copy of gl2ps as it used to do.

Thoughts ?

[1] http://gitlab.onelab.info/gl2ps/gl2ps/commit/2b7018cce99dfdf3a338e796530551d89d5730ff
[2] http://gitlab.onelab.info/gl2ps/gl2ps/commit/006ffbf6fec28bbb982826cb61c98bd5c6d0e5c6

Pantxo Diribarne <pantxo>
Project Member
Thu 27 Jul 2017 02:56:47 AM UTC, comment #45:

>> comment #15)


I tried the example of comment #15 and the native PDF surface looks much better, free of lines, whereas the converted EPS-to-PDF has all the cracks/lines we've been discussing. There is a bug in the PDF native plot, it's that the y-axis line is coming out dotted rather than solid. That's a bug for gl2ps to fix, if fltk/qt are not doing anything wrong. Viewing the converted PDF in Acroread, I quit half way through it was so slow to render. None of the -dpdfwrite examples I've generated or that you uploaded are totally free of grey lines/cracks.

>> In comment #17 I proposed to make gl2ps>>>pdf the default for pdf related outputs and introduce a new format ("-dpdfgs") to handle the gl2ps>>>eps>>>pdf tool chain. Now the question is wether the eps files should have shading enabled by default.


If the gl2ps library has support for direct PDF, by all means use that for -dpdf and -dpdfwrite. I suggest dropping the pdfgs option, though. No one will want bigger, slower, poorer quality files. Giving the user the chance to use that conversion will just lead to confusion and another future bug report. Plus, if the user insists on such a conversion there is always system level ps2pdf that he or she can use.

Dan Sebald <sebald>
Wed 26 Jul 2017 08:57:56 PM UTC, comment #44:

@Dan: as a summary
In comment #34 I used "-dpdfwrite" (I also could have used "-dpdf", which is the same with a page around the figure) precisely because it goes through the eps conversion step: the patch enables shading in the original gl2ps>>>postscript output and the aim was to show that the conversion to pdf works and may be an option in cases where the native gl2ps>>>pdf output fails (see the end of comment #15)

In comment #17 I proposed to make gl2ps>>>pdf the default for pdf related outputs and introduce a new format ("-dpdfgs") to handle the gl2ps>>>eps>>>pdf tool chain. Now the question is wether the eps files should have shading enabled by default.

  • cons:
    • large files for shaded surfaces: lets not forget that we have the raster output (png, jpg) for this kind of complicated cases,
    • slow printing
    • slow rendering in Acroread,
  • pros: sometimes better looking

Not really convincing I guess but, again, may be an option (see "-e" new option in comment #17)

Pantxo Diribarne <pantxo>
Project Member
Wed 26 Jul 2017 07:31:00 PM UTC, comment #43:

True. However, Dmitri's point is that

-dpdflatexstandalone

ends up using gl2ps's native LaTeX/PDF support, whereas

-dpdfwrite

doesn't use the gl2ps support. I just confirmed this in _opengl_print_.m:

and in the _print_parse_opts_.m there is the association between pdfwrite and the ghostscript devices:

So best as I can tell, -dpdfwrite is going this path:

gl2ps >>> EPS >>> ps2write >>> PDF

Converting EPS to PDF does not produce a reliable result, apparently. Either EPS is an inferior or insufficient format compared to PDF, or the ps2write facility is bad.

Dan Sebald <sebald>
Wed 26 Jul 2017 06:44:34 PM UTC, comment #42:

@Dan: gl2ps writes all its formats from scratch, no dependency except libpng to support images in svg. I have never had a look at the shading part of the code but it is generally very readable bare c:

http://gitlab.onelab.info/gl2ps/gl2ps/blob/master/gl2ps.c

Pantxo Diribarne <pantxo>
Project Member
Wed 26 Jul 2017 06:18:58 PM UTC, comment #41:

Oh, I thought we were talking about gl2ps's PDF support with "print -dpdfwrite". I'm fine with comment #17 ideas--was never keen on the everything-to-postscript-first approach.

About the single-precision theory, possibly if maybe the way it is programmed into PostScript isn't quite mathematically sound. (Remember, PostScript is a lot like a programming language in itself.) What would make me doubt that theory, though, is the fact that the -dpdflatexstandalone PDF output gets printed by Acroread into some sophisticated-looking PS. If it were just a bunch of triangles, one would think Acroread would produce what Xpdf produces which is only triangles.

Dan Sebald <sebald>
Wed 26 Jul 2017 05:30:14 PM UTC, comment #40:

@Dan: see comment #17
Essentially, pdflatexstandalone uses direct pdf function of gl2ps.
Otherwise it goes through ps/eps. I have some vague recollections
that postscript does single-precision math. Could it be some of the problem?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 26 Jul 2017 04:50:31 PM UTC, comment #39:

Interesting find Dmitri. Some observations:

1) The size and time of loading for the -dpdfwrite file. I did the -dpsc/-dpdf thing, which perhaps is different from this -dpdfwrite. The info within the PS file is:

%%Creator: GPL Ghostscript 910 (ps2write)

So, we are starting to get intermediary tools here that could also be a source of artifacts. Is gl2ps using some additional tools outside its control?

2) Why is this -dpdflatexstandalone better? I've replicated your result, i.e., a very nice PDF image--with and without line smoothing. I've also confirmed in various ways that when acroread and xpdf render, it is drawing small individual triangles and not some binary image representation of the drawing.

It looks like you compiled the LaTeX code to create the final image. I'm analyzing just the PDF file generated.

Q: What is Glyph &amp; Cog's role in this? pdftops is using one of its products? gl2ps is using one of their products?

What can be taken away from this? With complete certainly, probably not too much, but my hypothesis is

1) In PDF perhaps there is such a thing as a tessellated surface, hence the nice PDF files for -pdflatexstandalone. But it could be that PS doesn't have such a feature...i.e., PS has been frozen for a quite a while and was defined years ago.

2) Whatever software is generating the PDF of -pdflatexstandalone knows how to generate such tessellated surface.

3) Both Acroread and Xpdf can interpret such tessellated surface within a PDF file. The former should go without saying, but that Xpdf can do so too is good.

3) When creating PS from said tessellated surface, Acroread is doing some kind of trick to produce a nice PostScript result, whereas Xpdf is going with the basic bunch of triangles approach. In other words, poppler pdftops is using the technique that we know suffers from cracks/lines.

I'm interested in knowing more, as it would be nice for gnuplot to fix its PDF output to get rid of the lines/cracks it has underneath the black mesh lines.

Dan Sebald <sebald>
Wed 26 Jul 2017 12:45:58 PM UTC, comment #38:

And doing

I get a fantastic looking pdf (attached)

Dmitri.

(file #41341)

Dmitri A. Sergatskov <dasergatskov>
Wed 26 Jul 2017 12:36:28 PM UTC, comment #37:

Just for the record --- I get the same pdf as Pantxo.
(hg id 980f39c3ab90+ tip @ ; gl2ps1.4.0)

Also:

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 26 Jul 2017 09:00:58 AM UTC, comment #36:

For my system, I don't see much difference between before and after patch. But it is also clear that my PDF result is much less dense mesh size. The file produced here loads into Acroread in a couple seconds (file size 619173 bytes), while your file (size 7612989 bytes) takes somewhere around a minute to load. On the other hand, Xpdf is much faster reading your file and seems reasonable.

Nonetheless, I still see some lines/cracks in spots here and there with the PDF and PNG files that you uploaded. For example deep in the interior of the sombrero are a collection of grey marks. Could it be that the high density is better at covering up the lines? Zooming brings out more of the lines/cracks.

Dan Sebald <sebald>
Wed 26 Jul 2017 08:24:16 AM UTC, comment #35:

The pdf is attached compressed in .tar.gz format

(file #41340)

Pantxo Diribarne <pantxo>
Project Member
Wed 26 Jul 2017 08:18:47 AM UTC, comment #34:

@Dan: I have tested with the latest gl2ps (1.4.0) but I don't expect that it makes much difference. Don't you even differences when viewing shaded surfaces, e.g. :

For me, prior to the patch, such surface is completely cluttered with white antialiasing lines, while with the patch it is very good looking. I'll attach the pdf file (in case gl2ps version matters) and a screenshot.

Pantxo Diribarne <pantxo>
Project Member
Wed 26 Jul 2017 07:05:22 AM UTC, comment #33:

Version info from an SVG file:

Dan Sebald <sebald>
Tue 25 Jul 2017 06:06:08 PM UTC, comment #32:

This setting has no affect for me.

Here is the test script I used:

I see the same gray cracks in xpdf viewer for PDF and gv for PS. The interesting result is that viewing PDF unzoom there don't seem to be any cracks/lines along the four-sided elements, just running between points. I wonder if there was some extra slop put in the size of those elements so that the elements overlap a bit. When I zoom in both PDF and PS, then I start to see strange effects along the quadrangle borders.

But that doesn't mean something couldn't have been fixed in your system. Newer gl2ps version? Newer drivers? The OpenGL stuff seems like a bit of magic, video cards even being an issue and all.

One drawback to the removal of GL2PS_NO_PS3_SHADING is that printing slows down to at least twice as long. It seems to take a good five seconds to print without that parameter, whereas without the change printing takes about one and a half seconds.

Dan Sebald <sebald>
Tue 25 Jul 2017 03:30:25 PM UTC, comment #31:

@Dan:

>> One has to not reassemble the blue triangle to disrupt the hidden-surface layering. But one could, in fact, include the red rectangle as part of a tessellation ...


What you are proposing is to apply projection and clipping which looks like a very hard task for which neither OpenGL tesselator nor gl2ps will help.

Anyway, I just tried again to remove the "GL2PS_NO_PS3_SHADING" option, and for some reason it worked !(I am pretty sure my conclusion was the contrary a few month ago ???). I was able to generate all the demos I tried as pdf and the antialiasing lines are most of the time hardly visible. Can someone else try the attached patch?

(file #41332)

Pantxo Diribarne <pantxo>
Project Member
Thu 20 Jul 2017 08:36:22 PM UTC, comment #30:

In an editor, I removed all the black lines from foo.svg. There are no cracks or stitching lines visible in Inkscape. Is it because these are overlapping triangles? One has to not reassemble the blue triangle to disrupt the hidden-surface layering. But one could, in fact, include the red rectangle as part of a tessellation with the blue triangles around it. Nothing is lost in that case, as this is 2D data and the viewer isn't going to rotate the surface/view angle.

For gnuplot, breaking up the intersecting shapes into smaller shapes for layer order is pretty straightforward. It's more a matter of all the book keeping that has to be done. The code is C, so not convenient C++ lists.

BTW, regarding this foo.svg example, zooming into the image in the viewer or Inkscape shows a bad joining of lines where the red and blue triangles intercept. I've attached a screen capture. Through trial and error I identified the two lines as these:

It looks to me like the x,y-coordinates of the point that is supposed to match at the intersection of the blue/red triangles at that edge aren't being computed the same:

298.08,208.44
299.721,209.231

Dan Sebald <sebald>
Thu 20 Jul 2017 07:43:22 PM UTC, comment #29:

File attached.

(file #41267)

Pantxo Diribarne <pantxo>
Project Member
Thu 20 Jul 2017 07:41:57 PM UTC, comment #28:

>> What is the issue there?

gl2ps does have a pretty elaborate depth sorting algorithm (I attached the svg file I obtain using the latest gl2ps). Notice how the blue triangle has been split into two so that one is drawn first then the red triangle then the remaining blue triangle. Obviously you can't pack the 2 blue triangles back into a single polygon or you'll end-up with a very wrong figure.

Pantxo Diribarne <pantxo>
Project Member
Thu 20 Jul 2017 05:59:19 PM UTC, comment #27:

>> I also though about that but think about 3D crossing patches:


What is the issue there? That blue is blending with red when it shouldn't? I know that gnuplot has an issue with the intersecting surface, but that is because no one (probably me) has gotten around to a true surface depth sorting algorithm, but instead uses the approximating painter's algorithm.

>> I also though about that but one of the points of splitting polygons into triangles is to handle color gradients. In this case it is unlikely that 2 neighbor triangles have the same color and there is nothing to pack back.


Now that I comprehend the issue, it seems that gnuplot should have the same problem with PDF output. And it does, but in a less obvious way. If I remove the black mesh covering the edges:

('grandkids' is the surface object), then viewing the gnuplot output in Acroread results in the same issue with "Smooth line art" on/off.

Note that smoothing lines is a nice thing to have on the edges, where one intends it to be. Otherwise that outer edge of the sombrero looks kind of block-y.

>> PS: The relevant bug report for Inkscape is [1]. I know it looks like off-topic but the discussion there is quite instructive. [1] https://bugs.launchpad.net/inkscape/+bug/170356


Yes, and it is a twelve year bug because the developers (a few comments within that thread) realize how difficult a problem they would have to address it. Once the horse is out of the barn regarding the structure of that tessellated surface, it's difficult to address the issue.

This is a very general problem with PDF (or, I would say any vector-based format...in SVG we are forcing crisp edges by the hint). Here's a complaint from an unhappy camper on the Adobe site:

Feb 18, 2012 5:00 AM
Frame artifacts appearing in PDF output
https://forums.adobe.com/thread/964508

In which black lines appear rather than white (simply because of the foreground/background choice). The term "stitching" is bandied about, sort of a euphemistic way of discounting the problem by giving it a "well-known" name. I'd actually prefer the more Cohen-eque "cracking", in the sense "that's how the light gets in".

Here again from Adobe is a reference to the issue in one of their products:

Thin white, dark lines (stitching) | Export to PDF | InDesign CS2 and later
https://helpx.adobe.com/indesign/kb/thin-white-dark-lines-stitching.html

Some convoluted methodology for dealing with this, the crux of which seems to be "turn off 'Smooth line art'".

I would think that as an alternative to smoothing lines of all individual objects, the PDF viewer could first render the whole scene to the desired output resolution, and then apply image smoothing. But I suppose the philosophical issue is that vector-based descriptions are scalable.

I think the best that can be done as far as gl2ps is to somehow patch those individual tessellation triangles for a mesh square (or patch) back together. Apparently Octave isn't alone in the individual triangles:

https://www.mathworks.com/matlabcentral/answers/15388-artifacts-in-figures-exported-as-pdf-from-matlab

Again, an unhappy camper, who concludes Adobe isn't at fault. But in some sense it is a problem with the PDF language, or any vector-based description. In the grand scheme of computer graphics, it seems there should be a way of describing in the language a "tessellated surface" so that the PDF-viewer knows how to deal with smoothing at edges. A tessellated surface would probably be something described more as a mesh than individual triangles in order to avoid any type of NP-problem of putting tessellations back together.

The most productive effort in the long run would be if the graphics community were to hassle Adobe to extend their PDF/PS definition to include tessellated surfaces. (I'm not 100% sure such a thing doesn't already exist in the latest definition, but digging into PostScript requires all the documents, which I no longer have access to.) That would then make life easier for all the viewers, etc. that need to process PostScript.

Dan Sebald <sebald>
Wed 19 Jul 2017 09:34:02 PM UTC, comment #26:

@Dan:

>> It makes more sense to put such effort into gl2ps to patch things back together


I also though about that but think about 3D crossing patches:

I also though about that but one of the points of splitting polygons into triangles is to handle color gradients. In this case it is unlikely that 2 neighbor triangles have the same color and there is nothing to pack back.

PS: The relevant bug report for Inkscape is [1]. I know it looks like off-topic but the discussion there is quite instructive.

[1] https://bugs.launchpad.net/inkscape/+bug/170356

Pantxo Diribarne <pantxo>
Project Member
Wed 19 Jul 2017 05:33:46 PM UTC, comment #25:

SVG: eog (eye-of-gnome) viewer handles SVG. For that renderer, the shape-rendering="crispEdges" hint gets rid of the cracks. Probably just Inkscape where hints don't affect anything--it's more of an editor than a viewer.

Dan Sebald <sebald>
Wed 19 Jul 2017 04:52:50 PM UTC, comment #24:

> > Then I suppose you did not read comment #14 which clearly states that setting anti-aliasing off in the viewer will remove those lines.


OK, so anti-aliasing in the case of PDF doesn't refer to smoothing the whole composite image. Instead, it refers to individual objects and line art. Because of smoothing applied to the edges of all the individual tessellation triangles, the anti-aliasing feature now creates the "cracks". Adobe Acrobat has the same behavior but in its settings is

"Smooth line art"
"Smooth images"
"Enhance thin lines"

the latter probably just being a widening of low line-width numbers so that they don't disappear from view.

For Inkscape, I've changed the setting inside the SVG file for 'shape-rendering' and at the same time modified some of the Rendering settings in the Inkscape viewer, but it doesn't seem to address the issue. It could be that it is just Inkscape that does this and if one were to view the SVG image in an HTML platform things are fine. Don't know if it is that important to research that.

I don't see the point of trying to fix the rendering part of XPDF for this issue. Their response is likely to be the same as the Octave-compatibility viewpoint, i.e., that XPDF behaves the way that Acroread behaves. Then it becomes an issue of trying to convince Adobe that rendering needs to be fixed. Plus what of a half dozen more renderers in linux and Windows that might do a similar thing?

Plus, it's not like a simple fix either. Once one goes into the more general world, where the triangle points may not be exactly the same then the question becomes, "How close to the triangle edges need to be in order for us to consider that this is supposed to be one patch?" PDF files can be zoomed after all. Then it becomes an NP-search type of problem when we start talking having to compare hundreds or even thousands of little triangles.

It makes more sense to put such effort into gl2ps to patch things back together. At least there the GLU tessellation triangles might still be grouped together, thereby avoiding the NP-search. Beyond that are still some issues with gl2ps with the triangles and mesh lines. See the attached screenshot.

I don't think there is a bug here that is the responsibility of Octave. The best thing is to put a note in the "print" help specific to the fltk/qt toolkits about what to expect for the output.

(file #41246)

Dan Sebald <sebald>
Wed 19 Jul 2017 02:48:27 PM UTC, comment #23:

@Dan:

>>I don't think the issue is anti-aliasing.


Then I suppose you did not read comment #14 which clearly states that setting anti-aliasing off in the viewer will remove those lines.

As for svg, you could play with the "shape-rendering" attribute [1]. It is a rendering hint for the viewer that unfortunately has no counterpart on the pdf/eps side.

[1] https://www.w3.org/1999/07/06/WD-SVG-19990706/render.html

Pantxo Diribarne <pantxo>
Project Member
Tue 18 Jul 2017 11:21:01 PM UTC, comment #22:

> > AFAIU it is pdf/eps rasterization libraries that need a fix: you could try to find how to implement a better anti-aliasing algorithm (that doesn't take background colors into account when two foreground polygons, triangles or not, are adjacent) and submit it to libpoppler/xpdf developpers.


I don't think the issue is anti-aliasing. If anything, it has to do with the manner in which polygons are drawn/filled at the borders.

Months/years ago the last I looked at this, there is a test_gl2ps.svg file I have, which is a display of the patch demo with a green octagon to the left and a blue hexadecagon to the right. If I open that in inkscape, that two has the tessellation lines. But the tessellation lines aren't really lines, they are the "cracks" of space where two edges don't meet snugly and the white background shows through. The pixels that show through are very faint, so look grey. The slope of the line must determine the pattern at which there is a space in terms of x,y coordinates--hence some slopes look like a dotted line (crack), while others look like a solid line (crack).

The SVG file is ASCII, and it appears to me that the dimensions on the triagle vertices all match well. That is, well, I can show:

See how all the vertices coincident between triangles are the same exact value, e.g., 436.879 is consistent. In other words, there is no rounding effect on anyone's part along the way.

So, the driver's algorithm is probably something in which the formula of a line is constructed directly or indirectly and anything for which w'x < c (i.e., hyperplane notation) is colored blue. Maybe if the driver used a formula like w'x <= c it would give that outer edge of the triangle a little more width somehow. Just speculation, of course, without digging into inkscape or ghostview code, but my point is that it's sort of the driver's discretion of how to treat this. It could be that the on-screen drivers attribute more width to that triangle edge.

Is it Inscape or GhostView's responsibility to do this? From their perspective it might simply be, "We do solid polygons as a series of vertices, not tessellated triangles." And maybe that is what the "bug" is, i.e., just the fact that many drivers with polygon support for > 3 vertices don't concern themselves with tessellated triangle fills. Maybe there are some control mechanism in SVG/EPS that will make the width of the polygon's border non-zero--I've no idea.

I can add a stroke width to the triangles:

and the tessellation "cracks" go away, but the down side is that the vertices where triangles meet have jagged points that stick out. Which is worse?

> > How would you handle two adjacent polygons with different colors?


Whichever is drawn second wins out, i.e., its border is a hairline thicker than the triangle drawn underneath.

Anyway, I tested this concept as described above with SVG and the drawback is going to be little "flares" at the vertices of polygon perimeters. (Think of the pointed tip of sharp angle triangles.) It might be less drastic if we draw lines with butt caps rather than have a stroke around the polygons, but it will probably still be noticeable.

I'm beginning to think there is no good solution here, and that it is simply a matter of something being lost for drivers in general with tessellation triangles.

Dan Sebald <sebald>
Tue 18 Jul 2017 09:15:11 PM UTC, comment #21:

@Dan:

>> Can we pin-point where exactly the issue is? It's a lot of work to build OpenGL/Mesa from scratch and convince developers there is something to fix.


I think there is nothing to fix on the mesa side: the on-screen and raster offscreen images don't show these artificial lines. AFAIU it is pdf/eps rasterization libraries that need a fix: you could try to find how to implement a better anti-aliasing algorithm (that doesn't take background colors into account when two foreground polygons, triangles or not, are adjacent) and submit it to libpoppler/xpdf developpers.

>> Is there the possibility of "covering-up" the tessellation lines by drawing lines the same color as the patch after the convex shapes have been drawn?


How would you handle two adjacent polygons with different colors?

Pantxo Diribarne <pantxo>
Project Member
Tue 18 Jul 2017 06:22:04 PM UTC, comment #20:

Interesting comment here about GL_QUADS:

https://stackoverflow.com/questions/6644099/what-is-so-bad-about-gl-quads

I'm guessing that most programmers of the low-level routines found that they ended up using triangles to implement quads. The point is that the hardware ultimately determines how things are implemented, and GPUs typically have only triangles. (Something I didn't know or assume, I'd think some would have a convex shape routine.)

Can we pin-point where exactly the issue is? It's a lot of work to build OpenGL/Mesa from scratch and convince developers there is something to fix.

Is there the possibility of "covering-up" the tessellation lines by drawing lines the same color as the patch after the convex shapes have been drawn? There's nothing too difficult about that algorithm, i.e., just draw lines between all combinations of pairs of points. The tessellation lines I'm seeing always look to be a single pixel wide. Would drawing such a line be 100% accurate? That is, rather than tessellation lines there are remnants of the line, i.e., single gray pixels floating about.

Dan Sebald <sebald>
Tue 18 Jul 2017 05:50:40 PM UTC, comment #19:

@Dan:

  • Detecting non convex polygons won't solve any problem until we change our printout rendering libray: I think I already pointed you to the fact that even the most simple polygons, GL_QUAD that are non convex native opengl primitives (no GLU here), are finally tesselated into triangles and gl2ps will treat them as such. In fact gl2ps only knows about triangles and lines.
  • Graphicsmagick has nothing to do with the print process. It only handles raster formats that are already pretty well handled (see png or jpg) by ghostscript.
  • Gnuplot has nothing to do with this particular bug report.
Pantxo Diribarne <pantxo>
Project Member
Tue 18 Jul 2017 05:29:31 PM UTC, comment #18:

Dmitri is correct; the differences you are seeing is a viewer issue. Turn anti-aliasing off to get a view of everything that is present because otherwise thin, faint lines get lowpass-filtered out of the display.

I looked at the link I posted below as a reminder of what is at play here. GLU is the OpenGL library extension (i.e., it's not the OpenGL graphics primitives) but uses them to achieve slightly higher functionality, one of them being the general patch fill. GLU is most likely the software introducing the tessellation lines you see. The proper thing would be to fix the GLU library (or the primitives if it goes that far). However, as I probably pointed out elsewhere, I've tried providing OpenGL developers with fixes to other problems and found it hard to sway people working on that project.

Another alternative I thought of was to first detect any shapes which are convex because OpenGL has a routine that fills convex shapes, i.e., no tessellation required. In the example you've given, I believe most shapes are going to be convex because they are translations of squares from a mesh surface. (Four points can transform to a non-convex shape rather easily, but generally that isn't too common with reasonable surfaces when resolution is chosen properly.) There is a hunk of prototype code here:

https://savannah.gnu.org/bugs/download.php?file_id=33583

Such an approach won't totally eliminate the issue of the tessellation lines for strange surfaces if there happen to be some non-convex shapes, but for the most part it should remove them.

Regarding eps->pdf conversion, that comes from a design which simplified the matter of support for all output file formats by using one strategy of first creating and EPS file then converting that file whatever format that image-magick converter can handle, which is just about everything. So image-magick does most of the work, but the limitation is the quality of gl2ps image and there aren't any vector-based outputs. This idea of EPS->all was extended to the gnuplot toolkit as well. I didn't like that change because it really degraded the quality of output figures such as LaTeX and SVG, no less in the general sense if there are image-magick library quirks. I think gnuplot toolkit plot format richness has been restored. I also created a GUI demo that prints to any of the formats that gnuplot produces then issue system commands to externally process the example output files. That's not currently in the latest repository, but it's nice in that users can seek out the code of the demo to see how LaTeX figures, etc. should be used.

Dan Sebald <sebald>
Tue 18 Jul 2017 03:11:57 PM UTC, comment #17:

@Dmitri: pdf->eps conversion often turns out to be poor quality (rasterized graphics and text) so since eps is still preferred in some domains of scientific publication it would be best to not have converted eps. Instead I would propose the following:

  • -dps/eps/eps2 ... (latex included) : native gl2ps output. Eventually add a switch (e.g. "-e" for "enhanced") to allow the removal of the "GL2PS_NO_PS3_SHADING" option and obtain better but unconvertible results.
  • -dpdf ... (latex included) : native gl2ps output. Add a note about the new format (see below) that handles lit surfaces better
  • -dpdfgs : eps converted to pdf. "gs" is for "ghostscript" but any other name would fit.
  • rasterized formats and other vector formats: stick to eps conversion toolchain
Pantxo Diribarne <pantxo>
Project Member
Mon 17 Jul 2017 10:10:30 PM UTC, comment #16:

I just thought that since pdf is a (kind of)
superset of postscript, it would make more sense to use
pdf as a base and then convert it to less capable formats.

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Mon 17 Jul 2017 08:39:33 PM UTC, comment #15:

@jwe: actually I do see antialising lines in the eps from comment #12 when I use either evince or Okular so xpdf/poppler version or graphics hardware may also play a role. The best result I have seen for eps files and 3D surfaces were obtained when I tried to remove the "GL2PS_NO_PS3_SHADING" option in gl2ps-print.cc. The drawback is that ghostscript is unable to convert those postscript level 3 files so we are back at the beginning.

@Dmitri:As for the reason for not using the native gl2ps pdf output, I think the idea was to avoid having to fight format specific bugs. Actually the native pdf output is often nicer (it is easy to test it using the -dpdflatex devices) but it has bugs that the postscript doesn't have (and vice versa), see e.g. lit surfaces:

Note that if you remove the light in this example then "native.pdf" is much nicer than "converted.pdf".

Pantxo Diribarne <pantxo>
Project Member
Sat 15 Jul 2017 12:49:08 AM UTC, comment #14:

Also, if you display output.pdf with ghostscript:

you get no artefacts, but with -sDEVICE=x11alpha they are there.

Similar effect in Okular viewer (disabling AA for the graphics
will remove those lines) -- that apply both to eps and pdf files.

So it looks like this pdf/eps dichotomy is due to viewer options
(antialias pdf and do not antialias postscript).

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 15 Jul 2017 12:24:06 AM UTC, comment #13:

If I convert output.pdf to postscript using pdf2ps (from ghostscript distribution), the resulting output.ps does not show the artifacts.

The other question -- since gl2ps can write pdf directly,
why we are going to eps->pdf route?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 14 Jul 2017 09:53:06 PM UTC, comment #12:

Hmm, the input file was not attached properly. Trying again, but gzipped this time.

(file #41208)

John W. Eaton <jwe>
Project Administrator
Fri 14 Jul 2017 09:50:54 PM UTC, comment #11:

I started looking at this problem today, then found this (and the other) bug report. Before I read through the comments, I discovered that the eps file generated by gl2ps does not appear to have the extra lines, but the generated pdf file does. Or at least the artifacts do not appear when I view the generated eps file with evince.

Looking at what Octave's print command is doing, I captured the EPS output from gl2ps and the ghostscript filter command, which is essentially this:

The input and output files are attached.

Since displaying the PostScript file doesn't show the artifacts, is there some way to generate a PDF file that will behave the same way?

(file #41207)

John W. Eaton <jwe>
Project Administrator
Fri 23 Sep 2016 09:40:10 AM UTC, comment #10:

Going through eps is definitely not good for the longer term.
PS and EPS are used less and less, and there is no expectation
that I know of to update them in any way.

More review is needed as this is an important change.
Are there any other candidates beyond what Pantxo has
suggested?

Michael Godfrey <godfrey>
Project Member
Fri 23 Sep 2016 09:32:44 AM UTC, comment #9:

There has been discussions on the mid term ways to achieve publication quality printout from opengl based toolkits.
IMHO on the way there is a much more important issue which is text handling.

One potential intermediate solution would be changing our printing chain from opengl->eps->otherformats to opengl->svg->otherformats

Among the numerous advantages of svg over postscript:

  • native handling of non-ascii characters
  • native handling of other fonts than type 1
  • basic handling of super/sub scripts for tex interpreter strings
  • possibility to use the svg output of mathjax to render latex formated strings(as path, not characters unfortunately)
  • possibility to hint the renderer on wether the shape needs anti-aliasing (through the "shape-rendering" attribute)

The main drawback is that we need a fast and accurate svg2other converter. The candidates I have looked at are:

  • librsvg (c): limited support for the "baseline-shift" text attribute. Values "sub" and "super" are implemented but "offset" (which gl2ps uses for vertical alignment) and "percentage" are not. Antialiasing is Ok. Draws a bunch of dependencies, among which Cairo/Pango and thus gdk.
  • batik (java): the most accurate I have seen but I found it to be slow (at least for rasterized outputs) with the simple tests I did.
  • Qt: I think it is an option to look at. Qt only supports svg tiny 1.2 (IIUC a subset of svg) and thus has poorer text capabilities, but if we can workaround this (e.g. by using "dy" instead of "baseline-shift") it means no additional dependency.
Pantxo Diribarne <pantxo>
Project Member
Fri 23 Sep 2016 08:45:14 AM UTC, comment #8:

Good that the original thread was found. Sorry for not
locating it. And, my belief that this was solved was
wishful thinking!

Is Pantxo's suggestion for the long-term
solution that Cairo should be used agreed by others?
Are there other viable choices? In any case, publication
quality should be the goal.

Michael Godfrey <godfrey>
Project Member
Mon 28 Sep 2015 09:55:35 AM UTC, comment #7:

I agree that at some point, we would like to have it fixed. As we can't hope that all final rasterizing engines (printers, pdf/eps renderers, ghostscript, ...) will handle anti-aliasing properly, we should find a solution on our side.

@Dan: I don't think your strategy will lead to any improvement. Let me explain: whatever the way we draw polygons - using GLU for patches (which may be concave), or using bare OpenGL GL_QUAD for axes background (convex) - they end up being split into smaller triangles as we can see from the output of gl2ps. So trying to distinguish between convex-concave polygons is a no go.

So I'd say OpenGL = tesselation. Strategies I think about (none is simple) :

  • Use gl2ps SVG backend/parse SVG/reconstruct polygons/convert to other formats: the process of recognizing what triangle belongs to what polygon may be time consuming. To easy that job, we could add comments in gl2ps svg output using "gl2psSpecial" function.
  • Write a new renderer for 2D plots using Cairo: this is, I think, the long term solution towards publication quality outputs
Pantxo Diribarne <pantxo>
Project Member
Wed 08 Jul 2015 03:14:58 PM UTC, comment #6:

Sorry. I was mixed up. The case where hist was correct
was a gnuplot test of the patch which fixes it from
producing only black boxes. I thought that it was fltk.

Useful to get this fixed somehow, though.

Michael Godfrey <godfrey>
Project Member
Wed 08 Jul 2015 02:21:03 PM UTC, comment #5:

Duplicate bug. Long before June 23. Very OpenGL/system dependent. The issue is GLU (an extension of OpenGL, and not the actual OpenGL). GLU has a generalized polygon drawing routine for non-convex shapes which results in tessellation lines. I proposed using OpenGL's convex polygon routine (note the difference, GLU is an extension of OpenGL) whenever it is determined that the polygon is in fact convex:

https://savannah.gnu.org/bugs/?func=detailitem&item_id=44181#comment16

Didn't seem acceptable though. Try gnuplot.

Dan Sebald <sebald>
Wed 08 Jul 2015 01:12:44 PM UTC, comment #4:

Ugh. I was kind of hoping that it was just my
(Intel HD 6000) system....

The lines show up on the current stable system too.
So, the problem was introduced a while ago, but
after 23 June.

Michael Godfrey <godfrey>
Project Member
Wed 08 Jul 2015 11:22:48 AM UTC, comment #3:

spoke too soon

with
hist (randn (10000, 1), 30);
figure(1,"visible","off")
print zzz.pdf

yes I see the lines

Doug Stewart <dastew>
Wed 08 Jul 2015 11:19:22 AM UTC, comment #2:

with default from 5 days ago no dashed lines using Ubuntu 14.04

Doug Stewart <dastew>
Wed 08 Jul 2015 11:15:28 AM UTC, comment #1:

Of course, this problem may be specific to my
Fedora 22 system. So, it would help if someone could try:
and inspect the output to see if there are diagonal
dashed lines through the plot as there are in the attached PDF.

Michael Godfrey <godfrey>
Project Member
Wed 08 Jul 2015 10:42:49 AM UTC, original submission:

Using a system built before 23 June the histogram (as
in the Manual) plotted correctly. With the current system,
hist (randn (10000, 1), 30); produces results as attached.

I will try to isolate this problem, but if anyone knows
of a likely cause, it would be helpful.

This is under default. I will try stable.

Michael Godfrey <godfrey>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #41723:  nativepdf.patch added by pantxo (1KiB - text/x-patch)
file #41341:  t1.pdf.gz added by dasergatskov (316KiB - application/gzip)
file #41340:  foo.pdf.tar.gz added by pantxo (834KiB - application/gzip)
file #41332:  gl2psshading.patch added by pantxo (949B - text/x-patch)
file #41267:  foo.svg added by pantxo (9KiB - image/svg+xml)
file #41208:  gl2ps-output.eps.gz added by jwe (363KiB - application/x-tgz)
file #41207:  output.pdf added by jwe (332KiB - application/pdf)
file #34392:  zzz.pdf added by godfrey (4KiB - binary/octet-stream)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -unavailable- added by dasergatskov (Posted a comment)
  • -unavailable- added by jwe (Updated the item)
  • -unavailable- added by pantxo (Posted a comment)
  • -unavailable- added by sebald (Posted a comment)
  • -unavailable- added by dastew (Posted a comment)
  • -unavailable- added by godfrey (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 14 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 13 Nov 2017 12:30:22 PM UTCpantxoDependencies-=>bugs #45137 is dependent
    Sun 03 Sep 2017 07:58:10 PM UTCpantxoAttached File-=>Added nativepdf.patch, #41723
    Wed 26 Jul 2017 12:45:58 PM UTCdasergatskovAttached File-=>Added t1.pdf.gz, #41341
    Wed 26 Jul 2017 08:24:16 AM UTCpantxoAttached File-=>Added foo.pdf.tar.gz, #41340
    Wed 26 Jul 2017 08:19:46 AM UTCpantxoAttached File-=>Added SombreroShadedCapture.png, #41339
    Tue 25 Jul 2017 03:30:25 PM UTCpantxoAttached File-=>Added gl2psshading.patch, #41332
    Thu 20 Jul 2017 07:43:22 PM UTCpantxoAttached File-=>Added foo.svg, #41267
    Wed 19 Jul 2017 04:52:50 PM UTCsebaldAttached File-=>Added Screenshot_from_2017-07-19_11:30:46-annotated.png, #41246
    Tue 18 Jul 2017 03:13:23 PM UTCpantxoStatusNone=>Confirmed
    Fri 14 Jul 2017 09:53:06 PM UTCjweAttached File-=>Added gl2ps-output.eps.gz, #41208
    Fri 14 Jul 2017 09:50:54 PM UTCjweAttached File-=>Added output.pdf, #41207
    Fri 23 Sep 2016 08:13:58 AM UTCpantxoItem GroupRegression=>Incorrect Result
    Fri 23 Sep 2016 08:07:56 AM UTCpantxoSummaryA recent change has broken hist (randn (10000, 1), 30);=>Patches have spurious (antialising) lines in vector printout
    Wed 08 Jul 2015 10:42:49 AM UTCgodfreyAttached File-=>Added zzz.pdf, #34392

    Back to the top


    Powered by Savane 3.1-cleanup1