Package qupath.imagej.detect.cells

Class WatershedCellDetection

java.lang.Object
qupath.lib.plugins.AbstractPlugin<BufferedImage>
qupath.lib.plugins.AbstractInteractivePlugin<BufferedImage>
qupath.lib.plugins.AbstractDetectionPlugin<BufferedImage>
qupath.lib.plugins.AbstractTileableDetectionPlugin<BufferedImage>
qupath.imagej.detect.cells.WatershedCellDetection
All Implemented Interfaces:
PathInteractivePlugin<BufferedImage>, PathPlugin<BufferedImage>
Direct Known Subclasses:
PositiveCellDetection
public class WatershedCellDetection extends AbstractTileableDetectionPlugin<BufferedImage>
Default command for cell detection within QuPath, assuming either a nuclear or cytoplasmic staining.

To automatically classify cells as positive or negative along with detection, see PositiveCellDetection.

To quantify membranous staining see WatershedCellMembraneDetection.

Author:
Pete Bankhead

  • Field Details

    • parametersInitialized

      protected boolean parametersInitialized

  • Constructor Details

    • WatershedCellDetection

      public WatershedCellDetection()

  • Method Details

    • setDebugMode

      public static void setDebugMode(boolean debug)
      Set whether to use debug mode. If this is on, images will be shown during processing to visualize how the algorithm is working at each stage.
      Parameters:
      debug -
      See Also:

    • getDebugMode

      public static boolean getDebugMode()
      Get whether debug mode is on or off.
      Returns:
      See Also:

    • parseArgument

      protected boolean parseArgument(ImageData<BufferedImage> imageData, String arg)
      Description copied from class: AbstractPlugin
      Parse the input argument, returning 'true' if the argument is valid and it's possible to run the plugin.

      This is called from within runPlugin. If it returns 'true', getTasks will be called and then runTasks will submit these to the plugin runner to run. If it returns 'false', runPlugin will immediately abort and return false as well. Since this could result in some internal variables changed (e.g. a ParameterList), implementing classes can't be assumed to be thread-safe; plugins should be created and called from a single thread, although they may use multiple threads (via a PluginRunner) to complete their tasks.

      Overrides:
      parseArgument in class AbstractInteractivePlugin<BufferedImage>
      Parameters:
      imageData -
      arg -
      Returns:

    • getDefaultParameterList

      public ParameterList getDefaultParameterList(ImageData<BufferedImage> imageData)
      Description copied from class: AbstractInteractivePlugin
      This should return a default ParameterList containing any information that is needed to repeat the task exactly.
      Specified by:
      getDefaultParameterList in interface PathInteractivePlugin<BufferedImage>
      Specified by:
      getDefaultParameterList in class AbstractInteractivePlugin<BufferedImage>
      Parameters:
      imageData -
      Returns:

    • getName

      public String getName()
      Description copied from interface: PathPlugin
      Get the name of the plugin for display.

      This should be descriptive and, above all, short - as it may be used for menu item names & dialog box titles.

      Returns:

    • getLastResultsDescription

      public String getLastResultsDescription()
      Description copied from interface: PathPlugin
      (Optional) short one-line description of the results, e.g. to say how many objects detected. GUIs may choose to display this on a label during interactive processing.
      Returns:

    • getDescription

      public String getDescription()
      Description copied from interface: PathPlugin
      Get a brief description of the plugin's purpose & operation.

      If no description is provided, this may return null.

      Returns:

    • getPreferredPixelSizeMicrons

      protected double getPreferredPixelSizeMicrons(ImageData<BufferedImage> imageData, ParameterList params)
      Description copied from class: AbstractTileableDetectionPlugin
      Get the preferred pixel size that would be used for the specified ImageData and ParameterList.

      This is useful in deciding whether to break large regions into smaller, parallelizable tiles.

      Specified by:
      getPreferredPixelSizeMicrons in class AbstractTileableDetectionPlugin<BufferedImage>
      Parameters:
      imageData -
      params -
      Returns:

    • createDetector

      protected ObjectDetector<BufferedImage> createDetector(ImageData<BufferedImage> imageData, ParameterList params)
      Description copied from class: AbstractTileableDetectionPlugin
      Create a new ObjectDetector, compatible with the specified ImageData and ParameterList.
      Specified by:
      createDetector in class AbstractTileableDetectionPlugin<BufferedImage>
      Parameters:
      imageData -
      params -
      Returns:

    • getTileOverlap

      protected int getTileOverlap(ImageData<BufferedImage> imageData, ParameterList params)
      Description copied from class: AbstractTileableDetectionPlugin
      Get an appropriate overlap, in pixels, if analysis of the specified ImageData will be tiled.

      If the overlap is 0, then tile boundaries are likely to be visible in the results.

      If the overlap is > 0, then the overlap should also be > the expected largest size of a detected object - otherwise objects may be lost of trimmed when overlaps are resolved. This is because (currently) the resolution of overlapping detections involves taking the largest one, rather than (for example) merging them.

      (Merging may be permitted in later versions, but only where measurements are not made by the plugin - since merged objects may require different measurements, e.g. for area or mean than can be easily computed in a general way from the individual objects being merged).

      Specified by:
      getTileOverlap in class AbstractTileableDetectionPlugin<BufferedImage>
      Parameters:
      imageData -
      params -
      Returns:
      The overlap size in pixels, or 0 if overlapped tiles are not supported.