Rename Object Classification submenu to Detection Classification

[andmccall]

Since it seems (from what I can tell) that all the commands within this menu work only on detections and not annotations, the submenu should be called Detection classification, so as not to give the impression that they work on annotations.

[petebankhead]

The reason I chose the more general 'Object classification' is thinking about the future. Even though the existing commends mostly focus on object classification for detections only, future commands might not be. And extensions might add commands to classify in a different way.

For example, here's a script that adds a basic command to classify annotations based on the shape of the ROI:

import javafx.application.Platform
import javafx.scene.control.MenuItem
import qupath.lib.gui.QuPathGUI
import qupath.lib.gui.dialogs.Dialogs
import qupath.lib.objects.PathObject
import qupath.lib.objects.classes.PathClass

commandName = "Classify annotations"

Platform.runLater {
    installCommand()
    Dialogs.showInfoNotification(commandName, "Command installed!")
}


def installCommand() {
    def menu = QuPathGUI.getInstance().getMenu("Classify > Object classification", false)
    def mi = menu.getItems()
            .stream()
            .filter(m -> commandName.equals(m.getText()))
       .findAny().orElse(null)
    if (mi == null) {
        mi = new MenuItem(commandName)
        menu.getItems().add(mi)
    }
    mi.setOnAction {e -> classifyAnnotations()}
}

def classifyAnnotations() {
    def imageData = QuPathGUI.getInstance().getImageData()
    def annotations = imageData == null ? [] : imageData.getHierarchy().getAnnotationObjects()
    if (annotations.isEmpty()) {
        Dialogs.showWarningNotification("Classify annotations", "No annotations found!")
        return
    }
    for (def annotation in annotations)
        classifySingleAnnotation(annotation)
    imageData.getHierarchy().fireObjectClassificationsChangedEvent(this, annotations)
}

def classifySingleAnnotation(PathObject pathObject) {
    def roiName = pathObject.getROI()?.getRoiName()
    pathObject.setPathClass(PathClass.getInstance(roiName))
}

I think it makes sense for such classifiers to be added to a single Object classification submenu, rather than split between Detection and Annotation (also, there might one day be a need to classify TMA cores, which don't fit into either category).

Also, the top of the Train object classifier dialog makes it possible to select different types of objects to classify.

Admittedly, these are all detections or subtypes of detection... but that's because I couldn't think of a good workflow to use them for annotations (since you're using annotations to train the classifier, how should QuPath distinguish between which annotations are for training and which should be classified...?). The internal representation of the object classifier is capable of specifying the type of object it should be applied to, even though we have no easy way to interactively create annotation classifiers through the user interface, or examples where that is actually used.

Perhaps more usefully, we plan to enable the use of deep learning models for classification - and these don't have the complication of needing annotations for training. Much of the code to enable this has already been written, but we need to figure out how best to link it up to the user interface and provide meaningful models for the feature to be useful. When it is useful, I expect it to become very useful.

QuPath's best features probably don't exist yet, but we try to design the software thinking far enough into the future so that they can be added...

For that reason, if the fact that most commands under Object classification currently only work for detections is confusing, I think we need some other way to resolve that confusion.

[andmccall]

(since you're using annotations to train the classifier, how should QuPath distinguish between which annotations are for training and which should be classified...?)

I'm not actually, sadly I don't get the chance to work in QuPath much as I mostly work with 3D images. This came about because of this post: https://forum.image.sc/t/using-annotations-imported-into-qupath/95333

It seems the user imported ROIs as annotations instead of detections. Ultimately probably more of a user error based on the current design of the system, but I just do feel it is confusing that everything is given the generic label of "object" (both the submenu and the filter) when it only works on detections. Perhaps another submenu within the Object classification menu specifically for Detection classification commands? I know that currently that would mean a single submenu item in the Object classification menu, but it would add clarity to the current state of things, and I would imagine that at least some of these commands will be restricted to detections only well into the future.

[petebankhead]

I feel that is likely to cause more confusing and maintenance headaches as the software develops, mostly for the reasons I outlined above. Commands will change and improve. The same command (e.g. Load object classifier) might meaningfully only work for detections now, but handle other object types in the future (I think that, in principle, it already does support other object types, if you can somehow create and save a classifier that applies to annotations).

There had been a Train detection classifier in earlier versions, so the renaming in that case was to reduce confusion because there was a transition period during which both commands were maintained in parallel.

If we move things, we need to update the documentation - and some of the docs are in the form of videos, so that's not straightforward.

And if we push the term 'detection classifier' it will likely confuse someone who thinks it isn't relevant to them because they have cells, not detections.

I don't think the current arrangement is ideal, but we are always trying to balance the current software with the past, the future, the docs, and a large number of users with very different needs and expectations... and a very small number of developers. Added to that are the people who write extensions, for whom changing menu structures can cause trouble. It is not an easy project to manage.