Blend modes

[LenLon]

Hello tmap team,

first: wonderful package, thanks for your hard work.

Now my feature request: Blend modes for tmap layers! Now that R has integrated support for compositing, it would make working with base and tilemaps so much better if we could blend layers instead of having to rely on transparency to make underlying layers visible. Any plans of integrating them into the tmap package soon?

Here's a fellow github of a ggplot2 extension that does just that:
https://mjskay.github.io/ggblend/

Best,
Lennart

[mtennekes]

Thx, great suggestion! Not my highest priority a.t.m. to be honest, but always open to suggestions/PRs. In case it is a low-level blending operation (and also supported by grid) than it should be relatively easy to integrate this in tmap.

[tim-salabim]

@mtennekes please ping me if you implement blending also in interactive mode... Very interested in a viable solution

[philament]

Hi, I just wanted to chime in here to say that I strongly support this feature request. Even only a "multiply" blend would go a long way. This is probably the only reason why I cannot rely on tmap 100% in my work and still have to resort to QGIS sometimes for map making. Blending a high contrast base map such as Stamen Toner with a raster layer looks so much better than simply reducing the transparency of the raster. See below for an example:

[mtennekes]

Not easy, but finally found a tutorial that may help:

https://www.stat.auckland.ac.nz/~paul/Reports/GraphicsEngine/groups/groups.html

I have zero hands-on experience with these kind of operations, so user requirements are more than welcome @LenLon @philament

What kind of arguments would you like in tmap? As I understood from the tutorial (section "Compositing and blend modes") there are 25 blending operations, where multiply is one option. Does it make sense to add an argument called ... (?) to each layer function?

[LenLon]

Same as with transparency which is defined by the alpha = argument, an argument in the layer function called blend = that takes the name of a blend mode and defaults to blend = "normal" when undefined should be all that's required, but happy to have other chime in.

Glad to hear there's something happening on that front! It will greatly level up tmap if implemented :)
Blend modes like "xor" and "difference" can be really useful too if you are looking for differences in Rasters or overlapping polygons, for example.

[mtennekes]

I think we should also distinguish between within-layer blending (e.g. overlapping polygons), and between-layer blending operations.

I have to wait for implementation, because when running the examples from grid.group I get:

Warning message:
Ignored alpha mask (not supported on this device)

Warning message:
In drawDetails.GridGroup(x, recording = FALSE) : Group definition failed

using MacOS

[LenLon]

"Within-layer blending" would be very extra! I have never heard of that kind of blending, and ArcGIS for example doesn't support it at all (see here). How would tmap know which object is "on top" anyway?
I would focus on between-layer blending first, as the user can just plot the same layer twice using different filter() calls for the input data if blending different overlapping objects of the same layer is desired. This also gives more control on which objects to blend and how.

[LenLon]

And you need a case for when someone puts a non-"normal" blend mode for the lowest layer, maybe throw an exception or better assume a white background in any case?

[philament]

Fully agree with @LenLon on the additional "blend" argument.

99% of at least my personal use cases for blending would be covered by something like:
tm_shape(osm_background) + tm_rgb() + tm_shape(myraster) + tm_raster(blend = 'multiply')