LogColorMapper maps to wrong values

Possibly related: #8061 Definitely related: #5020

TL;DR I’m happy to make a PR to use log for the LogColorMapper instead of log1p but wanted to hear opinions first.

As of now, LogTicker and LogTickFormatter seem to work with a simple log(x) transform, whereas LogColorMapper does a log(1+x) transform (log1p), which makes the colorbar map to the wrong values. The documentation does not mention the occurence of log1p at all.

So one of these two options has to be used for both cases.

Scientifically, log1p makes absolutely no sense because it makes the transform depend on the unit of the measurement, but in #5020 the reason given was that small values smaller than 10-ish are “usually below the range of values that log is used for”, which I don’t understand at all.

I get the concern that for 0-values, the log scale will blow up, but that’s a problem of choosing the right transform for your data and should be handled by the user, not by bokeh. One could always add separate Log1pColorMapper, Log1pTickFormatter, etc. or something like it if users really need this behaviour for their dimensionless values.

[bryevdv]

@poplarShift I can’t actually find any evidence that other libraries (Altair/Vegalite, MPL, Plotly) handle zero on log scales, except for MPL’s symlog which I think is generally regarded as bad. So I am inclined now to agree with you that we should just do the simple thing and stop using log1p in the colorbar case, and make it match what the other log scales on axes do. Since that is technically a “breaking change” I will move this to the 2.0 milestone. Just FYI most of the work for 2.0 is already done on the landing-2.0 branch so it should be out a matter of weeks after 1.4 is.

Thanks for your patience with this old issue.

[bryevdv]

@poplarShift If you would like to re-submit that PR against the landing-2.0 branch it would certainly be helpful (or alternatively it could be submitted agains master after 1.4 is released)