http://imagej.273.s1.nabble.com/Quantifying-overlap-on-fluorescence-image-tp5021990p5022007.html
She used to be in 2018, e.g. dealing with a related topic.
> Hi Rohitesh,
>
> Could you please post your Coloc-2-related questions on forum.image.sc? The
> current maintainer of that plugin, Ellen Arena, is not subscribed to this
> mailing list, but is active on the image.sc forum.
>
> Thanks,
> Curtis
>
>
> On Sat, Apr 6, 2019, 14:33 Gupta, Rohitesh <
[hidden email]> wrote:
>
>> Hi All,
>>
>> I used Caco2 to analyze my image but the pdf file generated shows that the
>> y-intercept is non-zero. The warning asks me to subtract background and use
>> ROI. My question is, which channel should be selected for ROI and should I
>> perform background subtraction for both images ?
>>
>> Thanks,
>> Rohitesh
>>
>> -----Original Message-----
>> From: ImageJ Interest Group <
[hidden email]> On Behalf Of Gupta,
>> Rohitesh
>> Sent: Saturday, April 6, 2019 12:19 PM
>> To:
[hidden email]
>> Subject: Re: Quantifying overlap on fluorescence image
>>
>> Hi all,
>>
>> What about the colocalization tool as referred earlier in one of the
>> emails by Nick ? I used Jacop and was able to determine the colocalization
>> coefficients. Also isn't coloc2 a Fiji plugin ?
>>
>> Thanks,
>> Rohitesh
>>
>> -----Original Message-----
>> From: ImageJ Interest Group <
[hidden email]> On Behalf Of Curtis
>> Rueden
>> Sent: Saturday, April 6, 2019 10:14 AM
>> To:
[hidden email]
>> Subject: Re: Quantifying overlap on fluorescence image
>>
>> Hi all,
>>
>> I second the suggestion to use a dedicated plugin like Coloc 2 [1].
>>
>> There are many nuances and pitfalls to colocalization analysis. As such, I
>> strongly recommend checking out the Colocalization Analysis page [2] of the
>> ImageJ wiki before attempting to perform colocalization analysis. In
>> particular, do not use a naive approach like those discussed earlier in
>> this thread, as they do not consider the relevant statistical issues.
>>
>> Regards,
>> Curtis
>>
>> [1]
https://imagej.net/Coloc_2>> [2]
https://imagej.net/Colocalization_Analysis>>
>> --
>> Curtis Rueden
>> LOCI software architect -
https://loci.wisc.edu/software>> ImageJ2 lead, Fiji maintainer -
https://imagej.net/User:Rueden Have you
>> tried the Image.sc Forum?
https://forum.image.sc/>>
>>
>>
>> On Sat, Apr 6, 2019 at 3:21 AM Ondřej Šebesta <
[hidden email]>
>> wrote:
>>
>>> Hi.
>>> Is not this just one of the basic colocalization parameters: manders,
>>> which is calculated nearly by all colocalization tools and express so
>>> called coocurrence?
>>> Splitting your image into red and green channel and using FIJI
>>> included plugin Coloc2 should answer your question quite quickly.
>>>
>>> Hope this helps a little.
>>> Best Ondrej
>>>
>>> so 6. 4. 2019 v 0:39 odesílatel John A. Hayes <
[hidden email]>
>> napsal:
>>>
>>>> Hi all,
>>>>
>>>> I concur with Kenneth and was also default thinking you would be
>>>> able to split the images into 3 respective R-G-B channels, changing
>>>> the R and G
>>> to
>>>> 32-bit, and dividing one with the other using the image calculator,
>>>> then you’d average them based on some scaling value and developing a
>>>> %, but
>>> I’d
>>>> have to think about it more how much to scale everything. That’s
>>>> probably more efficient than iterating pixel by pixel (even though
>>>> that
>>> essentially
>>>> is being done at a lower computational level on byte arrays I
>>>> believe [i.e., much faster]).
>>>>
>>>> The bigger question I have about is the subject of your images. If
>>>> these are immunos, my understanding is that that’s not generally
>>>> quantitative,
>>> so
>>>> hypothetically saying there’s “2%” of overlap between (a) and (b) is
>>>> very subjective to the skills and quality of labeling and detection,
>>>> and area
>>> of
>>>> interest examined. I have found that frowned upon in my experience
>>>> for peer-reviewed articles unless that alone is used to motivate
>>> you/colleagues
>>>> to use a more quantitative approach for colocalization. That is to
>>>> say,
>>> we
>>>> detected colocalization to some degree (see Fig. XA/B) and that
>>>> motivated us to do further experiments to more directly test the
>>>> degree of colocalization…. Now if ANY overlap is scientifically
>>>> interesting, you would just need >=1 pixels and the actual value may
>>>> be unimportant… But again that comes down to how much confidence you
>>>> and your
>>> readers/audience
>>>> have in the approaches...
>>>>
>>>> Just my 2c.
>>>>
>>>> Good luck and all the best,
>>>>
>>>> John
>>>>
>>>>> On Apr 5, 2019, at 6:14 PM, Kenneth Sloan
>>>>> <
[hidden email]>
>>>> wrote:
>>>>>
>>>>> I don't know if this will be considered helpful, but...
>>>>>
>>>>> While there are apparently a number of co-location tools
>>>>> available, if
>>>> *I* had to solve this problem my first
>>>>> instinct would be to write a simple Java plugin.
>>>>>
>>>>> It's fairly simple to iterate over every pixel in the image
>>>>> (something
>>>> like):
>>>>> for(int y=0;y<height;y++)
>>>>> for((int x=0;x<width;x++)
>>>>> processPixel(x,y);
>>>>>
>>>>> inside "processPixel", I would simply fetch the pixel value as an
>>>>> r,g,b
>>>> triple, and then apply whatever
>>>>> logic you want. In this case, something like:
>>>>>
>>>>> if ((r>0) && (g>0)) overlap++;
>>>>>
>>>>> Now, you have the number of pixels with non-zero values for both r
>>>>> and
>>>> g. Is that what you want?
>>>>>
>>>>> The level of Java programming competence to do this is really
>>>>> quite
>>>> minimal - and ALL of the necessary information (including
>>>>> templates for the necessary program) is in the ImageJ manual.
>>>>>
>>>>> I'm sure there are clever ways to do this, perhaps involving some
>>> flavor
>>>> of "image calculator" (which, more or less, simply
>>>>> does the iteration over all pixels for you - and provides yet
>>>>> another
>>>> syntax for specifying the per-pixel computation).
>>>>>
>>>>> But, once you have written 10 of these "process all the pixels in
>>>>> an
>>>> image" plugins in Java, the next one can be banged out
>>>>> in 15 minutes (depending on your propensity for typos). In fact -
>>>>> you
>>>> are eventually convinced to write it so that only "processPixel"
>>>> needs to be modified.
>>>>>
>>>>> I will grant you that the FIRST one has a fairly steep learning
>> curve.
>>>> My point is: it's worth it. I have always considered the primary
>>> advantage
>>>> of ImageJ to be the ability to easily integrate absolutely arbitrary
>>>> Java code.
>>>>>
>>>>>
>>>>> --
>>>>> Kenneth Sloan
>>>>>
[hidden email]
>>>>> Vision is the art of seeing what is invisible to others.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Apr 5, 2019, at 11:58, Rohitesh Gupta
>>>>>> <
[hidden email]>
>>>> wrote:
>>>>>>
>>>>>> Dear Kees,
>>>>>>
>>>>>> Thank you for your reply. Happy to get such a quick response.
>>>>>> May I ask how one can identify overlap by just splitting the
>>>>>> images in
>>>> red and green. I tried doing that but wasn't sure how to determine
>>> overlap
>>>> based on split.
>>>>>>
>>>>>> Would be happy to hear your reply.
>>>>>>
>>>>>> Thanks again,
>>>>>> Rohitesh
>>>>>>
>>>>>> --
>>>>>> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>>>>>
>>>>> --
>>>>> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>>>>
>>>> --
>>>> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>>>>
>>>
>>>
>>> --
>>> Mgr. Ondřej Šebesta
>>> Laboratory of Confocal and Fluorescence Microscopy Faculty of Science,
>>> Charles University in Prague Vinicna 7
>>> 128 44 Prague
>>> Czech Republic
>>>
>>> Phone: +420 2 2195 1061
>>> e-mail:
[hidden email]
>>>
>>> --
>>> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>>>
>>
>> --
>> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>>
>> The information in this e-mail may be privileged and confidential,
>> intended only for the use of the addressee(s) above. Any unauthorized use
>> or disclosure of this information is prohibited. If you have received this
>> e-mail by mistake, please delete it and immediately contact the sender.
>>
>> --
>> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>>
>> The information in this e-mail may be privileged and confidential,
>> intended only for the use of the addressee(s) above. Any unauthorized use
>> or disclosure of this information is prohibited. If you have received this
>> e-mail by mistake, please delete it and immediately contact the sender.
>>
>> --
>> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>>
>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>