Additional fixes for colorize span

[jbednar]

So far just comments, but I think there also should be handling for min_alpha in the case where the span includes no values.

[philippjfr]

I think there also should be handling for min_alpha in the case where the span includes no values.

I think I disagree here, the current behavior is consistent with the way it has always worked in the non-categorical case and how other plotting libraries treat color limits. Anything below the lower bound should be assigned the min_alpha value.

[jbednar]

I think I disagree here, the current behavior is consistent with the way it has always worked in the non-categorical case and how other plotting libraries treat color limits. Anything below the lower bound should be assigned the min_alpha value

I've added examples of using min_alpha together with span, and I think you're right; it seems to behave consistently. It would be great if you could look over the new examples (in the new section "2_Pipeline.ipynb#Controlling-ranges-for-colormapping") and see if you think the behavior is as you'd expect.

There are also a few open issues remaining from recent PRs/issues:

• @philippjfr: _interpolate "if np.issubdtype(data.dtype, np.integer): mask = data == 0" -- This does not appear valid for sum or other non-count aggregates to me, why should zero values be masked out in this case? Now that we use uints for count aggregates I think zero should be handled just like any other value for regular integer types.

• @jbednar: I think I agree, though note that we will then no longer be able to mask out pixels with no data in them, for integer aggregates other than count. I do think that's safer, on balance, though. I tried changing that line to test "if data.dtype.kind == 'u':" instead, but saw no difference.

• Need examples of non-count by aggregates

• Need examples and possible fix for Problems with _colorize() #899 using negative aggregate values

[jbednar]

Ok, Philipp and I had a productive debugging session where we really tried to pin down where things were behaving differently between _interpolate and _colorize, between sum and mean, and between sum/mean and count. We found a variety of issues due to the categorical code never previously having supported floats or nans, and we think we managed to address all those. The behavior now looks good for aggregating sums and means of positive values, which is now illustrated in new examples in 2_Pipeline.ipynb. The behavior for aggregating non-categorical negative values also looks good, again illustrated with new examples showing what I consider to be appropriate ways to work with aggregations of positive and negative values.

• The last remaining known issue with these changes is to validate or improve the behavior for aggregating positive and negative values categorically. I added a new example that illustrates what it currently does, but I'll have to think about what it should do in that case, and then we can finally merge this.
• Well, after adding some tests corresponding to the new cases added to 2_Pipeline.ipynb.

[jbednar]

Discussion for the zero and negative case is at #899 (comment); short answer is yes, it is broken.

[jbednar]

I've now changed _colorize to subtract the minimum value from the data by default before calculating colors, which now lets it work with negative values and seems to have essentially no impact on the typical cases that previously worked, i.e. counts, since those nearly always have a pixel with 0 anyway, so that using the minimum is the same as the previous default of using 0.

I also added special handling for computing a color for pixels that are zero (after subtracting the baseline), which previously was causing some pixels to end up black. Now they instead are colored with the average color of the categories present (albeit at zero strength) in that pixel, which allows us to avoid ever having undefined colors.

I added new examples to 2_Pipeline.ipynb and documented the color_baseline argument, so I think it's ready to go once the tests pass (and new tests are added!).