I have noticed some interesting behavior with the Gabriel Landini's Color
Deconvolution plugin. When I use the 'H DAB' vector set to separate my images of DAB and hematoxylin stained slides, I get a fair amount of signal in the 'zero' channel. This is also demonstrated in Landini's example using the built in 'H DAB' vectors (http://www.dentistry.bham.ac.uk/landinig/software/cdeconv/cdeconv.html). I know that I need to measure our actual chromagens separately and then put these (normalized values) into the user values boxes or add them to the code. This is also noted by Landini on his page. I am in the process of doing this now since I know that my chromagens are pretty different from the default vectors. The interesting thing is that if I use the default 'H&E DAB' vector set for Landini's demo image or any of my images, I get what appears to be much more accurate hematoxylin and DAB channel images. Also, the eosin channel is very clean compared to the 'zero' channel using the 'H DAB' vectors. This also holds true when I use these vector sets with my slides stained only with DAB or only hematoxylin (though the DAB only slide does show some apparent bleed through into the hematoxylin channel). The DAB and hematoxylin vector values are the same for both vector sets, the only difference are the 'zero' vs eosin third vector sets. I am curious as to why this happens, but more importantly, I am wondering if I can use the default H&E DAB set as a better rough+ready vector set (especially for images where I don't have individually stained slides to determine the ideal vectors.) I would appreciate any insight into this. Thanks, Jim |
On Wednesday 02 November 2005 14:53, No Name wrote:
> I know that I need to measure our actual chromagens separately and then > put these (normalized values) into the user values boxes or add them to > the code. This is also noted by Landini on his page. I am in the process > of doing this now since I know that my chromagens are pretty different > from the default vectors. Yes, that is the best: stain the images with only 1 chromogen at a time and extract the vectors that way. > The interesting thing is that if I use the default 'H&E DAB' vector set > for Landini's demo image or any of my images, I get what appears to be > much more accurate hematoxylin and DAB channel images. Maybe it looks accurate, but the idea is that one first defines the colours used to make sure that the unmixing result is what one intends. I have also noted that DAB does vary across labs but also the haematoxylin is quite variable (specially since there are several methods). Make sure that you colour-correct all the images (by dividing the original image by the brightfield and multiplying the result by 255; you can use the Calculator_Plus for doing it in one step without having to resort to 32bit conversion). > The DAB and hematoxylin vector values are the same for both vector sets, > the only difference are the 'zero' vs eosin third vector sets. In the H DAB option the third component is calculated as the orthogonal to the other 2 available (some shade of green). In the H, E, DAB one the 3rd is the eosin colour, so the transformation is forced to separate into those 3 instead. (that means that the 2 colour spaces are not the same). I guess that this difference (by luck?) compensates for any inaccuracies that there may be in the vectors. > if I can use the default H&E DAB set as a better rough+ready vector set > (especially for images where I don't have individually stained slides to > determine the ideal vectors.) The problem is, I think, that one is never sure that the other 2 vectors get separated correctly; they may have some degree of mixing between them. If staining is 'exclusive' then you would see the effect, but if you have co-localisation of the colours it may be difficult to realise the size of the error, despite that you have an almost empty "3rd image". If single-stained images are not available, you could try to define the vectors on areas which are uniquely labelled with each stain, but unfortunately one cannot make it always sure that this is so. I hope it helps. Cheers, Gabriel |
Gabriel,
Your color deconvolution plugin is just what I need, thanks! Is the Ruifrok and Johnston article available online anywhere, I could only find an abstract. Mike Smith |
On Thursday 03 November 2005 20:27, Smith, Mike wrote:
> Your color deconvolution plugin is just what I need, thanks! > > Is the Ruifrok and Johnston article available online anywhere, I could only > find an abstract. Not that I am aware of. Perhaps one can order it through interlibrary loan. There is a new version coming out today. I will post it to the list when ready to download. Cheers, Gabriel |
In reply to this post by No Name-4
Gabriel,
Thank you very much for your insights into the Color Deconvolution plugin. I didn't understand how the 3rd vector was created for 2 color stain sets before. Also, thank you and Dennis for the updated version of Color Decon - stack capability and the better image names are a big help. I am still having some trouble getting my DAB and Hem vectors to produce accurate output. My DAB vector appear to be very close to the built-in DAB vector but my hematoxylin vector is a bit different (mine:0.778, 0.563, 0.277 vs. Rufroik:0.650, 0.700, 0.290). Using the built in vector set 'H DAB' I get a result very similar to the example on your web page (significant signal in the third 'green' vector over both DAB and Hem stained regions.) Using my vector set for 'H DAB' results in a 'grey' third channel but now all three resulting images have many pure white (255) pixels scattered throughout. Does this indicate that the vectors are too close to each other for accurate separation or just that I still don't have the correct vectors? Thanks, Jim Gabriel Landini <[hidden email]> Sent by: ImageJ Interest Group <[hidden email]> 11/02/2005 10:48 AM Please respond to ImageJ Interest Group To: [hidden email] cc: (bcc: James Deeds/PH/Novartis) Subject: Re: H DAB Color Deconvolution vectors On Wednesday 02 November 2005 14:53, No Name wrote: > I know that I need to measure our actual chromagens separately and then > put these (normalized values) into the user values boxes or add them to > the code. This is also noted by Landini on his page. I am in the process > of doing this now since I know that my chromagens are pretty different > from the default vectors. Yes, that is the best: stain the images with only 1 chromogen at a time and extract the vectors that way. > The interesting thing is that if I use the default 'H&E DAB' vector set > for Landini's demo image or any of my images, I get what appears to be > much more accurate hematoxylin and DAB channel images. Maybe it looks accurate, but the idea is that one first defines the colours used to make sure that the unmixing result is what one intends. I have also noted that DAB does vary across labs but also the haematoxylin is quite variable (specially since there are several methods). Make sure that you colour-correct all the images (by dividing the original image by the brightfield and multiplying the result by 255; you can use the Calculator_Plus for doing it in one step without having to resort to 32bit conversion). > The DAB and hematoxylin vector values are the same for both vector sets, > the only difference are the 'zero' vs eosin third vector sets. In the H DAB option the third component is calculated as the orthogonal to the other 2 available (some shade of green). In the H, E, DAB one the 3rd is the eosin colour, so the transformation is forced to separate into those 3 instead. (that means that the 2 colour spaces are not the same). I guess that this difference (by luck?) compensates for any inaccuracies that there may be in the vectors. > if I can use the default H&E DAB set as a better rough+ready vector set > (especially for images where I don't have individually stained slides to > determine the ideal vectors.) The problem is, I think, that one is never sure that the other 2 vectors get separated correctly; they may have some degree of mixing between them. If staining is 'exclusive' then you would see the effect, but if you have co-localisation of the colours it may be difficult to realise the size of the error, despite that you have an almost empty "3rd image". If single-stained images are not available, you could try to define the vectors on areas which are uniquely labelled with each stain, but unfortunately one cannot make it always sure that this is so. I hope it helps. Cheers, Gabriel |
On Friday 04 November 2005 16:23, [hidden email] wrote:
> I am still having some trouble getting my DAB and Hem vectors to produce > accurate output. My DAB vector appear to be very close to the built-in DAB > vector but my hematoxylin vector is a bit different (mine:0.778, 0.563, > 0.277 vs. Rufroik:0.650, 0.700, 0.290). You could try to make a image by stitching 2 or 3 images of singly stained material and note the "ROI vector matrix values" by clicking "show matrices" for all the stains, repeat this several times and calculate an average value for each to minimise sampling error). Also try to sample in areas that have strong stain (but not near black, obviously). Note that the optical density values from the ROIs are an average, so try to select the ROIs small and as I suggested above on areas well stained. Then use "User values" to enter those average values and let the plugin calculate the translation matrix values (then one should insert those in the plugin code). > Using the built in vector set 'H > DAB' I get a result very similar to the example on your web page > (significant signal in the third 'green' vector over both DAB and Hem > stained regions.) Using my vector set for 'H DAB' results in a 'grey' > third channel but now all three resulting images have many pure white > (255) pixels scattered throughout. > Does this indicate that the vectors are > too close to each other for accurate separation or just that I still don't > have the correct vectors? Not sure, it could be a bug. The 3rd colour, if 0, is defined automatically, so it depends on the other 2. Please post somewhere an image and a macro with the user values you defined to see if this is reproducible or if there is a bug in the code. Please do not email me a large image because until Monday I will be accessing the net through a slowish modem. About the white pixels, what kind of image format are you using? Are they acquired as jpegs? Where one of the stains is not present, the result is supposed to be 255 or near. Cheers, Gabriel |
In reply to this post by No Name-4
I have programmed a color deconvolution plugin for Photoshop-plugin compatible hosts (Photoshop and other main image editing programs plus a number of free image viewers/editors). I intended it mainly for forensic purposes (color separation and removal) but I think it should be fine for the purposes discussed here as well (if not, I might add features).
I am giving it away for free via 4N6site.com and you can find examples, instructions etc there as well. Cheers, Charles |
Free forum by Nabble | Edit this page |