http://imagej.273.s1.nabble.com/Quantifying-overlap-on-fluorescence-image-tp5021990p5021998.html
so 6. 4. 2019 v 0:39 odesílatel John A. Hayes <
> 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