geom_tile and PDF Output

[Freddie Witherden]

Hello,

I am having an issue with geom_tile in that when my plot is saved as a
PDF (either directly, using pdf("..."), or through tikzdevice("..."))
that lines (or "striations") appear throughout the plot. I have
observed this behaviour on several PDF viewers and suspect it is due
to round off resulting in small gaps between tiles. These gaps allow
the background to bleed through.

This this looks somewhat awkward I am wondering if anyone knows of any
solutions? Ideally, one would have the geom_tile() layer rasterised
as a bitmap and then included as a raster as opposed to vector layer.
However, given that this does not currently seem to be implemented in
ggplo2 [1] I am open to other suggestions. Is there an easy way to
increase the size of all tile points such that they overlap? (Which
may be one of the simpler solutions.)

Regards, Freddie.

[1] See "Optimize pdf output size of geom_jitter "

[Osmo Salomaa]

At least according to the docs [1] geom_tile has a default size=0.1. I
assume you have set that to zero. If you still see lines of disturbing
width, you can explicitly draw those lines in the same color as you
fill the tiles, e.g.

ggplot(...)
+ geom_tile(aes(fill=z, color=z), size=0)
+ scale_fill_gradientn(...)
+ scale_color_gradientn(...)

where the two scale-calls have the same colors, breaks etc. This is
what I usually do and it works well enough.

And if you need to convert those PDFs to PNG or JPG, the DPI used for
that conversion will affect how visible those lines are in the raster
image, since the lines are probably as narrow as possible to render.
600 DPI can be significantly better than 300 DPI.

[1] http://had.co.nz/ggplot2/geom_tile.html

[Freddie Witherden]

On Nov 11, 3:07 pm, Osmo Salomaa <osmo.salo...@strafica.fi> wrote:
> At least according to the docs [1] geom_tile has a default size=0.1. I
> assume you have set that to zero.

I am using: qplot(x, y, data = pot, geom = "tile", fill = potential)
for my plotting and so do not believe that I am changing the size of
the tiles. It appears fine in the R preview pane (which uses X11Cairo
as the output device) -- just when saved as a PDF. Hence why I
suspect that the problems are roundoff related.

Regards, Freddie.

[Dennis Murphy]

Which version of R do you have? If it's 2.13.0 or 2.13.1, an upgrade
to 2.14.0 *might* solve the problem. In those versions, the general
type of problem you're reporting here was reported by others on R-help
in various ways, covering base graphics, lattice and ggplot2.
Infelicities with some of the graphics devices was supposed to have
been fixed in 2.13.2 and 2.14.0, and in 2.14.0 some new graphics
devices were made available in conjunction with Cairo. See the NEWS
file of the latest R release for more details.

> --
> You received this message because you are subscribed to the ggplot2 mailing list.
> Please provide a reproducible example: http://gist.github.com/270442
>
> To post: email ggp...@googlegroups.com
> To unsubscribe: email ggplot2+u...@googlegroups.com
> More options: http://groups.google.com/group/ggplot2
>

[baptiste auguie]

Quite often the problem has been quoted to be related to pdf viewers
introducing antialiasing artefacts when displaying many small tiles.
The only real workaround that I know of would be to make use of
rasterGrob instead of rectGrob -- for rectangular tiles only --, but
even that comes with its own share of pdf viewer infelicities as I
learned the hard way (try submitting a paper and telling your
coauthors+referees+editor that "it's your pdf viewer that's buggy, not
my graphic").

baptiste

[Freddie Witherden]

On Nov 11, 10:45 pm, Dennis Murphy <djmu...@gmail.com> wrote:
> Which version of R do you have? If it's 2.13.0 or 2.13.1, an upgrade
> to 2.14.0 *might* solve the problem. In those versions, the general
> type of problem you're reporting here was reported by others on R-help
> in various ways, covering base graphics, lattice and ggplot2.
> Infelicities with some of the graphics devices was supposed to have

> been fixed in 2.13.2 and 2.14.0, [..]

I have just tried R 2.14 on my Mac (my Linux distribution is yet to
provide a package for 2.13). The result is the same.

Regards, Freddie.

[Freddie Witherden]

On Nov 12, 3:24 am, baptiste auguie <bapt4...@googlemail.com> wrote:
> Quite often the problem has been quoted to be related to pdf viewers
> introducing antialiasing artefacts when displaying many small tiles.
> The only real workaround that I know of would be to make use of
> rasterGrob instead of rectGrob -- for rectangular tiles only --, but
> even that comes with its own share of pdf viewer infelicities as I
> learned the hard way (try submitting a paper and telling your
> coauthors+referees+editor that "it's your pdf viewer that's buggy, not
> my graphic").

Do you have an example of how rasterGrob can be used with ggplot2's
geom_tile? It seems as if I need to somehow first get the tiles as a
raster from R/ggplot2 and then composite that raster onto my plot
using rasterGlob. Is there a general procedure for this?

Regards, Freddie.

[Winston Chang]

I see this issue with simple things like histograms, also with R 2.14.0 (and previous versions). There's a tiny little gap between the bars, but it doesn't always appear consistently. I think it's dependent on the viewing program. With Preview on my mac, no matter how much I zoom in, the gap always appear as a tiny hairline. However, with Adobe Reader, there's no visible gap. I've attached an example PDF file.

For those who know the insides of ggplot2: do the x coordinates of the bars end and start on exactly the same number, or is there a small numeric gap?

-Winston

[Hadley Wickham]

> For those who know the insides of ggplot2: do the x coordinates of the bars
> end and start on exactly the same number, or is there a small numeric gap?

They're exactly the same.

Hadley

--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

[Winston Chang]

Strange - here are screenshots of what it looks like in the Mac Preview app. There's a tiny gap no matter how close you zoom. There's also a slight moire effect. The program must be doing something strange with the rendering, as there are no gaps when I use Adobe Reader.

-Winston

[Hadley Wickham]

That's possibly because the bars are surround by a transparent 0.5mm line.
Hadley

[Zack Weinberg]

On Sun, Nov 13, 2011 at 4:05 PM, Hadley Wickham <had...@rice.edu> wrote:
>> For those who know the insides of ggplot2: do the x coordinates of the bars
>> end and start on exactly the same number, or is there a small numeric gap?
>
> They're exactly the same.

Part of the problem may be rounding error in the PDF device. This is
the portion of the PDF content stream that actually draws the bars:

51.79 48.02 6.40 0.00 re f
58.19 48.02 6.40 0.00 re f
64.59 48.02 6.40 0.00 re f
70.99 48.02 6.40 21.48 re f
77.39 48.02 6.40 21.48 re f
83.79 48.02 6.40 21.48 re f
90.19 48.02 6.40 42.97 re f
96.60 48.02 6.40 42.97 re f
103.00 48.02 6.40 42.97 re f
109.40 48.02 6.40 21.48 re f
115.80 48.02 6.40 64.45 re f
122.20 48.02 6.40 85.93 re f
128.60 48.02 6.40 85.93 re f
135.01 48.02 6.40 107.42 re f
141.41 48.02 6.40 193.35 re f
147.81 48.02 6.40 107.42 re f
154.21 48.02 6.40 214.83 re f
160.61 48.02 6.40 193.35 re f
167.01 48.02 6.40 171.87 re f
173.42 48.02 6.40 150.38 re f
179.82 48.02 6.40 150.38 re f
186.22 48.02 6.40 128.90 re f
192.62 48.02 6.40 85.93 re f
199.02 48.02 6.40 42.97 re f
205.42 48.02 6.40 64.45 re f
211.82 48.02 6.40 21.48 re f
218.23 48.02 6.40 21.48 re f
224.63 48.02 6.40 0.00 re f
231.03 48.02 6.40 0.00 re f
237.43 48.02 6.40 21.48 re f
243.83 48.02 6.40 21.48 re f
250.23 48.02 6.40 0.00 re f
256.64 48.02 6.40 0.00 re f

The 're' operator's four prefix arguments are x, y, w, h in that
order, and it draws a rectangle whose lower left-hand corner is at
(x,y) and upper right-hand corner is at (x+w, y+h). So to get no gap
between bars, the left-hand column should increment by exactly 6.40
each time, but you can see that sometimes it goes up by 6.41 instead.

However, when I correct that manually, I still get visible seams
between all the bars in my PDF reader (evince). So there's more
required. I don't especially want to dig through the PDF spec right
now and figure it out, though.

[Freddie Witherden]

On Nov 14, 12:45 am, Zack Weinberg <za...@panix.com> wrote:
> Part of the problem may be rounding error in the PDF device.  This is
> the portion of the PDF content stream that actually draws the bars:
>

> [snip]

>
> The 're' operator's four prefix arguments are x, y, w, h in that
> order, and it draws a rectangle whose lower left-hand corner is at
> (x,y) and upper right-hand corner is at (x+w, y+h).  So to get no gap
> between bars, the left-hand column should increment by exactly 6.40
> each time, but you can see that sometimes it goes up by 6.41 instead.
>
> However, when I correct that manually, I still get visible seams
> between all the bars in my PDF reader (evince).  So there's more
> required.  I don't especially want to dig through the PDF spec right
> now and figure it out, though.

Have you tried making the bars overlap slightly? Such as by
increasing the width of each rectangle. So long as there is a bit of
overlap my understanding is that there should be no gaps.

Regards, Freddie.

[Winston Chang]

I think the problem may have something to do with either (A) something funny about the antialiasing in the PDF viewer, or (B) the transparent lines Hadley mentioned, or maybe both together.

I took one of the screen shots I previously attached, and zoom way into that bitmap. You can see that there's actually a light border all the way around each of the bars, but the shade of gray isn't constant all the way around the bars, and it differs from bar to bar. (You can also see that the numbers of colored edges because I have subpixel font smoothing turned on.)

I also tried modifying the section that Zack mentioned (after uncompressing the PDF). The original bar width is 6.40, and I tried increasing it to 6.50, and even 7.00, for the first six (or so) bars on the left side. For example:

70.99 48.02 7.00 21.48 re f

77.39 48.02 7.00 21.48 re f

83.79 48.02 7.00 21.48 re f

90.19 48.02 7.00 42.97 re f

96.60 48.02 7.00 42.97 re f

With both 6.50 and 7.00, gaps are still visible in Mac Preview when I zoom way out. However, when I zoom in, the gaps disappear. With 7.00, that's a pretty substantial overlap. I've never noticed this issue in other documents, and I'm guessing that at least some these other documents have used rectangles with edges that go right up to each other, or even overlap slightly. If I'm right about this, then perhaps the different here is the transparent 0.5mm line? Unfortunately, I don't understand the PDF format well enough to remove it.

-Winston

[Joey Harrison]

Freddie,

I am currently struggling with this same problem with lines between the tiles of the geom_tile(). Did you ever find a satisfactory solution?

Thanks,

Joey

[Adriano Fantini]

Have you tried using useDingbats=FALSE?

regards.

--

--
You received this message because you are subscribed to the ggplot2 mailing list.

Please provide a reproducible example: https://github.com/hadley/devtools/wiki/Reproducibility

 
To post: email ggp...@googlegroups.com
To unsubscribe: email ggplot2+u...@googlegroups.com
More options: http://groups.google.com/group/ggplot2

---
You received this message because you are subscribed to the Google Groups "ggplot2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ggplot2+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Kahle]

geom_raster now exists, too.

david.

-------------------------------------------------------------

-------------------------------------------------------------

David J. Kahle, Ph.D.

Assistant Professor

Department of Statistical Science

Baylor University

One Bear Place #97140

Waco, Texas 76798

Office : (254) 710-6102

https://sites.google.com/site/davidkahle/

[Joey Harrison]

Thanks for the response. I just tried setting useDingbats to false and it didn't make any difference.

I also tried geom_raster, and as you can see in the attached image, it comes out blurry. I tried setting to interpolate to true and false and it made no difference. Is there another option that might help?

I'm also attaching the geom_tile version which shows the lines. The irony is that the lines won't appear if you view it in chrome, but they show up in Preview (mac). It's tempting to just blame Preview for the problem, but that doesn't actually solve the problem.

Any other ideas?

Joey

[Joey Harrison]

Ay caramba, the geom_raster version also looks fine in Chrome. All the same, I need a solution that looks right in any PDF viewer.

Joey

[Joey Harrison]

Quick update: Preview has an option in preferences to enable/disable anti-aliasing called "Smooth text and line art". Unchecking this box fixes both the lines within the geom_tile and the blurriness of the geom_raster. However, all the text looks unacceptably jaggy, so I'm still looking for a general solution. 

Rendering to PNG instead of PDF avoids these problems, but introduces other issues with text scaling. The search continues...

Joey

[Crump, Ron]

>Thanks for the response. I just tried setting useDingbats to false and it
>didn't make any difference.

I played with an example from the help file and could get rid of the lines
in the PDF by manually setting the width and height values. I guess I¹m
just creating small overlaps between adjacent tiles.

This is a bit fiddly, but might do as a short term fix. I guess you need
to know the spacing (therefore width/height) of your values. If the tile
width and height are variable then I guess the aesthetic would be set and
provided with a multiplier (e.g. aes(width=w*1.02,height=h*1.02) ), or
something like that.

Ron.

pp <- function (n,r=4) {
x <- seq(-r*pi, r*pi, len=n)
df <- expand.grid(x=x, y=x)
df$r <- sqrt(df$x^2 + df$y^2)
df$z <- cos(df$r^2)*exp(-df$r/6)
df
}
p <- ggplot(pp(20), aes(x=x,y=y))


pdf('junk3.pdf')
p+geom_tile(aes(fill=z),width=1.355,height=1.355)+coord_fixed()
dev.off()

[Joey Harrison]

Ron, 

It took a bit of fiddling, but this actually works! In my case, I have a parameter sweep from 0 to 2 in steps of 0.05, meaning my tiles should also have a width and height of 0.05. Setting width and height to 0.05 creates tiles the exact same size as my original, confirming that the parameters are in the same scale as the chart (and not proportional or something). I had to scale them up to 0.6 before the lines disappeared, which seemed like a lot (20%). It looks good (see first attachment) at that point, but you go much bigger, you start to notice some oversized tiles at the edge (see second attachment).

I hope this gets fixed in Preview (and other PDF viewers, e.g. Skim), but at least we've got a fix for now. Thank you for the workaround!

Best,

Joey