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