CARTAvis / carta-frontend

Source code repository for the frontend component of CARTA, a new visualization tool designed for the ALMA, the VLA and the SKA pathfinders.
https://cartavis.github.io/
GNU General Public License v3.0
20 stars 10 forks source link

WebGL rendering of catalog points #814

Closed veggiesaurus closed 3 years ago

veggiesaurus commented 4 years ago

Rather than using Konva, we should use WebGL to render catalog points.

We can do this by generating shapes and lines from the individual catalog points, and storing them in a vertex buffer, in a similar process to the contour generation.

More details are needed on what types of shapes need to be rendered, and whether the line thickness needs to be adjusted, or whether single-pixel lines can be used.

veggiesaurus commented 4 years ago

My suggestion is to provide a simple list of symbol shapes, similar to that of DS9:

I think it's important to be able to edit the line width, especially for HiDPI screens. I also think it's important to be able to assign a different symbol shape, color and size to each point, based on a column or criteria

kswang1029 commented 4 years ago

we probably can apply some rotations to these symbol shapes like the attached image. For closed shape, we can set it as filled or not.

Screen Shot 2020-03-04 at 6 28 10 PM
arusstaylor commented 4 years ago

This seems a good comprehensive set of symbols. I can't imaging a use case where we want use filled versions. Colour and size and line thickness I think would be the attributes that we want to be able to set. There should be a "highlight" mode for each when for example selecting an object in the catalogue table highlights the symbol for that object on the image. Should probably be an action that draws the eye like blinking.

veggiesaurus commented 4 years ago

Should probably be an action that draws the eye like blinking. Yes, this is a very useful feature of DS9, along with automatically centering on a point.

I don't think we should aim for the reverse (clicking on a point on the image view to highlight a point in the catalog), because the catalog overlay could be tens of thousands of points, and interacting with that many points is tricky.

arusstaylor commented 4 years ago

So is the issue capturing a click associated with a symbol in the image when the density of symbols is high? I have been thinking that it would be good have something like a little popup that displayed metadata from the table for a symbol when selected.

veggiesaurus commented 4 years ago

So is the issue capturing a click associated with a symbol in the image when the density of symbols is high? I have been thinking that it would be good have something like a little popup that displayed metadata from the table for a symbol when selected.

There are a few issues:

  1. This would require us to also render a hit graph for the catalogs. Not too hard to do, but will make the render process a bit more expensive
  2. Selecting a symbol on the image view would then interfere with the ability to select regions, or to pan/zoom

(it might not be feasible to do a nearest-point check often, when you have tens of thousands of points to go through)

arusstaylor commented 4 years ago

I think issue 2 is generic and not specific to this application. When one has nested graphic on an image, symbols, regions and potentially other annotations, how does one not what the intention of a click is re selection. I think probably the best approach is to be context sensitive. If the region widget is the current "active" widget select regions. If the catalogue viewer then select the symbol, etc... ?

veggiesaurus commented 4 years ago

I think issue 2 is generic and not specific to this application. When one has nested graphic on an image, symbols, regions and potentially other annotations, how does one not what the intention of a click is re selection. I think probably the best approach is to be context sensitive. If the region widget is the current "active" widget select regions. If the catalogue viewer then select the symbol, etc... ?

That could work. If the catalog dialog is open, we allow a selection of catalog points. If not, we only allow regions. That's a bit outside of the scope of this issue, so perhaps we should make another issue to discuss it.

arusstaylor commented 4 years ago

I think not just that the catalogue dialog is open, but that the catalogue dialog has current focus. So that you dont have to close the catalogue dialog to switch to regions focus. Do we have the concept of focus with the widget windows?

veggiesaurus commented 4 years ago

I think not just that the catalogue dialog is open, but that the catalogue dialog has current focus. So that you dont have to close the catalogue dialog to switch to regions focus. Do we have the concept of focus with the widget windows?

For undocked widgets, yes, but not for docket widgets.

veggiesaurus commented 4 years ago

I've implemented a native canvas rendering approach as a test (much simpler and more flexible than WebGL) in PR #816, but it looks to be limited to around 10K - 20K points, depending on the user's definition of "acceptable" performance. Branch angus/test_canvas_rendering (and backend branch mark/catalog) on mix 'n match

Note, the number of points increases considerably if a simpler shape (e.g. a rectangle) is used, rather than a circle

veggiesaurus commented 4 years ago

I think we can close this in favour of @panchyo0's use of plotly's scattergl feature.