http://imagej.273.s1.nabble.com/Quantifying-overlap-on-fluorescence-image-tp5021990p5022000.html
There are many nuances and pitfalls to colocalization analysis. As such, I
ImageJ wiki before attempting to perform colocalization analysis. In
> 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>