Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
4 posts
|
Hi all,
I have a large number of images that I've created by splattering a small blob of black ink on a needle onto a piece of plain white paper. Once the ink has dried I've been trying to use imagej to count the number of blobs. I've found the 'Particle Analyzer' function and created a small macro that runs 'Make Binary' and then 'Particle Analyzer' on the images and saves the count. On low DPI images, saved straight to jpg, imagej consistently comes well under manual counts. On high DPI images, saved to tiff and then converted (on max settings) to jpgs (so imagej can load them), imagej consistently counts higher than the manual counts. Does anyone have any ideas as to how I can improve accuracy? I've spent a while trying different pixel^2 and circularity settings. I'm using the version of imagej from the ubuntu repositories (1.44i). Thanks in advance, -- Matthew Moore Surgical Materials Testing Laboratory System Administrator Telephone: +44 (0)1656 752165 Email: [hidden email] -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
1783 posts
|
On Wednesday 01 Aug 2012 10:35:03 Matthew Moore wrote:
> On low DPI images, saved straight to jpg, imagej consistently comes well > under manual counts. On high DPI images, saved to tiff and then > converted (on max settings) to jpgs (so imagej can load them), imagej > consistently counts higher than the manual counts. Shouldn't the amount of ram to hold the loaded image be the same regardless of the format that is stored in? But you can improve accuracy in the representation of your image data by not using lossy formats (like lossy jpeg). Do you see where the the differences are? for example do you detect too many 1 pixel regions? Is that noise or data? Have you tried different segmentation methods? Do they converge? > Does anyone have any ideas as to how I can improve accuracy? I've spent > a while trying different pixel^2 and circularity settings. I'm using > the version of imagej from the ubuntu repositories (1.44i). Without more details it is difficult to know what is going on, but I would be willing to bet it is not the particle analyzer accuracy, but the segmentation approach used. You would benefit from the constant bug fixing. Latest ij.jar is 1.47b6 (the daily build). Cheers Gabriel -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
4 posts
|
On 01/08/12 11:22, Gabriel Landini wrote:
> On Wednesday 01 Aug 2012 10:35:03 Matthew Moore wrote: >> On low DPI images, saved straight to jpg, imagej consistently comes well >> under manual counts. On high DPI images, saved to tiff and then >> converted (on max settings) to jpgs (so imagej can load them), imagej >> consistently counts higher than the manual counts. > Shouldn't the amount of ram to hold the loaded image be the same regardless of > the format that is stored in? > But you can improve accuracy in the representation of your image data by not > using lossy formats (like lossy jpeg). The loading issue was that imagej wouldn't read the tiff created by xsane (which I'm using for the scanning). I've converted the tiffs from xsane into a tif with no compression and imagej loads them fine now. > Do you see where the the differences are? for example do you detect too many 1 > pixel regions? Is that noise or data? Have you tried different segmentation > methods? Do they converge? The main problem is that the 'Make binary' that you have to use before running the particle analyzer introduces lots of noise into the image, so it picks up lots of false positives. >> Does anyone have any ideas as to how I can improve accuracy? I've spent >> a while trying different pixel^2 and circularity settings. I'm using >> the version of imagej from the ubuntu repositories (1.44i). > Without more details it is difficult to know what is going on, but I would be > willing to bet it is not the particle analyzer accuracy, but the segmentation > approach used. > > You would benefit from the constant bug fixing. Latest ij.jar is 1.47b6 (the > daily build). I'm sorry, but I've no idea what segmentation approach I'm using. Not entirely sure what you mean there (and not been able to figure it out from the docs). The dots are quite obvious really, it's a plain white piece of paper with black blobs on it. I'll certainly try the latest daily. Thanks, -- Matthew Moore Surgical Materials Testing Laboratory System Administrator Telephone: +44 (0)1656 752165 Email: [hidden email] -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
25 posts
|
Hi,
you can easily check whether the count makes sense, if you display the outlines of the counted particles (Show: Overlay Outlines). If you compare this to your original image, you might be able to identify the problem. To remove noise "particles", you could try the Gaussian filter (Process-Filters-Gaussian Blur). The preview option allows to check whether you kill small particles by that. Best regards, Volker 2012/8/2 Matthew Moore <[hidden email]>: > On 01/08/12 11:22, Gabriel Landini wrote: >> On Wednesday 01 Aug 2012 10:35:03 Matthew Moore wrote: >>> On low DPI images, saved straight to jpg, imagej consistently comes well >>> under manual counts. On high DPI images, saved to tiff and then >>> converted (on max settings) to jpgs (so imagej can load them), imagej >>> consistently counts higher than the manual counts. >> Shouldn't the amount of ram to hold the loaded image be the same regardless of >> the format that is stored in? >> But you can improve accuracy in the representation of your image data by not >> using lossy formats (like lossy jpeg). > > The loading issue was that imagej wouldn't read the tiff created by > xsane (which I'm using for the scanning). I've converted the tiffs from > xsane into a tif with no compression and imagej loads them fine now. > >> Do you see where the the differences are? for example do you detect too many 1 >> pixel regions? Is that noise or data? Have you tried different segmentation >> methods? Do they converge? > > The main problem is that the 'Make binary' that you have to use before > running the particle analyzer introduces lots of noise into the image, > so it picks up lots of false positives. > >>> Does anyone have any ideas as to how I can improve accuracy? I've spent >>> a while trying different pixel^2 and circularity settings. I'm using >>> the version of imagej from the ubuntu repositories (1.44i). >> Without more details it is difficult to know what is going on, but I would be >> willing to bet it is not the particle analyzer accuracy, but the segmentation >> approach used. >> >> You would benefit from the constant bug fixing. Latest ij.jar is 1.47b6 (the >> daily build). > > I'm sorry, but I've no idea what segmentation approach I'm using. Not > entirely sure what you mean there (and not been able to figure it out > from the docs). The dots are quite obvious really, it's a plain white > piece of paper with black blobs on it. > > I'll certainly try the latest daily. > > Thanks, > > -- > Matthew Moore > Surgical Materials Testing Laboratory > System Administrator > Telephone: +44 (0)1656 752165 > Email: [hidden email] > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html ... [show rest of quote] -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
1783 posts
|
In reply to this post by Matthew Moore
> The main problem is that the 'Make binary' that you have to use before
> running the particle analyzer introduces lots of noise into the image, > so it picks up lots of false positives. In that case you could process the image before thresholding or after. Before: there are many filters that you can try: smoothing (mean, Gaussian), median, morphological (greyscale closing/opening). During: you could to try different methods for the actual thresholding step (and IJ supports quite a few) or some other pixel classification. After: binary closing/opening, filter by size, opening and closing by reconstruction, median, etc. You need to be aware that by any of that processing, you are changing the original data. > The dots are quite obvious really, it's a plain white > piece of paper with black blobs on it. I guess that probably the dots are not the problem, but the image or background is not completely white, and the thresholding level that you are using picks some of that intensity variation as "object". Regards Gabriel -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
4 posts
|
On 02/08/12 11:06, Gabriel Landini wrote:
>> The main problem is that the 'Make binary' that you have to use before >> running the particle analyzer introduces lots of noise into the image, >> so it picks up lots of false positives. > In that case you could process the image before thresholding or after. > > <snip> > > You need to be aware that by any of that processing, you are changing the > original data. Thanks for the pointers. I've been trying various combinations of them out, not got better than about +/- 20% so far. The flag to ignore dots on the edge of the image has been the most useful so far, as that's nearly always noise. >> The dots are quite obvious really, it's a plain white >> piece of paper with black blobs on it. > I guess that probably the dots are not the problem, but the image or > background is not completely white, and the thresholding level that you are > using picks some of that intensity variation as "object". Exactly. As you and Volker correctly guessed part of the problem is that when scanning dust is picked up (which looks similar to the smallest blobs) and when the image processing is done for the counting, noise from the paper is picked up (shade from where the paper wasn't totally flat is a main culprit). If I had access to a clean room to do the splatter and scanning then I reckon I could get a reasonable level of accuracy, but as it is I'm not sure it's going to be possible. Many thanks for the suggestions and advice. -- Matthew Moore Surgical Materials Testing Laboratory System Administrator Telephone: +44 (0)1656 752165 Email: [hidden email] -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
4 posts
|
In reply to this post by Gabriel Landini
On 02/08/12 11:06, Gabriel Landini wrote:
>> The main problem is that the 'Make binary' that you have to use before >> running the particle analyzer introduces lots of noise into the image, >> so it picks up lots of false positives. > In that case you could process the image before thresholding or after. > > Before: there are many filters that you can try: smoothing (mean, Gaussian), > median, morphological (greyscale closing/opening). > > During: you could to try different methods for the actual thresholding step > (and IJ supports quite a few) or some other pixel classification. > > After: binary closing/opening, filter by size, opening and closing by > reconstruction, median, etc. > > You need to be aware that by any of that processing, you are changing the > original data. > >> The dots are quite obvious really, it's a plain white >> piece of paper with black blobs on it. > I guess that probably the dots are not the problem, but the image or > background is not completely white, and the thresholding level that you are > using picks some of that intensity variation as "object". ... [show rest of quote] If I were to send some sample images over is there anyone on the list who might be able to take a look at them and see if they might be able to suggest a suitable set of thresholds/filters etc? I've been slowly working through a massive combination of filters and settings, to try and improve accuracy, but have had no success so far. Thanks, Matt -- Matthew Moore Surgical Materials Testing Laboratory System Administrator Telephone: +44 (0)1656 752165 Email: [hidden email] -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
25 posts
|
2012/8/7 Matthew Moore <[hidden email]>:
> If I were to send some sample images over is there anyone on the list > who might be able to take a look at them and see if they might be able > to suggest a suitable set of thresholds/filters etc? I would be happy to try, but don't expect much from my limited experience :) Best, Volker -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Free forum by Nabble | Disable Popup Ads | Edit this page |