-
-
Notifications
You must be signed in to change notification settings - Fork 419
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
graph layer #5861
base: main
Are you sure you want to change the base?
graph layer #5861
Conversation
I definitely support renaming Making numba optional for napari-graph is certainly an effective solution, but my concern is that it might be hard for people to discover that numba is needed in the situation where they use a library that depends on napari-graph but does not depend on napari-graph itself. |
@Czaki suggests the possibility of adding a button to create an empty graph (because you can interactively build a graph) Also suggested, since |
Warnings are pretty noisy in napari thanks to that CPython |
…er (#6402) # References and relevant issues This is a follow up to #6288 and predecessor to #5861 and was originally discussed at the hackathon (cc @DragaDoncila, @jni). # Description This PR migrates all `edge_*` attributes and references on points layer to use `border_*`, so that there is no confusion between graph edges and other lines depicting the border of an object. Even if #5861 changes in terms of implementation etc., **any** graph layer we implement will likely require this change, so it's being split out from #5861 (also to aid in review). ## TODO: Please see [this issue ](#6541 a discussion regarding refactoring other layer types (shapes, vectors,..) --------- Co-authored-by: Jordao Bragantini <jordao.bragantini@czbiohub.org> Co-authored-by: Jordão Bragantini <jordao.bragantini@gmail.com> Co-authored-by: Draga Doncila Pop <17995243+DragaDoncila@users.noreply.github.com> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Lorenzo Gaifas <brisvag@gmail.com> Co-authored-by: Peter Sobolewski <76622105+psobolewskiPhD@users.noreply.github.com> Co-authored-by: Grzegorz Bokota <bokota+github@gmail.com>
Can we verify this very related issue while closing this PR, please: #2260 |
@cmalinmayor, i ran into this old issue. it is kinda related to the edge highlighting we're working on: #2560 and @quantumjot would probably be happy to see something like this for edges in cell tracking graphs |
for more information, see https://pre-commit.ci
…into napari-graph-2023
@@ -136,6 +137,9 @@ def _on_highlight_change(self): | |||
pos = self.layer._highlight_box | |||
width = scaled_highlight | |||
|
|||
# FIXME: vispy bug? LineVisual error when going from 2d to 3d (or the opposite) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JoOkuma I'm going through to split up points changes into their own PR - is this line part of a bad merge or did you add this? If you added it, can you expand a bit more what the bug is? Maybe this should be its own tiny PR
This will be needed for the VispyGraphLayer
fix VispyGraphLayer _subvisuals error
Description
This PR implements a graph layer for napari using the napari-graph.
Currently, it only supports operations at the node level (e.g., insertion, movement, removal) inherited from the points layer.
This should solve multiple open issues:
Simple example using nuclei centroids:
napari-graph-nuclei-demo.mp4
Example of performance with 1 million nodes over four dimensions with out-of-slice display:
napari-graph-1mi-nodes.mp4
TODO Before Merge
Update docs:
Before doing this, I would like others' opinions over renaming
edge_colors
and otheredge_
related attributes tonode_contour_
(or something else, open to feedback) to avoid confusion withedge
from the graph. Currently, it has the same nomenclature as the points layer.Update
napari-graph
readme and provide examples on its repo.Add
napari-graph
to pypi and condaDecide if
napari-graph
will be an optional dependency, it depends onnumba
, which imposes some constraints onnumpy
version, @Czaki suggestion was to makenumba
optional tonapari-graph
, which could work, but it would be super slow because it uses a lot offor
loops.References
The issues mentioned above and napari-graph.
Type of change
How has this been tested?
Final checklist:
trans.
to make them localizable.For more information see our translations guide.
cc @andy-sweet @jni @jwindhager