added clustering and dimensionality reduction to NAP6 menus

[jo-mueller]

trafficstars

Ok, this will put the widgets (plotter, dim. reduction & clustering) into the contributable menus section. The Plotter itself was there before, but this brings the dim. reductoon and the clustering, too. In 0.9.0, they will then be found here:

• Plotter: Layers > Visualize > Plot & select features (napari clusters plotter)
• Dim. reduction Layers > Project > Dimensionality reduction on features (napari clusters plotter)
• Clustering: Layers > Classify > Clustering on features (napari clusters plotter)

@jni since you were asking about this on bsky the other day I'd guess I'd ping you, too as an additional pair of eyes ;) Do you think that'd be the appropriate place to put these?

Long copilot description

This pull request updates the napari.yaml configuration for the napari_clusters_plotter plugin to reorganize menus, enhance clarity in widget display names, and remove unused submenus. Below are the key changes:

Menu Reorganization:

• Added new menu entries under napari/layers/project and napari/layers/classify for Dimensionality_Reduction and Clustering commands, respectively.
• Removed the features_submenu and its associated entries to simplify the menu structure.

Widget Display Name Updates:

• Updated widget display names for better clarity:
  • Changed "Clusters Plotter" to "Plot & select features."
  • Changed "Dimensionality Reduction" to "Dimensionality reduction on features."
  • Changed "Clustering" to "Clustering on features."

[jni]

I think they make sense! I'm not clear on the plugin functionality though. The only one I vaguely question is:

Dim. reduction Layers > Project > Dimensionality reduction on features (napari clusters plotter)

This is not reducing the layer data, but rather, features on the layer, right? So I might consider it more appropriate in Measure (from NAP-6: "Items in this submenu provide utilities for summarising information about your layer’s data. An example would be a widget that plots the change in the intensity of a clicked pixel over time") rather than Project ("Commands that generate various projections based on one or more layers"), which I interpret more as MIP or similar.

Having said that all classification systems are lossy and imperfect, so this is a judgement call, and both choices can be defended. 🤷

[jo-mueller]

Hi @jni , thanks for the feedback! I could agree with moving dimensionality reduction (which operates entirely on features and as such, measurements) to the measure section. @zoccoler @stefanhahmann would you also agree with that?

[stefanhahmann]

Hi @jni , thanks for the feedback! I could agree with moving dimensionality reduction (which operates entirely on features and as such, measurements) to the measure section. @zoccoler @stefanhahmann would you also agree with that?

Difficult decision. Reading through the descriptions for the menus and assuming the possibility, I could split my vote, I would do the following:

• 50% Project
• 40% Measure (we are not actually measuring something with dim. red.)
• 10% Data (We do something with the data, but the description suggests things more like image data format conversion in this category)

I am actually missing a category called "Analyse".

[jni]

I am actually missing a category called "Analyse".

As the NAP itself instructs, this could be proposed by raising an issue on the napari repo!

I feel like Analyse itself is too broad — measurement is a form of analysis, for example, and maybe segmentation could be argued to also be a form of analysis — but we could consider it (maybe it subsumes measure). At any rate, it would be good to have this specific use case on our radar, so if we come across something similar we can be like ah-ha — these two things need to be grouped together, what should we call the group.

[jo-mueller]

As discussed with @zoccoler yesterday, both of us were fine with @jni's suggestion. With the introduction of the searchable menus this will be much easier to find, anyway :)

[jni]

Incidentally, we've been discussing this internally and we're thinking about adding Layer > Features for functionality related to features, which this could fit into rather well. Thoughts?

[jo-mueller]

@jni Is there an issue to join the discussion? Just above, I think it's possible to live with or without. Even currently, the existing options do not account for whether a plugin should operate on Images/Labels/Surfaces/Features. If there were a new submenu Layer > Features, then the new question would be whether the Clusters Plotter Widget, for instance, should go under Layer > Visualize > Plot Features or Layer > Features > Plot Features. I guess adding a Features submenu would break the current paradigm of entries not being ordered by the layer type they operate on.

That being said, I'd slightly lean towards not opening the second entry Layer > Features to keep it clear that the current structure is not ordered by layer or data type. Maybe it could be a convention that entries in the Layer menus are named like name of the functionality (data operated on) (plugin of origin). For instance, I renamed the clustering and dim. reduction to display as Dimensionality reduction (features) (napari clusters plotter).

Maybe it'd be possible to display a little icon next to the entry in the Layer menus that indicates on what kind of data it operates (e.g., Image, Label, Features, etc)?

[jni]

Is there an issue to join the discussion?

Sorry, not at the moment — I started it in the core dev chat with an offhand link to this discussion. 😬 I just went over it and there's nothing sensitive there, so once I get folks' permissions I'll move it to the general channel on the Zulip.

But anyway, my main point is, NAP-6 is a new thing, we're still figuring it out, and we super appreciate community input and want to make sure you all have a good experience with it! 😊 So please don't hesitate to reach out. For now I will make an issue about Layer > Features and link to this discussion. 🙏

[jni]

napari/napari#7900

[jni]

I just went over it and there's nothing sensitive there, so once I get folks' permissions I'll move it to the general channel on the Zulip.

This is done now: https://napari.zulipchat.com/#narrow/channel/212875-general/topic/NAP-6.20pigeonholes/near/516142145

although mostly the relevant discussion is happening in napari/napari#7900 now.