Worm Toolbox .xml worm model manipulation

Sample image and/or code

Raw image:
Find the raw image here: CP_issues/20210129-toxin16A-p02-m2X_A09.TIF at 6f3b16c2ac71f11682891b17f28d941f4a769b07 · tcrombie/CP_issues · GitHub

Working example:

  1. Clone the CP_issues repo found here: GitHub - tcrombie/CP_issues: Reproducible CP issues
  2. Open CP_issues/short_worms/short_worm_example.cpproj in CellProfiler-4.0.7
  3. configure input/outputs for your machine and analyze.


  • The example image is from an experiment testing the effect of toxins on C. elegans. The nematodes in the well image are sick due to toxin exposure and some are very small. I made a worm model from small sick worms called MDHD.xml (CP_issues/short_worms/input/MDHD.xml) that can identify the smaller worms in this well. However, occasionally the model identifies worms that are extremely small. For example, the output from the pipeline contains worms with Worm_Length of 2 (CP_issues/short_worms/output/output_data/OverlappingWorms_MDHD.csv).

Analysis goals

I want to measure the lengths of nemtodes in the well. Note, I am not concerned about larger worms being separated into two worms by the MDHD.xml model. I am more interested in removing the very short, fat worms that are clearly not worms but debris in the well. You can see the worm outlines I’m referring to in the output image here in blue: CP_issues/20210129-toxin16A-p02-m2X_A09_overlay.png at 6f3b16c2ac71f11682891b17f28d941f4a769b07 · tcrombie/CP_issues · GitHub


  • I do not understand how the MDHD.xml worm model finds worms of length 2 when min-path-length parameter is set to 31.77 (see MDHD.xml for details).


  1. How should I interpret the worm model parameters in the MDHD.xml file? Specifically how do these parameters influence the minimum length of a worm. The values below are taken directly from my MDHD.xml file.
  1. Does the fact that I made the model with CP3.1.9 affect how it is run with CP4.0.7?

Hmmm, I’m not certain how to interpret the parameters; naively, I would think you are correct that the minimum path length and/or area would preclude such a small object, but I don’t recall the underlying code well enough to be certain.

  1. My first couple of ideas for fixes (none of them mutually exclusive) would just be to a) use an Opening module on your binary image before you run UntangleWorms to remove small spots b) use FilterObjects to remove small crud like that you don’t like after Untangling c) if it isn’t too painful, redo your training and make sure you don’t accidentally have some small worms in your training set that are somehow leading to them ending up being selected downstream.
  2. It shouldn’t affect the Untangling per se, we did not make any major changes to that module in my recollection (or that are recorded in the release post), but it might affect your thresholding.

Thanks @bcimini!

  • Q1 Fix idea A: I’ve tried tinkering with the diameter range for objects added to the binary image. Trouble is, I have small thin worms with an equivalent diameter similar to the crud in the wells.

  • Q1 Fix idea B: I like it! I might use ClassifyObjects to retain the small crud-like worms too so I can step through a size threshold that works best.

  • Q1 Fix idea C: I don’t like it! lol. Making worm models is painful. Although you’re right, it should help.

  • Q2: OK, thanks. I did notice that thresholding is slightly different between 3 and 4, but I don’t think it will affect the model performance. I suppose I could test by running the same model in CP3 and CP4.

Anyone else have experience with how the parameters in the worm models can be manipulated to prevent super short worms?

Ha, don’t blame you for not wanting to retrain, just is TECHNICALLY an option. If you were lucky and had a model that had trained easily in half an hour or so, it might have been worth it; not so much otherwise.

I’ll see if I can dig into the code more later this week.

1 Like