http://imagej.273.s1.nabble.com/Quantifying-overlap-on-fluorescence-image-tp5021990p5022002.html
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 ?
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 ?
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.
> 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>
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.
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.