TrackObjects doesn't record labels properly in .mat/.csv

Hi all,
I’m having trouble with the TrackObjects module- while it seems to be tracking and naming the objects correctly when I look at the labeled images (frames 1&2 from a sample movie attached- notice that for example 3&5 are conserved from frame 1 to frame 2 and the highest visible number (79) is the same as the number of objects), when I look at the .mat and .csv outputs those numbers don’t match up at all with the image outputs (for example, the highest value is 52) and multiple objects are given the same label!

I’ve attached the pipeline, the .mat output, and the first 2 frames of the TrackObjects graphic output- the original movie is too large to attach(61Mb@16 bit) so I’ve given you the first 10 frames@8bit. Thanks so much!

DefaultOUT__1.mat (1.57 MB)

_pseudofinal_ColocalizationTelomereTracking.cp (14.7 KB)

Any thoughts or workarounds guys? I’m also glad to give you more info.

I had this issue running 10997(Windows, don’t remember if I installed it as 32 or 64-bit) and 11086 32bit, but I re-installed version 10415 (32bit) and now it works fine. Something between 10415 and 10997 then…


Don’t worry, we haven’t forgotten! Thanks for adding the version information; that will definitely help narrow things down. However, it will take a bit of time for us to address the problem since TrackObjects is one of our more complicated modules. We’ll post here when we have an answer, but we hope that your work isn’t hobbled too much by using 10415 in the meantime.


Thanks so much- I tried last night to look through the versions of the modules and spot the error, but as you pointed out, it’s waaaaaaaaay too complex for a novice programmer like myself. In the meantime, 10415 does a pretty good job.
Appreciate it as always!

The newest version of TrackObjects uses a Kalman filter to try and predict trajectories, so perhaps this increases the likelihood of splits (one telomere in a previous being assigned as the parent to two telomeres in the child) and merges. The previous version assigned the label numbers on pass 1 of the LAP method. It now does a reassignment on pass 2 which is the stage that performs the merges and splits which is why you are getting duplicates. Unfortunately, there are two possible ways we could have assigned labels in the case of a split: both daughters could get the same label as their mutual parent and both daughters could get labels different from their parent. We chose to give both daughters the same label as their parent. Perhaps the best approach to analyzing the data would be to use TrackObjects_ParentGroupIndex and TrackObjects_ParentObjectNumber to track each telomere from frame to frame instead of relying on the label. Each image set in a movie has the same group number and successive image sets have successive group indices. The group index number for an image set is available in the image measurements for that image set.

I adjusted the pipeline a little to greatly favor new telomere creation over splitting. If you want to track one telomere through multiple frames without merge or split, you should set the merge alternative cost and split alternative cost in TrackObjects to 1; this will give the alternative options to splitting a much lower score than the cost of splitting and same for merges.

Hope this helps,

–Lee Kamentsky

Thanks, that does explain a lot- could you post the new pipeline please? I’d love to play around with it.
Perhaps in the next build you could allow the user to pick which of the two labeling schemes they want to use? Since the labels appended to the image output still use the old scheme, it seems like the information should still be there.
Thanks again.

Zombie Thread!

My project had moved away from tracking for a couple of years, hence me not posting here as much*. I’m getting back into looking at tracking, however, and in trying to revisit this question (about how to handle splits and merges when I’m trying to reconstitute these tracks in python for further analysis) I noticed an instance where the program seems to be splitting a track into two daughters pretty arbitrarily, and then constantly switching back and forth between the two. I’ve posted a screenshot of the excel file where I was looking at the breakdown, where the colors represent the different daughters (would have posted the excel file itself, but apparently .xls allowed as an attachment).

I haven’t delved too deeply into the rest of my data from this experiment, so I don’t know how often things like this are occurring (and i know that there are a majority of instances where telomeres are followed very well for 100+ frames), but it was troubling enough that I thought I’d see if you had any thoughts into why this was happening or how I could prevent it in the future. I’ve attached the pipeline and movie- thanks for any help or insight you may have!

*=Still using the program several times a week though! I’ve also got my lab and a former labmate’s new lab hooked on it, and working on converting others… (5.67 MB)
TelomereTrackingPipeline.cp (12.8 KB)

Glad you are still using CP! Keep up the good work spreading the news :smile:

Have you tried lowering the Split Alternative Cost? Actually, it looks like you have modified the costs markedly from the defaults (most ~40) to about 1. The settings are not easy to adjust and get feedback on, other than empirically, I understand. I haven’t looked at the code, and just a guess, but it might be that cost values of 1 may sit at some boundary and raising all of them slightly might make it more stable.

One nice way to visualize your tracks is detailed here:
I just downloaded R, rgl, and ran your pipeline all in only 20 minutes(!) and produced the attached 3D interactive plot (well, it’s interactive on my machine). I can see graphically your discontinuities, however other than adjusting the costs I don’t have any great insights. If these are representative movies, then the upshot is that they only take a few minutes to run on my laptop and so you can adjust the parameters empirically pretty quickly.


Hi David,
Thanks for the response- I set them to the minimum (1) following Lee’s advice earlier in this thread, but I’ll play around with other small numbers and see if it helps at all.
Just out of curiosity, is TrackObjects substantially different in 2.1 than it was in 2.0(11710)? 2.1 has been pretty buggy the times I tried to use it so I haven’t really played with it too much, but wondering if it makes more sense to try to optimize in that build.

Aha! I didn’t read far up the thread enough for Lee’s advice!

No, it is not substantially different to my knowledge. The changelog for that module is here: …
In fact you could just skim the code here and read the Help text I was referring to, without going through the trouble of installing.

But we will be releasing 2.1 at least as beta in the Fall (afaik) so we are more confident in the build now than ever. Note that the pipelines will almost certainly not be back-compatible, so caveat emptor.