You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Possible improvement (again copied from PR #1146):
There is no workaround for this, it would need a more complicated implementation as we don't store the information required to do this. We would need to separate out the antialias weighting (what would conventionally be called the alpha but trying not to use that term here) from the normal aggregate numbers. For the count of a single line segment the count agg would be 1 for every pixel in the line right up to the edges, and the weighting would be 1 along the middle of the line, down to just about 0 at the extreme edges. The 2D agg returned to the user would be the product of the two, giving the same number as we currently return (for a single line).
For a compound reduction of a count and sum we can imaging 3 aggs, count, sum and weighting. For the count we'd return count*weighting to the user, for the sum we'd return sum*weighting, and for the mean we'd return (sum/count)*weighing, giving you exactly what you want.
In general, we couldn't just have a single weighting per canvas.line call, we'd need a weighing per agg. So maybe we'd think of changing each of the current agg's shapes from (height, width) to (height, width, 2), so the agg is attached to its weighting.
We would need to decide on appropriate mathematics to combine say (value1, weighting1) with (value2, weighting2) for a particular pixel. Let's assume we want a linear combination, so the combined value must be value1*weighting1 + value2*weighting2. Or is it? It might be more sensible to say we want the combined value and weighting so that value*weighting = value1*weighting1 + value2*weighting2 because the value needs to be stored unweighted (the whole purpose of this approach is to keep the weighting separate from the value). This maths is not dissimilar to combined rendering of RGB and A separately, but there we have the concept of rendering on top of existing colors in a non-commutative way. So it is more complicated than that!
In summary, to obtain a mean that more in line with what is expected would require:
Twice as much memory for the 3D aggs.
Slightly more complicated code, but only at the very highest and lowest levels as we'd still be scanning the source dataframe just once, only with 3D aggs.
Thought about appropriate maths to combine values and weights (which may or may not exist)
The text was updated successfully, but these errors were encountered:
It might be possible to implement the 3 agg approach just for mean reductions. This could be a good test to see how easy it is to implement and to identify drawbacks.
The current state of antialiased lines with various reductions was summaries in PR #1146. Test code and images are reproduced here:
Possible improvement (again copied from PR #1146):
There is no workaround for this, it would need a more complicated implementation as we don't store the information required to do this. We would need to separate out the antialias
weighting
(what would conventionally be called thealpha
but trying not to use that term here) from the normal aggregate numbers. For thecount
of a single line segment thecount
agg would be 1 for every pixel in the line right up to the edges, and theweighting
would be 1 along the middle of the line, down to just about 0 at the extreme edges. The 2D agg returned to the user would be the product of the two, giving the same number as we currently return (for a single line).For a compound reduction of a
count
andsum
we can imaging 3 aggs,count
,sum
andweighting
. For thecount
we'd returncount*weighting
to the user, for thesum
we'd returnsum*weighting
, and for themean
we'd return(sum/count)*weighing
, giving you exactly what you want.In general, we couldn't just have a single
weighting
percanvas.line
call, we'd need aweighing
per agg. So maybe we'd think of changing each of the current agg's shapes from(height, width)
to(height, width, 2)
, so the agg is attached to its weighting.We would need to decide on appropriate mathematics to combine say
(value1, weighting1)
with(value2, weighting2)
for a particular pixel. Let's assume we want a linear combination, so the combined value must bevalue1*weighting1 + value2*weighting2
. Or is it? It might be more sensible to say we want the combinedvalue
andweighting
so thatvalue*weighting = value1*weighting1 + value2*weighting2
because thevalue
needs to be stored unweighted (the whole purpose of this approach is to keep theweighting
separate from thevalue
). This maths is not dissimilar to combined rendering of RGB and A separately, but there we have the concept of rendering on top of existing colors in a non-commutative way. So it is more complicated than that!In summary, to obtain a mean that more in line with what is expected would require:
The text was updated successfully, but these errors were encountered: