Re: Costes thresholding and Manders Colocalization Coefficients in Fiji/JaCoP

[Birgit Möller]

Hi Tom,
first of all sorry for this delay of my answer, I was out of office for some days and unfortunately missed to let you know that.

On Sat, 17 Aug 2013 22:59:46 +0200, Tom Kazimiers <[hidden email]> wrote:
>Hi Birgit,
>
>On Fri, Aug 16, 2013 at 09:57:19AM -0400, Birgit M�ller wrote:
>> thanks for this very detailed answer!
>
>you are welcome. :-)

:-)

>> On Fri, 16 Aug 2013 15:09:57 +0200, Tom Kazimiers <[hidden email]> wrote:
>> >On Thu, Aug 15, 2013 at 03:18:18AM -0400, Birgit M�ller wrote:
>> >> [...] it makes a difference whether I calculate colocalization for
>> >> image A against B or vice versa. I guess this is due to the fact that
>> >  [...]
>> >So yes, the unsymmetric behaviour originates from T_r and T_g and
>> >depends on how these are calculated. This is done in the following way,
>> >described in more detail in Costes' paper:
>> >
>> >In a coordinate system the X axis represents the threshold of channel 1
>> >and the Y axis represents the threshold of channel 2. Meaningful as
>> >threshold is therefore basically the first quadrant where both axes
>> >reach from the image data type's minimum to its maximum.
>>
>> >Next, the slope as well as the y-intercept of a regression line is
>> >calculated. This determines the ratio between both channel's thresholds.
>> >This should be symmetric and mirrored at the x=y line (as you can see in
>> >the scatter plot of Coloc 2's result window).
>>
>> You mean that swapping the images causes the regression line to be
>> mirrored at the line x=y? Yes, I fully agree. Anyway - maybe not
>> important for you, but for the JaCoP people - this behaviour cannot be
>> reproduced in JaCoP. I think this is due to the fact that they do not
>> apply an orthogonal regression, but an ordinary linear least squares
>> approach with yields completely independent results for doing a
>> regression A against B vs. B against A. So the differences in the
>> results for A vs. B and B vs. A are much larger in JaCoP.
>
>I, too, think it would be good for auto the thresholding used with
>colocalization to yield the same results for A-B and B-A.

Definitely.

>> >To find good thresholds, the algorithm starts at the "top" of the
>> >regression line and goes down until some termination criteria is met,
>> >with "top" being the half between channel one's minimum and maximum
>> >value. Going done that line, the thresholds are used in Pearson's R
>> >value calculation on the channel one and two images. The threshold for
>> >channel two is is determined by the value of the regression line at
>> >x=threshold one.  If Pearson's R is below zero the regression went to
>> >far and the threshold is increased half way to the last threshold. If
>> >not, the next candidate point on the regression line is chosen by
>> >lowering channel one's threshold by half the distance to the last
>> >threshold candidate (for the first step, the last value is channel one's
>> >maximum). This is done until the difference between the current
>> >threshold and the last threshold candidate is below one (or a maximum
>> >number of iteration is reached).
>> >
>> >As an example,
>> >[...]
>> >The fact that there a different starting thresholds for each combination
>> >and the inversion regression line leads to a different pattern on how
>> >different thresholds are tried. However, it should be possible to find a
>> >pattern to go down the regression line, regardless of the channel
>> >ordering. If I am not mistaken, this should then produce the same
>> >thresholds for both combinations.
>>
>> Ok, I see. But, just to clarify, this means that you actually
>> implemented some kind of speed-up heuristic for finding the thresholds
>> which causes the differences in the thresholds, right?
>
>Yes, this correct.
>
>> I think that the algorithm as originally described in Costes paper
>> would more or less naively check all thresholds on the line starting
>> with the channel maximum of the first image and decreasing the
>> threshold by one in each step. And following this scheme, which is of
>> course far more time-consuming, the resulting thresholds should be the
>> same. Do you agree?
>
>I agree. I could easily add a checkbox to the plugin's setup dialog to
>ask the user if (s)he wants to use the speeded-up version or the naive
>one. Do you think this would be a good addition?

Yes, I think that would be a good compromise.

>> > The current pattern is: decrease the
>> >current threshold candidate in each iteration by half the distance to
>> >the last threshold candidate. If Person's R is below zero, go up again
>> >half the distance. We could change that into using the distance on the
>> >regression line itself, and not in the threshold dimension of image one
>> >(like done now). Do you see any downsides of this?
>>
>> No, if in addition the corresponding starting point on the mirrored
>> regression line is used this should yield equivalent results.
>
>Yes. So in case we we would always need to start at the point where we would
>catch the maximum values of each channel, at least when we start at the
>"top". This is the point where the threshold of the channel with the
>largest maximum value is at exactly at that point, i.e. it is mirrored
>as well. More general (if we don't start at the "top"), it is the
>corresponding starting point, just like you said.
>
>And do you think this should be optional? I think it shouldn't, but we
>should enforce this behavior. Do you agree? For this is wouldn't matter
>if the naive or the speeded-up regression would be used. It would,
>however, make the regression more robust.

Yes, I agree. I would also enforce this behaviour. I don't see the necessity for making it optional.

>Cheers,
>Tom

Best regards,

 Birgit

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html