Closed veggiesaurus closed 3 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
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.
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.
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.
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.
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:
(it might not be feasible to do a nearest-point check often, when you have tens of thousands of points to go through)
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... ?
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.
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?
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.
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
I think we can close this in favour of @panchyo0's use of plotly's scattergl
feature.
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.