Closed tcwilkinson closed 1 year ago
Both look good on my computer, with
I assume it has something to do with your OS & graphics device combination. What happens if you plot directly to pdf or png?
That's certainly possible. Although I see similar effects in the pngs toward the end of the page from the generated html vignettes here: https://r-spatial.github.io/stars/articles/stars5.html
I am on macos, details below.
Direct to png (or pdf) creates similar hairlines when you look closely:
ggsave("cache/test_nc_curv2.png",ggplot() + geom_stars(data=nc.curv) )
## Saving 7.07 x 4.03 in image
Effect more pronounced when output png is smaller...
ggsave("cache/test_nc_curv72.png",ggplot() + geom_stars(data=nc.curv),width=7,height=4,units="in",dpi=72)
Looking further into geom_stars
code, I see that, in these cases, the stars objects are being passed to geom_sf
, so the problem is really there.
The problem is from a hairline gap or line that geom_sf is producing between polygons, also visible in original nc
sf layer, despite selecting colour=NA
and lwd=0
:
ggplot() + geom_sf(data=nc,mapping=aes(fill=AREA),col=NA,lwd=0)
It doesn't cause a problem for these irregular polygons, although perhaps technically wrong, but with many tiny polygons (which the stars object becomes), then you start getting the artefacts.
@edzer Do these lines also appear for you? (i.e. is this platform / graphic dev specific)
No, they do not appear for me.
Although I see similar effects in the pngs toward the end of the page from the generated html vignettes here: https://r-spatial.github.io/stars/articles/stars5.html
That vignette was created by the MacOS GitHub actions runner (broken a.t.m.).
Thanks for checking.
So tha all suggests it is macos graphics device issue then (and not even hidden in geom_sf).
No idea where to chase something like that up! :-( Will look and update this issue if I can find something.
I now suspect that it has something to do with the ragg
graphics engine and its feature of antialiasing fills...
ragg is the only device that provides anti-aliasing of fill, which results in obvious quality differences. The reason for not doing so in cairo is presumably to avoid artefacts when shapes are touching each other where anti-aliasing can result in a thin edge between the two shapes instead of a contiguous colour.
(see https://ragg.r-lib.org/articles/ragg_quality.html#observations )
When I uninstall ragg
, and then use the cairo device (e.g. below), the png has no more hairlines:
ggsave("cache/test_nc_curv_noragg.png",ggplot() + geom_stars(data=nc.curv),type="cairo")
Just to compare, I checked alternative settings on RStudio -> Preferences -> General -> Graphics:
=> Conclusion, ragg
/AGG always antialiases, but this is a problem in case of contiguous polygons which will be very common for plotting stars
objects.
Since ragg
looks set to be widespread because of its cross-platform and text plotting advantages, this is important to sort out, but can only probably be fixed in ragg
itself.
I think this may be related to issues in ragg
:
@edzer Just to be sure, can I check what graphics device you have?
Fantastic. I believe I run cairo, as
> capabilities("cairo")
cairo
TRUE
I didn't test, but maybe it will help? This needs to be added to RMarkdown.
knitr::opts_knit$set(dev.args = list(type = "cairo"))
@kadyb as you can see here (printed at the top) the option is set to cairo
but the raster artefacts remain in subsequent figures.
Another idea is maybe removing the {ragg}
package in workflow?
Edit: With the https://github.com/r-spatial/stars/commit/1fa061e4c25c88653a5b37d652b091442403af22 it seems to work (vignette 2) but macOS is unhappy:
polygon edge not found
https://github.com/tidyverse/ggplot2/issues/2252
.onLoad failed in loadNamespace() for 'Cairo', details:
call: dyn.load(file, DLLpath = DLLpath, ...)
error: unable to load shared object '/Users/runner/work/_temp/Library/Cairo/libs/Cairo.so':
dlopen(/Users/runner/work/_temp/Library/Cairo/libs/Cairo.so, 6): Library not loaded: /opt/X11/lib/libXrender.1.dylib
Referenced from: /Users/runner/work/_temp/Library/Cairo/libs/Cairo.so
Reason: image not found
Probably XQuartz must be installed.
CairoPNG did the job, but there are now new artefacts e.g. the figure in this section. How would you go about remove ragg
?
What I don't understand is why I cannot get the artefacts on my own computer, Ubuntu, with ragg
installed, and the default (png
) knitr driver, but they arise on GA.
How would you go about remove ragg?
run: Rscript -e "remove.packages('ragg')" -e "tic::deploy()"
What I don't understand is why I cannot get the artefacts on my own computer, Ubuntu, with ragg installed, and the default (png) knitr driver, but they arise on GA.
For me locally on Windows and Ubuntu using Cairo the plots look good.
It wasn't the best idea. Now we get this error: there is no package called ‘ragg’
from {pkgdown}
. {ragg}
is required by {pkgdown}
by default. Rather, we should change this in the _pkgdown.yml
configuration file: https://pkgdown.r-lib.org/reference/build_articles.html#figures
Thanks @kadyb and @tcwilkinson ! The advice is to stay away from using ragg::agg_png()
, which is the default in pkgdown.
In https://github.com/r-spatial/stars/commit/2af98c364a0cd0b230f0f8056cd20434a993df3c I added a _pkgdown.yml
file that makes the examples use png()
rather than agg_png()
; in the last example here we still see that that doesn't work everywhere, as
> agg_png("/tmp/x.png")
> dev.capabilities()$rasterImage
[1] NA
where
> png("/tmp/x.png")
> dev.capabilities()$rasterImage
[1] "yes"
Also, the examples there show that png()
has its own challenges...
I'm not sure if this should be seen as a bug or just a necessary result of working with certain forms of translation.
I've noticed that plotting stars objects as sf or as curvilinear can result in some distracting visual artefacts (see examples below). I tried to work around, but have not found fix yet.
Suspect that these artefacts are not universal, can depend on graphics device, and device dimensions etc. etc. and won't be created by all datasets, but still don't like them much(!).
Is this a bug, or necessary result of working with rasters in a certain way (e.g. when transformed or warped)?
If the second, does anyone has good advice on how to avoid/reduce the effects of these, either within stars directly or by wrangling the data/plotting functions?
Some examples taken from the vignette docs (https://r-spatial.github.io/stars/articles/stars5.html), as per version: https://github.com/r-spatial/stars/commit/3c0b627f08516dec2bb11ab850d311abe5ad991d
Here the artifacts involve vertical and horizontal lines, looks like hairline outlines are created by converting each raster cell into polygon, to give a tartan effect. But color=NA and lwd=0 don't seem to help.
Here the artifacts look like circles, but closer in you can see that it looks like rotate hairline border lines or gaps.
Attempting to remove these lines with
color = NA
results in warning (as geom_stars already seems to request this anyway), but changes nothing.lwd=0
(an alternative way of removing polygon borders in ggplot) also has no effect.Just for good measure, it's not just ggplot, you can also see these in base plot, though the effect is different, depending on the size of the output.
It doesn't seem to be a problem with non-translated regular projected raster in base plot though.