Questions about analyze particles

[Ruszkai Ákos]

Hello,

First of all, let me introduce myself: I'm Ruszkai Ákos, a Hungarian
graduate pharmacist student. I'm writing my thesis about "Image analysis in
medicine technology".
I'll compare two different softwares (ImagePro + and ImageJ), in their
features and the results they return. In the laboratory, we mainly use
ImagePro+,so I'd like to focus more on ImageJ.Though I've read the online
manual, I still have some questions about the process and the results that
ImageJ returns. This'll be a long post to read, so sorry about that.
First, I'd like to ask what's the best pick to install: daily builds, or
stable versions? I'm using ImageJ on Debian testing, so I'm not unfamiliar
with handling with bugs and problem solving, in case things go wrong. Until
today, I've used 1.43g (that was installed from debian repository), but I
could upgrade to 1.43l via the built-in upgrader.
My following questions are about the analysis, and the results it returns,
because some things are quite confusing.
To describe in short, I need to analyse medicine pellets from digital photos
my consultant has provided me from the lab. I need to measure their "shape
descriptors", and the basic parameters (area, centroid, Feret etc.) I'm not
sure whether is this a bug or a feature, but I've noticed that the results
do not follow each other exactly as they were selected in the Set
Measurements dialogue. For example, Feret has 5 columns to display the
results: Feret, FeretX, FeretY, FeretAngle, MinFeret. The problem is, that
the Slice results column comes in between Feret and FeretX. This is not a
real problem, but I think it would be easier to look at the results if they
were sorted. Is this a bug, or am I missing an option checked in?
To get the proper statistical results, I need to measure circa 250 pellets
for each test. I've found, that this task is very easily done with the
stacks feature. The ROIs are easy to edit too, in case there's a dirt in the
image, that the auto threshold can't detect. So in the end, I get a stack
with 10 images, and approx. 250 ROIs. While it's not necessary, but it would
be nice to look at and draw only the ROIs on each slice - I can't do this
with the "show all" function, because that'll draw all ROIs on the same
slice, and that provides a complete mess. Is it possible to draw  ROIs that
belong to a particular slice only?
My third question is the most serious one, as I just can't figure out how
the "Summarise" works in the Results table.
In the attached image, my problem is clear: it seems, that the results are
shifted after "Feret". There are two columns with "-" that creates this
problem. Ok, I can clear those and move the columns back to ther places in
OpenOffice Calc, you can see that in xls I've uploaded to:

http://akion.planetnexuiz.de/sote/thesis/full_results.xls

Look at the end of the results: where does that very last column come from
(in coumn X) ? I can't even see that in the Results table in ImageJ.
I hope my letter isn't that long, and I'm not asking too basic things.
Thank you for your support.

Best regards,

Ákos

[Gabriel Landini]

On Sunday 29 November 2009, you wrote:
> First, I'd like to ask what's the best pick to install: daily builds, or
> stable versions?

Hi,
That depends whether you want to have the latest bugfixes or not...
Working from older versions that have been fixed might not be a good idea.

>  I'm not sure whether is this a bug or a feature, but I've noticed that the
>  results do not follow each other exactly as they were selected in the Set
> Measurements dialogue.

You can avoid having the Slice column, by unchecking the "Stack Position" in
the Set Measurements dialog entry. Or maybe I misunderstood...do you want the
column in a different place?

> In the attached image, my problem is clear: it seems, that the results are
> shifted after "Feret". There are two columns with "-" that creates this
> problem. Ok, I can clear those and move the columns back to ther places in
> OpenOffice Calc, you can see that in xls I've uploaded to:
>
> http://akion.planetnexuiz.de/sote/thesis/full_results.xls
>
> Look at the end of the results: where does that very last column come from
> (in coumn X) ? I can't even see that in the Results table in ImageJ.
> I hope my letter isn't that long, and I'm not asking too basic things.

That seems to be because there are some extraneous data delimiters in your xls
file. I do not see column names delimited with double inverted commas in the
data files created from my install of IJ 1.43m3 (but they exist in the file
you linked).
Where are these delimieters coming from? As far as I know, the delimiter used
in IJ data files is the tab "\t" (i.e. 0x09) . Your file has 0x22 [the data]
0x22 and  0x09. It seems that loading this file creates other problems in Ooo
Calc because numbers are loaded as strings...

Of course I do not know what your comparison between packages is intending to
show, but be aware there are many different ways of encoding particle area &
perimeter, so different results across different programs do not mean
necessariily "incorrect results".
I wrote other 2 particle analyzer plugins for this reason (Particles8 and
Particles4 using Freeman's chain code method).
If you the Freeman papers and all the follow ups you will found out that this
has been researched quite extensively.
Finding out what algorithms are implemented in the different plugins will
avoid reinventing the wheel.
I hope it helps

G.

[Ruszkai Ákos]

2009/11/29 Gabriel Landini <[hidden email]>

> >do you want the
> column in a different place?
>

Exactly. I'd like to have it in the first rows. Imho that makes sence there.

> > In the attached image, my problem is clear: it seems, that the results
> are
> > shifted after "Feret". There are two columns with "-" that creates this
> > problem. Ok, I can clear those and move the columns back to ther places
> in
> > OpenOffice Calc, you can see that in xls I've uploaded to:
> >
> > http://akion.planetnexuiz.de/sote/thesis/full_results.xls
> >
> > Look at the end of the results: where does that very last column come
> from
> > (in coumn X) ? I can't even see that in the Results table in ImageJ.
> > I hope my letter isn't that long, and I'm not asking too basic things.
>
> That seems to be because there are some extraneous data delimiters in your
> xls
> file. I do not see column names delimited with double inverted commas in
> the
> data files created from my install of IJ 1.43m3 (but they exist in the file
> you linked).
> Where are these delimieters coming from? As far as I know, the delimiter
> used
> in IJ data files is the tab "\t" (i.e. 0x09) . Your file has 0x22 [the
> data]
> 0x22 and  0x09. It seems that loading this file creates other problems in
> Ooo
> Calc because numbers are loaded as strings...
>
> I don't understand fully this, but one thing is sure: even ImageJ produces

a bad table. Why's there a baln row with "-" in there anyway?



> Of course I do not know what your comparison between packages is intending
> to
> show, but be aware there are many different ways of encoding particle area
> &
> perimeter, so different results across different programs do not mean
> necessariily "incorrect results".
>

Yes, my thesis is not about which program gives back better results. It'll
focus more about the features, the usability, userfriendlyness etc. I won't
tell you a secret, that ImagePro+ costs a lot of money to use only on one
PC. ImageJ is free and opensource, (that gives me a huge thumbs up anyway),
so why don't use it if it has the features we need? Not to mention other
laboratories we keep contact use it too, so it might be easier to share our
results/methods if we'd use the same software.



> I wrote other 2 particle analyzer plugins for this reason (Particles8 and
> Particles4 using Freeman's chain code method).
> If you the Freeman papers and all the follow ups you will found out that
> this
> has been researched quite extensively.
>

I'll look into these, thank you.


> Finding out what algorithms are implemented in the different plugins will
> avoid reinventing the wheel.
>

That's why I already like ImageJ, as I can read the source of the plugins,
so I'll know what they do exactly.

Best regard:

Ákos

[Gabriel Landini]

On Sunday 29 November 2009 17:02:57 you wrote:

> > I don't understand fully this, but one thing is sure: even ImageJ
> > produces a bad table. Why's there a baln row with "-" in there anyway?

Well, the tables generated are fine here, only tab delimited (I tried it again
on a different computer with 1.43m1).
Are you absolutely sure that the table you uploaded was not opened in Ooo and
then saved again as a CSV file or similar? What it is strange is that some
number columns are delimited with 0x22 and some aren't. I do not see any of
this in the tables I generate.

Perhaps it is time to update the ij.jar file and see if you get tables without
extra delimiters.
Save the Results table and look at it with a hex editor (okteta or mc) to see
if you still get the 0x22 delimiters.
The file should start with a space (0x20) yours starts with 0x22.

Cheers

G.

[Ruszkai Ákos]

2009/11/29 Gabriel Landini <[hidden email]>

> On Sunday 29 November 2009 17:02:57 you wrote:
>


> >Are you absolutely sure that the table you uploaded was not opened in Ooo
> and
> then saved again as a CSV file or similar?


The file I've uploaded was indeed edited in Ooo. I can upload the original
too generated by ImageJ.
Though I still don't understand where that X column comes from. If that's
pure garbage, I'm fine with it.

>Save the Results table and look at it with a hex editor (okteta or mc) to
see
if you still get the 0x22 delimiters.

Done, ImageJ generates 0x20. Here's the file:
http://akion.planetnexuiz.de/sote/thesis/full_results_imagej.xls

Regards

Ákos

ps: any ideas on my other questions? :D

[Gabriel Landini]

Some more info on this issue.
The summary columns are not aligned correctly, when one selects to output the
Slice Position (because there is an extra column). If you do not do that, the
table is OK.

This is unrelated to the wrongly coded table, though.

Cheers

G.

[Gabriel Landini]

On Sunday 29 November 2009 18:51:26 you wrote:
> Though I still don't understand where that X column comes from. If that's
> pure garbage, I'm fine with it.

X and Y columns are the coordinates of the centroid, I think.

G.

[Ruszkai Ákos]

2009/11/29 Gabriel Landini <[hidden email]>

> On Sunday 29 November 2009 18:51:26 you wrote:
> > Though I still don't understand where that X column comes from. If that's
> > pure garbage, I'm fine with it.
>
> X and Y columns are the coordinates of the centroid, I think.
>
> G.
>
No, I was talking about the latest coulmn in Ooo, named X (A-X)

Regards

Ákos

[Wayne Rasband]

On Nov 29, 2009, at 1:53 PM, Gabriel Landini wrote:

> Some more info on this issue.
> The summary columns are not aligned correctly, when one selects to
> output the Slice Position (because there is an extra column). If you
> do not do that, the table is OK.

The v1.43m4 daily build fixes a bug that could cause the Results table  
to become scrambled when using Analyze>Summarize with "Stack Position"  
enabled in Analyze>Set Measurements. Being able to take advantage of  
bug fixes like this is one advantage of using the daily builds. The  
daily builds also have new features, such as the image overlays (added  
in 1.43k) required to use the new SIOX (Simple Interactive Object  
Extraction) plugin (http://rsb.info.nih.gov/ij/plugins/siox/).

-wayne

[Ruszkai Ákos]

Wayne Rasband wrote:

>
> The v1.43m4 daily build fixes a bug that could cause the Results table
> to become scrambled when using Analyze>Summarize with "Stack Position"
> enabled in Analyze>Set Measurements. Being able to take advantage of
> bug fixes like this is one advantage of using the daily builds. The
> daily builds also have new features, such as the image overlays (added
> in 1.43k) required to use the new SIOX (Simple Interactive Object
> Extraction) plugin (http://rsb.info.nih.gov/ij/plugins/siox/).
>
> -wayne
>

Hello

Thank you for the update/heads up, from now on, I'll regularly check the
daily builds.
After I've updated my ImageJ, it no longer shifts the results. This is
the good part.
The bad news is that it still produces that odd last column after
Summarise. It doesn't show up in ImageJ's Results table, however, it
shows up in Ooo Calc. Either with save to xls, or simply select all +
copy+paste. I can even find the strings in Octeta.
I realy wonder where that comes from, and what calculation produces
those values.

Regards

Ákos

[Ruszkai Ákos]

Hello,

Ok, so here's a quick update:
I couldn't sort out the problem, but I'm not even bothered by it
anymore. I've gone back o square one, and removed imagej completely, and
"installed" the platform independent version, and upgraded to latest
nightly build.
Voila, the misterious results are gone!
It seems like something is realy bugged with the debian package.
Thank you for your help.
Though I still haven't found and easy way for the other questions I've
had in my first post, so any suggestions on those issues are welcomed.
Also, is there a whislist somewhere?

Regards

Ákos

[Gluender-3]

Dear,

your conclusion is somehow standard, will say,
quite often strange IJ-behaviour is associated
with OS or Java problems and they have been
discussed on the list in one or the other
fashion...

With respect to the your still open question, and
I suspect it concerns ROI-handling, things may
turn out similar. Consequently, you may search
this list and realize that quite similar
questions have been posed and answered.

Please see:
<https://list.nih.gov/archives/imagej.html>

>Hello,
>
>Ok, so here's a quick update:
>I couldn't sort out the problem, but I'm not
>even bothered by it anymore. I've gone back o
>square one, and removed imagej completely, and
>"installed" the platform independent version,
>and upgraded to latest nightly build.
>Voila, the misterious results are gone!
>It seems like something is realy bugged with the debian package.
>Thank you for your help.
>Though I still haven't found and easy way for
>the other questions I've had in my first post,
>so any suggestions on those issues are welcomed.
>Also, is there a whislist somewhere?
>
>Regards
>
>Ákos

HTH
--

                   Herbie

          ------------------------
          <http://www.gluender.de>

[Szilvi Mezey]

Ákos,

you can find the ImageJ wishlist here:
http://imagejdocu.tudor.lu/doku.php?id=wishlist:start

Üdv,

Szilvi Mezey
Semmelweis University,
Budapest, Hungary

2009/11/30 Ruszkai Ákos <[hidden email]>

> Hello,
>
> Ok, so here's a quick update:
> I couldn't sort out the problem, but I'm not even bothered by it anymore.
> I've gone back o square one, and removed imagej completely, and "installed"
> the platform independent version, and upgraded to latest nightly build.
> Voila, the misterious results are gone!
> It seems like something is realy bugged with the debian package.
> Thank you for your help.
> Though I still haven't found and easy way for the other questions I've had
> in my first post, so any suggestions on those issues are welcomed.
> Also, is there a whislist somewhere?
>
> Regards
>
> Ákos
>
>

[Ruszkai Ákos]

Hello

>
> your conclusion is somehow standard, will say, quite often strange
> IJ-behaviour is associated with OS or Java problems and they have been
> discussed on the list in one or the other fashion...
>
> You know, I'm not realy surprised. Also don't forget: "debian testing" .
Things will be clear at once ;) </sarcasm>

you may search this list and realize that quite similar questions have been
> posed and answered.
>

It was on my to-do list, but thank you again :)

Regards

Ákos

[Ruszkai Ákos]

2009/11/30 Szilvi Mezey <[hidden email]>

>
>
> you can find the ImageJ wishlist here:
> http://imagejdocu.tudor.lu/doku.php?id=wishlist:start
>
>
Hello

Thank you very much! I'll experience more with the software, and after that,
I'll post my revolutionary ideas there ;)

Regards / Üdv

Ákos