JaCoP colocalization plugin bug ? – threshold applied differently to display and calculation of Manders’ coefficients

Tags: #<Tag:0x00007fd54016b6c0> #<Tag:0x00007fd54016b580>



I think I’ve found a bug in the JaCoP plugin related to how it thresholds data for calculation of M1 and M2 Manders’ coefficients.

When thresholds are set in the JaCoP plugin, the display shows those thresholds correctly: all pixels with intensities equal to or greater than the thresholds are displayed in red. However, when calculating Manders coefficients JaCoP only includes pixels greater than the thresholds, excluding those that are equal to the threshold (and which are displayed as passing the threshold).

A simple example way to illustrate this apparent bug is to generate some sample data with a text file, use import text image file to open it, convert it to 8-bit (making sure to have the “scale when converting” option OFF in the Edit menu) and run the JaCoP plugin to get the M1 & M2 coefficients.

Example data set:

2    1    2
10   10   10
5    5    5
5    10   2
5    10   1
5    10   2

Using the following thresholds:

tA: 5
tB: 10

JaCoP displays the correct 6 & 3 pixels respectively as passing the threshold.
For calculations, the correct thresholded M1 and M2 are:

M1: 0.333 (15/45) (fraction of A overlapping B)
M2: 0.666 (20/30) (fraction of B overlapping A)

However, the results from thresholded M1 and M2 from the JaCoP plugin are:

M1: 0.0
M2: 0.0

If we adjust the thresholds, we get the following results from JaCoP:

tA    tB     M1      M2
4     10     0       0
5     9      0.333   0.333
4     9      0.333   0.666

Note that the correct answer given the data, in all cases, is M1=0.333 and M2=0.666. The fact that lowering the thresholds by 1 unit for both gives the correct results seems to indicate that the problem is that the plugin uses a “greater than” instead of “greater than or equal” criteria when applying the threshold to the data.

A workaround is to set the thresholds as desired (based on the display) and then subtract one unit from each in the JaCoP plugin before doing the calculation.

I’m wondering if other people can replicate this bug, and if so, whether there is any way it could get fixed.



@oburri Have you ever noticed this potential issue ??



Just wanted to provide an update on this issue. I contacted the creators of the plugin (Fabrice Cordelieres; Susanne Bolte) and this behavior is not a bug. I am posting his reply here (with his permission):

[quote] this is not actually a bug, but a matter of definition. JACoP is considering the threshold to be the last excluded value, not including it.
In the original paper by Manders, the ‘threshold’ was set to zero, so that only values starting at one were considered. I’ve decided to adopt a comparable strategy when implementing JACoP.

The issue seems to be that ImageJ defines visual thresholds as equal to or greater than; thus the discrepancy. The workaround is as I mentioned in my previous post. It probably will not make much of a difference in 16-bit images, but it is worth knowing about this if using 8-bit images where pixel intensities are on the low side.