Point antialiasing
- Dominant language
- Python
- Stars
- 3.6k
- Forks
- 376
- Avg merge
- 4h 32m
- Merged PRs (30d)
- 1
Description
My input data consists of billions of microvectors. Each is so short that it typically starts and ends inside one pixel. The microvectors connect to form a non-linear path (curve?) that extends for many pixels. While these microvectors could be rendered as multiple lines, sent in a single line rendering request, I feel like I will get the best performance by rendering them as points.
The resulting image has aliasing which I feel would best be reduced by giving each point some width. The intensity of the Z value should probably decrease in proportion to the pixel's distance from the point. This is effectively line antialiasing extended (or reduced?) to points.
When you add width to the process of rendering billions of points, parallel processing (multiprocessing, GPU, etc.) is required to get reasonable performance.
@jbednar said:
`Line aliasing is a problem even for billions of points if they are all on the same curve. So I'd want to address open issues with line antialiasing`
This is effectively the problem I have with one gotcha: the billions of microvectors are further divided into millions of curves, ie after, say, a thousand connected micro vectors, there is a "gap" which starts the next "curve". So, for best performance, representing them as points will avoid the cost of start-of-line and end-of-line antialias treatments for each curve. But really I don't know which approach would be faster: billions of antialiased points or millions of antialiased "curves." (I did look at a datashader test case for sending multiple "curves" in a single _line_ request but did not totally grasp the required input structures and never found the associated documentation. And I think the antialiaser divides by zero anyway.)
@jbednar said:
`addressing aliasing for rendering points with a specified size might also address aliasing in lines with a specified width; the problems may in fact be one and the same.`
Yes, there are nuances that make the problems the same and different at the same time. I am happy to explore these nuances in the limited time I have available (which seems to amount to 1-2 hours a week).
I started playing with an override of `Canvas.points`. It needs the scaling from the _canvas_ to calculate antialias interpolation. It reaches into the _canvas_ object to get the scaling parameters. (I guess the `line` antialiasing must do the same: I have not looked.)
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading the Canvas.points override and the existing line antialiasing code, focusing on how canvas scaling parameters are obtained. Review the referenced Datashader test case and its input structures. Done would require an agreed approach for antialiased point widths that handles separated curves and has acceptable performance at billion-point scale.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- data-visualization
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100