-
-
Notifications
You must be signed in to change notification settings - Fork 366
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Additional fixes for colorize span #910
Conversation
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 |
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:
|
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.
|
Discussion for the zero and negative case is at #899 (comment); short answer is yes, it is broken. |
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 |
… nan issues in colorize
So far just comments, but I think there also should be handling for min_alpha in the case where the span includes no values.