Quantifying overlap on fluorescence image
Locked
Quantifying overlap on fluorescence image
 
|
Hi Guys,
I had posted a query yesterday to which I did receive a reply. I am attaching an image which doesn't have any overlap between the green and red signal. It would be great if anyone can help in sharing the methodology to quantify an overlap (red and green making a yellow signal). In this case, the overlap factor should show zero value. Thanks, Rohitesh -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
BC Image.jpg (180K)
Re: Quantifying overlap on fluorescence image
|
|
Hello Rohitesh, welcome to the ImageJ community.
For pixel based colocalization, you can use this imageJ/Fiji plugin https://imagej.net/Coloc_2 . The website explains some of the caveats for colocalization analysis and how to use it. JACoP is also a useful plugin, and it is described in this publication https://onlinelibrary.wiley.com/doi/full/10.1111/j.1365-2818.2006.01706.x I suspect you did not receive help because your question yesterday was broad and vague, and it was not clear what you needed. For more help in the future post specific questions or issues and check out the forum https://forum.image.sc/ . Searching for colocalization there yields a lot of useful results. https://forum.image.sc/search?q=colocalization Good luck! Nick On 4/5/19 9:41 AM, Rohitesh Gupta wrote: > Hi Guys, > > I had posted a query yesterday to which I did receive a reply. I am attaching an image which doesn't have any overlap between the green and red signal. It would be great if anyone can help in sharing the methodology to quantify an overlap (red and green making a yellow signal). In this case, the overlap factor should show zero value. > > Thanks, > Rohitesh > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by Rohitesh Gupta
Dear Rohitesh,
Nick gave already some good links to measure colocalization. However, I don't agree with you that there is no overlap between the red and green signal in your image. Even by just looking at your jpg image (hope you have the original image for analysis as you lose information when using the jpg format) I can see already an overlap as some of the pixels show yellowish. Splitting the channels in red and green images show this as well, see attached. Best wishes Kees Dr Ir K.R. Straatman Senior Experimental Officer Advanced Imaging Facility Centre for Core Biotechnology Services University of Leicester www.le.ac.uk/advanced-imaging-facility -----Original Message----- From: ImageJ Interest Group <[hidden email]> On Behalf Of Rohitesh Gupta Sent: 05 April 2019 16:42 To: [hidden email] Subject: Quantifying overlap on fluorescence image Hi Guys, I had posted a query yesterday to which I did receive a reply. I am attaching an image which doesn't have any overlap between the green and red signal. It would be great if anyone can help in sharing the methodology to quantify an overlap (red and green making a yellow signal). In this case, the overlap factor should show zero value. Thanks, Rohitesh -- ImageJ mailing list: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimagej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Ckrs5%40leicester.ac.uk%7C85d6f03171d5456efbaf08d6b9e22d37%7Caebecd6a31d44b0195ce8274afe853d9%7C0%7C0%7C636900778423028475&sdata=1OhHz1vOUb%2B0r%2B8UaZHkVN5b%2Foh%2B2c9fppFCBckxtgY%3D&reserved=0 -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: Quantifying overlap on fluorescence image
|
|
In reply to this post by Rohitesh Gupta
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 |
Re: Quantifying overlap on fluorescence image
|
|
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 |
Re: Quantifying overlap on fluorescence image
|
|
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 |
|
|
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 |
Re: Quantifying overlap on fluorescence image
|
|
In reply to this post by Kenneth Sloan-2
Dear Kenneth, Rohitesh and Kees,
You could give a try to the following plugin: http://punias.free.fr/ImageJ/Colocalization_Finder.jar which is an update of the following tool: https://imagej.nih.gov/ij/plugins/colocalization-finder.html which new descriptions can be found here: http://punias.free.fr/ImageJ/colocalization-finder.html Have nice week-end, Philippe Le Samedi 6 Avril 2019 00:14 CEST, Kenneth Sloan <[hidden email]> a écrit: > 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 |
Re: Quantifying overlap on fluorescence image
|
|
In reply to this post by John Hayes
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 |
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 |
Re: Quantifying overlap on fluorescence image
|
|
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 |
Re: Quantifying overlap on fluorescence image
|
|
In reply to this post by Rohitesh Gupta
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 |
|
|
"Ellen Arena, is not subscribed to this mailing list"
She used to be in 2018, e.g. dealing with a related topic. <https://list.nih.gov/cgi-bin/wa.exe?A2=ind1804&L=IMAGEJ&F=&S=&P=78133> In 2016 <https://list.nih.gov/cgi-bin/wa.exe?A2=ind1601&L=IMAGEJ&P=R78758> she presented her interesting novice view of Coloc2. HTH Herbie ::::::::::::::::::::::::::::::::::::::::::: Am 07.04.19 um 16:10 schrieb Curtis Rueden: > 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 > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: Quantifying overlap on fluorescence image
|
|
In reply to this post by Rohitesh Gupta
I want to ask this again if anyone has had success with coloc2 ? I am trying diff ways to rectify my images but I still get that conventional warning message. I am just thinking of splitting the images and measuring fluorescence independently for each channel. It doesn't seem like that coloc2 is indeed a good option.
-- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: Quantifying overlap on fluorescence image
|
|
I hate to be a “Debbie Downer” (https://en.wikipedia.org/wiki/Debbie_Downer); but again Rohitesh, I wonder what you/your adviser/your supervisor are getting at here. You certainly should split the channels, but if I have to (partly) get “nerdy/technical” here, I’m wondering how cleanly you expect these channels to be? They are not as clean as you may have been led to believe in a microscope training session as I was (GFP, just 500-530 nm — that’s what I was taught! — WRONG). Again, NOT QUANTITATIVE!! There’s inevitably going to be SOME overlap between the RGB channels… The degree of overlap, and the importance thereof, is subjective in my view — that’s where to attack in a referee report. If you start exactly spouting percentages of overlap from these data, for the reviewer, even better to shoot you down!
If you look at the fluorescence spectra of common fluorophores found here: http://www.spectra.arizona.edu/ and here: https://www.thermofisher.com/us/en/home/life-science/cell-analysis/labeling-chemistry/fluorescence-spectraviewer.html They are NEVER cleanly separated across spectra of fluorophores like software RGB cleanly are. I hate to be the only one that craps on this for you (and I’m the only one on the mailing list that thinks this?), and maybe I’m being nitpicky, but I DO wish you all the best. Again, I wish you the best; but I thought I’d add just my 2c because I’m trying to giving you CONSTRUCTIVE advice and not just INSTRUCTIVE advice… Cheers, John > On Apr 12, 2019, at 9:30 PM, Rohitesh Gupta <[hidden email]> wrote: > > I want to ask this again if anyone has had success with coloc2 ? I am trying diff ways to rectify my images but I still get that conventional warning message. I am just thinking of splitting the images and measuring fluorescence independently for each channel. It doesn't seem like that coloc2 is indeed a good option. > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: Quantifying overlap on fluorescence image
|
|
In reply to this post by Rohitesh Gupta
You are thinking too deep into the fluorescent spectra of these channels. I am just trying to understand how to quantify individual samples if there is a difference between the intensity of green/red channels based on the difference in the antibody staining on that particular sample. To quantify overlap, I wanted to use coloc2. But, it seems like that because of the warning message, I am not sure how to depend on the output file ? So now i am thinking to go with the basics, and just calculate fluorescence intensity independently for each channel and report that. I am sure if two samples are compared having different fluorescence intensity, then that will show up. Certainly, I won't be able to quantify overlap.
-- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: Quantifying overlap on fluorescence image
|
|
Dear Rohitesh,
Did you give a try to the tool I indicated you on my mail from April 6th (see below)? This tool will be working for whatever input picture you may have. In order to use coloc2 you need to (only) have 8 bit pictures as inputs. Is this your case? My best regards, Philippe Dear Kenneth, Rohitesh and Kees, You could give a try to the following plugin: http://punias.free.fr/ImageJ/Colocalization_Finder.jar which is an update of the following tool: https://imagej.nih.gov/ij/plugins/colocalization-finder.html which new descriptions can be found here: http://punias.free.fr/ImageJ/colocalization-finder.html Have nice week-end, Philippe Le Samedi 13 Avril 2019 18:23 CEST, Rohitesh Gupta <[hidden email]> a écrit: > You are thinking too deep into the fluorescent spectra of these channels. I am just trying to understand how to quantify individual samples if there is a difference between the intensity of green/red channels based on the difference in the antibody staining on that particular sample. To quantify overlap, I wanted to use coloc2. But, it seems like that because of the warning message, I am not sure how to depend on the output file ? So now i am thinking to go with the basics, and just calculate fluorescence intensity independently for each channel and report that. I am sure if two samples are compared having different fluorescence intensity, then that will show up. Certainly, I won't be able to quantify overlap. > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: Quantifying overlap on fluorescence image
|
|
In reply to this post by Rohitesh Gupta
Hi Philippe,
Thanks for the link. The plugin seems to work well for my images. Thanks again. Happy weekend! Rohitesh -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by Rohitesh Gupta
Good day,
please note that ImageJ-plugins and -macros differ in many aspects. Plugins are always written in Java. Here is a good introduction: <https://imagingbook.files.wordpress.com/2013/06/tutorial171.pdf> The ImageJ-macro language is mainly meant for rapid prototyping, i.e. for calling plugins in a desired order. Here is a description <https://imagej.nih.gov/ij/developer/macro/macros.html> and here is a commented list of built-in functions. <https://imagej.nih.gov/ij/developer/macro/functions.html> To start with writing plugins or macros you should consider using the macro-recorder functionality of ImageJ. (Select either macro or java.) HTH Herbie Rohitesh Gupta wrote > Hi Guys, > > I had posted a query yesterday to which I did receive a reply. I am > attaching an image which doesn't have any > overlap between the green and red signal. It would be great if anyone can > help in sharing the methodology to quantify an overlap (red and green > making a yellow signal). In this case, the overlap factor should show zero > value. > > Thanks, > Rohitesh > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > > > BC Image.jpg (180K) > <http://imagej.1557.x6.nabble.com/attachment/5021990/0/BC%20Image.jpg> -- Sent from: http://imagej.1557.x6.nabble.com/ -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
«
Return to ImageJ
|
1 view|%1 views
| Free forum by Nabble | Edit this page |