TUNEL Staining and co-localization quantification



Thanks so much for the support so far! I’m trying to build a pipeline for quantification of co-localization and was hoping to clarify a few things about the modules. Basically, what I’m trying to measure at this point is the percentage of TUNEL-positive nuclei in a stack of images. My basic approach is to measure the number of nuclei objects and the number of TUNEL objects (nuclei blue and Tunel yellow-green) per section, then to use one of the colocalization modules to determine which TUNEL stains co-localize with nuclei. I’ve actually tried to use both the measurecorrelation and relate modules, although I have to be honest that I’m not exactly sure how to interpret the readout. I finally settled on ‘relate’ in the attached pipeline because I’m not as interested in the correlation of intensity, but rather of objects themselves, and this one I think gives me a column that tells how many Tunel per nuclei per section. I’m not entirely sure what to make of the correlation number (which ranges from 1E2 to -1E3), and how I would use this in my analysis. All I really want to know is what percentage of Tunel stain is co-localized with nuclei so that I can adjust my total counts per section to reflect ‘true’ Tunel-positive nuclei. For example, a section might have 5 Tunel objects and 150 nuclei, with .80 co-localization of Tunel with nuclei such that I could determine 4 Tunel-positive nuclei in that section. Unfortunately, I’m not exactly sure how to arrive at the 80% value based on either the measurecorrelation or relate modules, so if you have any advice, I’d greatly appreciate it.

One other question concerning stacks, do you have any suggestions for loading .avi files, and is there any way to determine that an object counted in 1 section of a stack will not be counted in others. I think this was addressed in another forum, although I haven’t been able to verify that the software is doing this in my analysis.

Thanks again for all your help!

TUNELPIPE.mat (1.29 KB)


Hi Mike,

Re: Colocalization - Using the Relate module is probably your best bet, for the reasons you mention. The relationship between “parent” objects and “child” objects are saved as measurements.

If you use Relate to establish the TUNEL objects as “children” to the nuclei, TUNEL objects with no parents did not colocalize to a nucleus. Alternately, TUNEL objects with the same “parent” label all belong to the same nucleus. Finally, each “parent” has a count of the number of “children.”

Re: AVIs - They can loaded into CP provided that they are uncompressed, and are treated like an set of independent images. CP doesn’t have direct stack-manipulation tools as such, but it is possible to work with the constraints you mention. I took a stab at this issue in this thread.



Thanks Mark,

A couple things:

First, I’m not sure I understand what information is being provided by the Relate module exported to Excel. As I mentioned, I’m only interested in two numbers per slide: How many total nuclei, and how many Tunel-positive nuclei. It looks like the nuclei count is provided in one column (Count_Nuclei), but I have no idea where to find the number of Tunel-positive nuclei. The headings for the relate function all appear to be means (mean, Nuclei, Location_Center_X; mean, Tunel, Parent_Nuclei; mean, Means_Tunel_per_Nuclei, Parent_Nuclei; etc.) and the values given in each column are decimals indicating that these numbers were apparently calculated. Can you help decipher what these means are measuring, and more importantly, advise me how to find the number I need (the absolute number of tunel-positive nuclei per slide)?

Second, along the lines of following an object through a stack, I tried putting in two Track objects modules (one for Tunel and one for Nuclei) without any luck and received the error message below. There aren’t a lot of options available for this module, so I’m not sure what I can do to get it to work. If you have any thoughts, please let me know.

Thanks so much for your help!


There was a problem running the analysis module TrackObjects which is number 08. Error using ==> label2rgb>parse_inputs at 148
Invalid entry for MAP.

parse_inputs in C:\Program Files\CompiledCellProfilerXP325811Bugfix\CompiledCellProfiler\CellProfiler_mcr\toolbox\images\images\label2rgb.m (148)
label2rgb in C:\Program Files\CompiledCellProfilerXP325811Bugfix\CompiledCellProfiler\CellProfiler_mcr\toolbox\images\images\label2rgb.m (47)
TrackCPlabel2rgb in C:\Program Files\CompiledCellProfilerXP325811Bugfix\CompiledCellProfiler\CellProfiler_mcr\Modules\TrackObjects.m (550)
TrackObjects in C:\Program Files\CompiledCellProfilerXP325811Bugfix\CompiledCellProfiler\CellProfiler_mcr\Modules\TrackObjects.m (216)
AnalyzeImagesButton_Callback in C:\Program Files\CompiledCellProfilerXP325811Bugfix\CompiledCellProfiler\CellProfiler_mcr\CellProfiler\CellProfiler.m (10442)
gui_mainfcn in C:\Program Files\CompiledCellProfilerXP325811Bugfix\CompiledCellProfiler\CellProfiler_mcr\CellProfiler\CellProfiler.m (12182)
CellProfiler in C:\Program Files\CompiledCellProfilerXP325811Bugfix\CompiledCellProfiler\CellProfiler_mcr\CellProfiler\CellProfiler.m (57)


Re: Relate - In addition to the Image measurements being exported in ExportToExcel, you may also need to export the parent and child objects as well (i.e, nuclei and TUNEL) to make use of the Relate measurements. That is because the Relate measurements are on a per-object, not a per-image basis, so the per-image means are not really useful for those. Once you do that, you can see the parent-child relationships I described earlier.

Alternately, you can filter the nuclei objects on the basis of the parent-child relationships by using the FilterByObjectMeasurement module, to get rid of nuclei that have no children (i.e, no TUNEL objects). The remaining nuclei objects will be given a new name, counted and the result placed in the Image spreadsheet.

Re: TrackObjects - The current version is somewhat buggy; your problem may be the one described here. The solution I suggest there is also open to you as well.