Open larspett opened 5 years ago
I could start looking into these, any info at this stage would be great
Please look into it! I will try to answer these questions as best I can quickly, here are quick shots from the hip, let me know if you need more inputs:
Playing around with specific pixel-based resolutions using "integer multiples" of the resolutions of the various layers may produce better results . As you suggest, the dpi and ggplot size (now expressed in inches at some dpi?) may play a big role here and should perhaps be adapted to the TIF resolution (and/or the grid size?) rather than what it is now. Maybe it could even be an integer multiple of both the TIF and the grid resolutions, I guess this in theory should give a pixel perfect result but may result in too high res plots perhaps?).
$ file MapSweden.tif
MapSweden.tif: TIFF image data, little-endian, direntries=17, height=619, bps=8, compression=none, PhotometricIntepretation=RGB Palette, width=307
For that same map, the color ramp used in the legend presently comes from https://github.com/rekonstrukt/swedishbutterflies/blob/master/R/zgeomaps.R#L86-L89 so it is being interpolated using three control points taken from a brewer palette (the idea was to get perceptually distinct shades in a sequential scale). This palette used could be tweaked at around https://github.com/rekonstrukt/swedishbutterflies/blob/master/R/zgeomaps.R#L34-L35 if you want that. Due to the interpolation, five colors will be used and transparent will be used for missing values. Two of those colors will come from interpolation, three will be from the palette and the mid color will be set to map to the mean of the values.
There is no alpha set for that distribution map that I can remember, I don't think it is set further down anywhere. Perhaps the "Over" image_composite operator does something... but I don't think so looking at the docs, and there it also seems that it would respect alpha. So I think the fill can be made using colors that have alpha set - ie some level of transparency, see for example this function for an example of how to add alpha to the colors: https://magesblog.com/post/2013-04-30-how-to-change-alpha-value-of-colours-in/
I have made a set of palettes and helper functions that uses the palette from the report software and the alphas from there too (had missed the alphas, they are 96=59%
If we want to, we could collect all colour specifications into these palettes (maybe we already have something similar). So far I have brought in the map colours (incl transparent, border & red dots), and the histogram etc red and green
Will branch and try these mods
BTW maybe the saved maps look different, I have only looked at the pngs produced by the snippet you sent for checking the map rendering after the bug workaround was implemented. Had a quick look at the save functions but am unsure which one to use for the distribution maps
I am thinking that I can generate a set of palettes that cover all colour uses in the package. Have already done so for some of them and could add the one for the sunhours etc. The question is where (in what file) to put the palette and support functions if/when they are generalised?
Good question, and I think that depending on how much one wants to generalize, there are a few options:
One option is to put it closest to where it would be used primarily, for example: https://github.com/rekonstrukt/swedishbutterflies/blob/master/R/plot.R#L47. This would make sense if there are few or simple palettes and palettes are used mostly elsewhere within functions in that same file.
If there are several palettes are used in several places (across several files such as plot.R, zgeomaps.R and perhaps in separate other places such as vignettes) it may make sense to put the function(s) in a separate file, ie R/palettes.R.
If really widely used, ie across several packages etc, it would make sense to make a package out of them, even, like with the RColorBrewerpackage.
Personally, I think it is nicer to not generalize unless needed, and also not avoid to generalize if that is required. So some kind of balance needs to be struck to not introduce too many new abstraction layers that would perhaps not be needed and that noone has asked for.
In this instance, perhaps putting it in a separate file palette.R would make good sense?
And in the wider community, people seem to be getting used to RColorBrewer so functions could be modelled after that package?
If so a minimum of two functions would be needed in the R/palettes.R file, a function like the RColorBrewer::brewer.pal.info to enumerate all provided palettes and a function like RColorBrewer::brewer.pal(n, name) to return a number of colors from a specific palette.
I guess that the RColorBrewer package does not have the prettiest function names etc so nicer conventions could be used, but on the other hand if people use it so widely they might expect things to work in the same ways when it comes to getting palettes and color info.
The maps have a few minor details that would be nice to tweak: