BoneJ Analyze Skeleton on Skeletons with >32766 components?

[Simon_Carr]

Dear All,

I am using BoneJ to undertake pore analysis of soils and sediments, but keep coming up against the Java limit of a maximum of 32,766 components. Unfortunately, my samples have populations of pores to be measured in the order of ~120,000 components, some of which extend right through the CT volume that has been scanned. Whilst I appreciate that I can sub-sample each volume into smaller pieces that bring the component number below the magic number, I am aware that this is compromising the quality of the analysis, because numerous large pore networks that extend as a single network through the whole volume are being split into perhaps four (or more) skeletons for subsequent analysis.

Can anyone advise whether there is a way to get around the Java-imposed limit on my volumes?

Regards,

Simon
_________________________________
Dr Simon Carr
School of Geography,
Queen Mary University of London,
Mile End Road, London, E1 4NS, UK.
t: 00 44 20 7882 2780
f: 00 44 20 8981 6276
e: [hidden email]<mailto:[hidden email]>
twitter: @DrSimonCarr








--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Ignacio Arganda-Carreras]

Hello Simon,

This limitation comes from the fact that I used a "short" image to store
the labeled skeletons in AnalzyeSkeleton. If you have some coding
experience you can easily create your own version of the plugin to use
Float instead of Short pixel values. That should make the trick.

In any case, I will talk to Michael Doube (BoneJ maintainer) to see if we
also add that change to our released version.

Best regards,

ignacio

On Mon, Oct 6, 2014 at 10:31 PM, Simon Carr <[hidden email]> wrote:

> Dear All,
>
> I am using BoneJ to undertake pore analysis of soils and sediments, but
> keep coming up against the Java limit of a maximum of 32,766 components.
> Unfortunately, my samples have populations of pores to be measured in the
> order of ~120,000 components, some of which extend right through the CT
> volume that has been scanned. Whilst I appreciate that I can sub-sample
> each volume into smaller pieces that bring the component number below the
> magic number, I am aware that this is compromising the quality of the
> analysis, because numerous large pore networks that extend as a single
> network through the whole volume are being split into perhaps four (or
> more) skeletons for subsequent analysis.
>
> Can anyone advise whether there is a way to get around the Java-imposed
> limit on my volumes?
>
> Regards,
>
> Simon
> _________________________________
> Dr Simon Carr
> School of Geography,
> Queen Mary University of London,
> Mile End Road, London, E1 4NS, UK.
> t: 00 44 20 7882 2780
> f: 00 44 20 8981 6276
> e: [hidden email]<mailto:[hidden email]>
> twitter: @DrSimonCarr
>
>
>
>
>
>
>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
Ignacio Arganda-Carreras, Ph.D.
Seung's lab, 46-5065
Department of Brain and Cognitive Sciences
Massachusetts Institute of Technology
43 Vassar St.
Cambridge, MA 02139
USA

Phone: [phone]
Website: http://bioweb.cnb.csic.es/~iarganda/index_EN.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[karo03]

Hi, just one shart remark to "use Float instead" for label image data!

Don't do that! For larger label numbers you will struggle around with float rounding errors, hence mislabelling problems. The latter will need more time to overcome! I don't know Java enough, but Long is much better than float.

Karsten

Am 07.10.2014 um 10:08 schrieb Ignacio Arganda-Carreras <[hidden email]>:

> Hello Simon,
>
> This limitation comes from the fact that I used a "short" image to store
> the labeled skeletons in AnalzyeSkeleton. If you have some coding
> experience you can easily create your own version of the plugin to use
> Float instead of Short pixel values. That should make the trick.
>
> In any case, I will talk to Michael Doube (BoneJ maintainer) to see if we
> also add that change to our released version.
>
> Best regards,
>
> ignacio
>
> On Mon, Oct 6, 2014 at 10:31 PM, Simon Carr <[hidden email]> wrote:
>
>> Dear All,
>>
>> I am using BoneJ to undertake pore analysis of soils and sediments, but
>> keep coming up against the Java limit of a maximum of 32,766 components.
>> Unfortunately, my samples have populations of pores to be measured in the
>> order of ~120,000 components, some of which extend right through the CT
>> volume that has been scanned. Whilst I appreciate that I can sub-sample
>> each volume into smaller pieces that bring the component number below the
>> magic number, I am aware that this is compromising the quality of the
>> analysis, because numerous large pore networks that extend as a single
>> network through the whole volume are being split into perhaps four (or
>> more) skeletons for subsequent analysis.
>>
>> Can anyone advise whether there is a way to get around the Java-imposed
>> limit on my volumes?
>>
>> Regards,
>>
>> Simon
>> _________________________________
>> Dr Simon Carr
>> School of Geography,
>> Queen Mary University of London,
>> Mile End Road, London, E1 4NS, UK.
>> t: 00 44 20 7882 2780
>> f: 00 44 20 8981 6276
>> e: [hidden email]<mailto:[hidden email]>
>> twitter: @DrSimonCarr
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>
>
>
> --
> Ignacio Arganda-Carreras, Ph.D.
> Seung's lab, 46-5065
> Department of Brain and Cognitive Sciences
> Massachusetts Institute of Technology
> 43 Vassar St.
> Cambridge, MA 02139
> USA
>
> Phone: [phone]
> Website: http://bioweb.cnb.csic.es/~iarganda/index_EN.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Simon_Carr]

Dear Iganico and Karsten,

Thanks for the responses: I’m a coding virgin unfortunately, so have no idea where to begin in terms of revising the plugin. I guess I will just have to await an ‘official’ workaround. However, I’m glad to hear that this may be something that could happen relatively soon.

Regards,

Simon
_________________________________
Dr Simon Carr
School of Geography,
Queen Mary University of London,
Mile End Road, London, E1 4NS, UK.
t: 00 44 20 7882 2780
f: 00 44 20 8981 6276
e: [hidden email]<mailto:[hidden email]>
twitter: @DrSimonCarr







On 7 Oct 2014, at 10:34, Karsten <[hidden email]<mailto:[hidden email]>> wrote:

Hi, just one shart remark to "use Float instead" for label image data!

Don't do that! For larger label numbers you will struggle around with float rounding errors, hence mislabelling problems. The latter will need more time to overcome! I don't know Java enough, but Long is much better than float.

Karsten

Am 07.10.2014 um 10:08 schrieb Ignacio Arganda-Carreras <[hidden email]<mailto:[hidden email]>>:

Hello Simon,

This limitation comes from the fact that I used a "short" image to store
the labeled skeletons in AnalzyeSkeleton. If you have some coding
experience you can easily create your own version of the plugin to use
Float instead of Short pixel values. That should make the trick.

In any case, I will talk to Michael Doube (BoneJ maintainer) to see if we
also add that change to our released version.

Best regards,

ignacio

On Mon, Oct 6, 2014 at 10:31 PM, Simon Carr <[hidden email]<mailto:[hidden email]>> wrote:

Dear All,

I am using BoneJ to undertake pore analysis of soils and sediments, but
keep coming up against the Java limit of a maximum of 32,766 components.
Unfortunately, my samples have populations of pores to be measured in the
order of ~120,000 components, some of which extend right through the CT
volume that has been scanned. Whilst I appreciate that I can sub-sample
each volume into smaller pieces that bring the component number below the
magic number, I am aware that this is compromising the quality of the
analysis, because numerous large pore networks that extend as a single
network through the whole volume are being split into perhaps four (or
more) skeletons for subsequent analysis.

Can anyone advise whether there is a way to get around the Java-imposed
limit on my volumes?

Regards,

Simon
_________________________________
Dr Simon Carr
School of Geography,
Queen Mary University of London,
Mile End Road, London, E1 4NS, UK.
t: 00 44 20 7882 2780
f: 00 44 20 8981 6276
e: [hidden email]<mailto:[hidden email]><mailto:[hidden email]>
twitter: @DrSimonCarr








--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html




--
Ignacio Arganda-Carreras, Ph.D.
Seung's lab, 46-5065
Department of Brain and Cognitive Sciences
Massachusetts Institute of Technology
43 Vassar St.
Cambridge, MA 02139
USA

Phone: [phone]
Website: http://bioweb.cnb.csic.es/~iarganda/index_EN.html

--
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

[Michael Doube-4]

"int" will probably work, giving ~2 billion labels, for a cost of 2x data size over short. Although, IIRC in IJ1, int is interpreted as an RGB (+alpha) image. I'm pretty sure I've used float or double for labelling (integer numeric values) in the past with no particular problems, but will watch out since Karsten's warning!

Michael

On 07/10/14 10:34, Karsten wrote:

> Hi, just one shart remark to "use Float instead" for label image data!
>
> Don't do that! For larger label numbers you will struggle around with float rounding errors, hence mislabelling problems. The latter will need more time to overcome! I don't know Java enough, but Long is much better than float.
>
> Karsten
>
> Am 07.10.2014 um 10:08 schrieb Ignacio Arganda-Carreras <[hidden email]>:
>
>> Hello Simon,
>>
>> This limitation comes from the fact that I used a "short" image to store
>> the labeled skeletons in AnalzyeSkeleton. If you have some coding
>> experience you can easily create your own version of the plugin to use
>> Float instead of Short pixel values. That should make the trick.
>>
>> In any case, I will talk to Michael Doube (BoneJ maintainer) to see if we
>> also add that change to our released version.
>>
>> Best regards,
>>
>> ignacio
>>
>> On Mon, Oct 6, 2014 at 10:31 PM, Simon Carr <[hidden email]> wrote:
>>
>>> Dear All,
>>>
>>> I am using BoneJ to undertake pore analysis of soils and sediments, but
>>> keep coming up against the Java limit of a maximum of 32,766 components.
>>> Unfortunately, my samples have populations of pores to be measured in the
>>> order of ~120,000 components, some of which extend right through the CT
>>> volume that has been scanned. Whilst I appreciate that I can sub-sample
>>> each volume into smaller pieces that bring the component number below the
>>> magic number, I am aware that this is compromising the quality of the
>>> analysis, because numerous large pore networks that extend as a single
>>> network through the whole volume are being split into perhaps four (or
>>> more) skeletons for subsequent analysis.
>>>
>>> Can anyone advise whether there is a way to get around the Java-imposed
>>> limit on my volumes?
>>>
>>> Regards,
>>>
>>> Simon
>>> _________________________________
>>> Dr Simon Carr
>>> School of Geography,
>>> Queen Mary University of London,
>>> Mile End Road, London, E1 4NS, UK.
>>> t: 00 44 20 7882 2780
>>> f: 00 44 20 8981 6276
>>> e: [hidden email]<mailto:[hidden email]>
>>> twitter: @DrSimonCarr
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>
>>
>>
>>
>> --
>> Ignacio Arganda-Carreras, Ph.D.
>> Seung's lab, 46-5065
>> Department of Brain and Cognitive Sciences
>> Massachusetts Institute of Technology
>> 43 Vassar St.
>> Cambridge, MA 02139
>> USA
>>
>> Phone: [phone]
>> Website: http://bioweb.cnb.csic.es/~iarganda/index_EN.html
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

<http://www.rvc.ac.uk>

This message, together with any attachments, is intended for the stated addressee(s) only and may contain privileged or confidential information. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Royal Veterinary College.

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Doube-4]

> I'm pretty sure I've used float or double for labelling (integer numeric values) in the past with no particular problems, but will watch out since Karsten's warning!

Karsten is correct, integers above 2^24 (a bit more than 16 million) are
not precisely represented by float. See e.g. this:

http://www.ibm.com/developerworks/java/library/j-math2/index.html

So I added a little warning to the 3D particle analyser's label image
output, in case users are measuring this many (!!) particles in their
image stacks (the analysis itself runs on an int[][] array so will be OK
up to 2^31 - 1 particles, it's just the image display which uses a
float). Perhaps a similar approach might be reasonable for Analyze Skeleton?

Michael


[RVC Logo - link to RVC Website]<http://www.rvc.ac.uk>    [Twitter icon - link to RVC (Official) Twitter] <http://twitter.com/RoyalVetCollege>     [Facebook icon - link to RVC (Official) Facebook] <http://www.facebook.com/theRVC>     [YouTube icon - link to RVC YouTube] <http://www.youtube.com/user/RoyalVetsLondon?feature=mhee>     [Pinterest icon - link to RVC Pinterest] <http://pinterest.com/royalvetcollege/>     [Instagram icon - link to RVC Instagram] <http://instagram.com/royalvetcollege>

This message, together with any attachments, is intended for the stated addressee(s) only and may contain privileged or confidential information. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Royal Veterinary College (RVC). If you are not the intended recipient, please notify the sender and be advised that you have received this message in error and that any use, dissemination, forwarding, printing, or copying is strictly prohibited. Unless stated expressly in this email, this email does not create, form part of, or vary any contractual or unilateral obligation. Email communication cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, amended, lost, destroyed, incomplete or contain viruses. Therefore, we do not accept liability for any such matters or their consequences. Communication with us by email will be taken as acceptance of the risks inherent in doing so.

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Ignacio Arganda-Carreras]

Sounds good to me!

On Wed, Oct 8, 2014 at 12:34 AM, Doube, Michael <[hidden email]> wrote:

>
>
>
> > I'm pretty sure I've used float or double for labelling (integer numeric
> values) in the past with no particular problems, but will watch out since
> Karsten's warning!
>
> Karsten is correct, integers above 2^24 (a bit more than 16 million) are
> not precisely represented by float. See e.g. this:
>
> http://www.ibm.com/developerworks/java/library/j-math2/index.html
>
> So I added a little warning to the 3D particle analyser's label image
> output, in case users are measuring this many (!!) particles in their
> image stacks (the analysis itself runs on an int[][] array so will be OK
> up to 2^31 - 1 particles, it's just the image display which uses a
> float). Perhaps a similar approach might be reasonable for Analyze
> Skeleton?
>
> Michael
>
>
> [RVC Logo - link to RVC Website]<http://www.rvc.ac.uk>    [Twitter icon -
> link to RVC (Official) Twitter] <http://twitter.com/RoyalVetCollege>
>  [Facebook icon - link to RVC (Official) Facebook] <
> http://www.facebook.com/theRVC>     [YouTube icon - link to RVC YouTube] <
> http://www.youtube.com/user/RoyalVetsLondon?feature=mhee>     [Pinterest
> icon - link to RVC Pinterest] <http://pinterest.com/royalvetcollege/>
>  [Instagram icon - link to RVC Instagram] <
> http://instagram.com/royalvetcollege>
>
> This message, together with any attachments, is intended for the stated
> addressee(s) only and may contain privileged or confidential information.
> Any views or opinions presented are solely those of the author and do not
> necessarily represent those of the Royal Veterinary College (RVC). If you
> are not the intended recipient, please notify the sender and be advised
> that you have received this message in error and that any use,
> dissemination, forwarding, printing, or copying is strictly prohibited.
> Unless stated expressly in this email, this email does not create, form
> part of, or vary any contractual or unilateral obligation. Email
> communication cannot be guaranteed to be secure or error free as
> information could be intercepted, corrupted, amended, lost, destroyed,
> incomplete or contain viruses. Therefore, we do not accept liability for
> any such matters or their consequences. Communication with us by email will
> be taken as acceptance of the risks inherent in doing so.
>

--
Ignacio Arganda-Carreras, Ph.D.
Seung's lab, 46-5065
Department of Brain and Cognitive Sciences
Massachusetts Institute of Technology
43 Vassar St.
Cambridge, MA 02139
USA

Phone: [phone]
Website: http://bioweb.cnb.csic.es/~iarganda/index_EN.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[karo03]

The problem with unique integers represented as float numbers starts much earlier. You should not have more than 5 decimals at maximum to be sure not to have mix-ups of labels. The problem is that there is always a conversion from float to int using numbers as labels!
Karsten

Am 08.10.2014 um 00:34 schrieb Doube, Michael <[hidden email]>:

> integers above 2^24 (a bit more than 16 million) are
> not precisely represented by float. See e.g. this:
>
> http://www.ibm.com/developerworks/java/library/j-math2/index.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Ignacio Arganda-Carreras]

OK, I have just updated the code so the labels are integers (converted to
floats). You can get the latest release by updating Fiji or downloading the
jar from here:

https://github.com/fiji/AnalyzeSkeleton/releases/tag/v2.0.1

Cheers!

On Wed, Oct 8, 2014 at 9:46 AM, Karsten <[hidden email]> wrote:

> The problem with unique integers represented as float numbers starts much
> earlier. You should not have more than 5 decimals at maximum to be sure not
> to have mix-ups of labels. The problem is that there is always a conversion
> from float to int using numbers as labels!
> Karsten
>
> Am 08.10.2014 um 00:34 schrieb Doube, Michael <[hidden email]>:
>
> > integers above 2^24 (a bit more than 16 million) are
> > not precisely represented by float. See e.g. this:
> >
> > http://www.ibm.com/developerworks/java/library/j-math2/index.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
Ignacio Arganda-Carreras, Ph.D.
Seung's lab, 46-5065
Department of Brain and Cognitive Sciences
Massachusetts Institute of Technology
43 Vassar St.
Cambridge, MA 02139
USA

Phone: [phone]
Website: http://bioweb.cnb.csic.es/~iarganda/index_EN.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Simon_Carr]

Dear Ignacio,

This is fantastic, THANK-YOU! I'm in the middle of writing a paper at the moment, but I will download the update later today and see how it gets on.

However, thank-you so much for being so responsive and updating the code so rapidly: it is very much appreciated.

Regards,

Simon

Dr Simon Carr
School of Geography
Queen Mary University of London
Mile End Road
London E1 4NS
T: 020 7882 2780
F:
Twitter: @drsimoncarr

> On 13 Oct 2014, at 10:13, Ignacio Arganda-Carreras <[hidden email]> wrote:
>
> OK, I have just updated the code so the labels are integers (converted to
> floats). You can get the latest release by updating Fiji or downloading the
> jar from here:
>
> https://github.com/fiji/AnalyzeSkeleton/releases/tag/v2.0.1
>
> Cheers!
>
>> On Wed, Oct 8, 2014 at 9:46 AM, Karsten <[hidden email]> wrote:
>>
>> The problem with unique integers represented as float numbers starts much
>> earlier. You should not have more than 5 decimals at maximum to be sure not
>> to have mix-ups of labels. The problem is that there is always a conversion
>> from float to int using numbers as labels!
>> Karsten
>>
>>> Am 08.10.2014 um 00:34 schrieb Doube, Michael <[hidden email]>:
>>>
>>> integers above 2^24 (a bit more than 16 million) are
>>> not precisely represented by float. See e.g. this:
>>>
>>> http://www.ibm.com/developerworks/java/library/j-math2/index.html
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>
>
>
> --
> Ignacio Arganda-Carreras, Ph.D.
> Seung's lab, 46-5065
> Department of Brain and Cognitive Sciences
> Massachusetts Institute of Technology
> 43 Vassar St.
> Cambridge, MA 02139
> USA
>
> Phone: [phone]
> Website: http://bioweb.cnb.csic.es/~iarganda/index_EN.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Ignacio Arganda-Carreras]

No problem. Thank you for reporting!

On Mon, Oct 13, 2014 at 11:34 AM, Simon Carr <[hidden email]> wrote:

> Dear Ignacio,
>
> This is fantastic, THANK-YOU! I'm in the middle of writing a paper at the
> moment, but I will download the update later today and see how it gets on.
>
> However, thank-you so much for being so responsive and updating the code
> so rapidly: it is very much appreciated.
>
> Regards,
>
> Simon
>
> Dr Simon Carr
> School of Geography
> Queen Mary University of London
> Mile End Road
> London E1 4NS
> T: 020 7882 2780
> F:
> Twitter: @drsimoncarr
>
> > On 13 Oct 2014, at 10:13, Ignacio Arganda-Carreras <
> [hidden email]> wrote:
> >
> > OK, I have just updated the code so the labels are integers (converted to
> > floats). You can get the latest release by updating Fiji or downloading
> the
> > jar from here:
> >
> > https://github.com/fiji/AnalyzeSkeleton/releases/tag/v2.0.1
> >
> > Cheers!
> >
> >> On Wed, Oct 8, 2014 at 9:46 AM, Karsten <[hidden email]> wrote:
> >>
> >> The problem with unique integers represented as float numbers starts
> much
> >> earlier. You should not have more than 5 decimals at maximum to be sure
> not
> >> to have mix-ups of labels. The problem is that there is always a
> conversion
> >> from float to int using numbers as labels!
> >> Karsten
> >>
> >>> Am 08.10.2014 um 00:34 schrieb Doube, Michael <[hidden email]>:
> >>>
> >>> integers above 2^24 (a bit more than 16 million) are
> >>> not precisely represented by float. See e.g. this:
> >>>
> >>> http://www.ibm.com/developerworks/java/library/j-math2/index.html
> >>
> >> --
> >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >>
> >
> >
> >
> > --
> > Ignacio Arganda-Carreras, Ph.D.
> > Seung's lab, 46-5065
> > Department of Brain and Cognitive Sciences
> > Massachusetts Institute of Technology
> > 43 Vassar St.
> > Cambridge, MA 02139
> > USA
> >
> > Phone: [phone]
> > Website: http://bioweb.cnb.csic.es/~iarganda/index_EN.html
> >
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
Ignacio Arganda-Carreras, Ph.D.
Seung's lab, 46-5065
Department of Brain and Cognitive Sciences
Massachusetts Institute of Technology
43 Vassar St.
Cambridge, MA 02139
USA

Phone: [phone]
Website: http://bioweb.cnb.csic.es/~iarganda/index_EN.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Doube-4]

I've incorporated Ignacio's changes into BoneJ:

http://bonej.org/download/testing/BoneJ_.jar

Michael

On 13/10/14 10:13, Ignacio Arganda-Carreras wrote:

> OK, I have just updated the code so the labels are integers (converted to
> floats). You can get the latest release by updating Fiji or downloading the
> jar from here:
>
> https://github.com/fiji/AnalyzeSkeleton/releases/tag/v2.0.1
>
> Cheers!
>
> On Wed, Oct 8, 2014 at 9:46 AM, Karsten <[hidden email]> wrote:
>
>> The problem with unique integers represented as float numbers starts much
>> earlier. You should not have more than 5 decimals at maximum to be sure not
>> to have mix-ups of labels. The problem is that there is always a conversion
>> from float to int using numbers as labels!
>> Karsten
>>
>> Am 08.10.2014 um 00:34 schrieb Doube, Michael <[hidden email]>:
>>
>>> integers above 2^24 (a bit more than 16 million) are
>>> not precisely represented by float. See e.g. this:
>>>
>>> http://www.ibm.com/developerworks/java/library/j-math2/index.html
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>

<http://www.rvc.ac.uk>

This message, together with any attachments, is intended for the stated addressee(s) only and may contain privileged or confidential information. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Royal Veterinary College.

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Jan Eglinger]

Hi Ignacio,

On 13.10.14 11:00, Ignacio Arganda-Carreras wrote:
> OK, I have just updated the code so the labels are integers (converted to
> floats).

Now I get the stack trace pasted below when running AnalyzeSkeleton_.run.
I think the problem is caused by `treeIS` containing FloatProcessors
since your recent commit:
https://github.com/fiji/AnalyzeSkeleton/commit/ec7bfcf0
but `getShortPixel()` wants to cast them to Short.

Many greetings,
Jan


(Fiji Is Just) ImageJ 2.0.0-rc-15/1.49i; Java 1.6.0_65 [64-bit]; Mac OS
X 10.9.5; 45MB of 4075MB (1%)

java.lang.ClassCastException: [F cannot be cast to [S
        at
skeleton_analysis.AnalyzeSkeleton_.getShortPixel(AnalyzeSkeleton_.java:2900)
        at
skeleton_analysis.AnalyzeSkeleton_.getShortPixel(AnalyzeSkeleton_.java:2914)
        at
skeleton_analysis.AnalyzeSkeleton_.divideVoxelsByTrees(AnalyzeSkeleton_.java:1210)
        at
skeleton_analysis.AnalyzeSkeleton_.processSkeleton(AnalyzeSkeleton_.java:903)
        at skeleton_analysis.AnalyzeSkeleton_.run(AnalyzeSkeleton_.java:367)
        at
sprouting.Sprout_Analyzer.analyzeSproutSkeleton(Sprout_Analyzer.java:885)
        at sprouting.Sprout_Analyzer.processAndShow(Sprout_Analyzer.java:590)
        at sprouting.Sprout_Analyzer.run(Sprout_Analyzer.java:442)
        at
ij.plugin.filter.PlugInFilterRunner.processOneImage(PlugInFilterRunner.java:262)
        at ij.plugin.filter.PlugInFilterRunner.<init>(PlugInFilterRunner.java:111)
        at ij.IJ.runUserPlugIn(IJ.java:204)
        at ij.IJ.runPlugIn(IJ.java:166)
        at ij.Executer.runCommand(Executer.java:131)
        at ij.Executer.run(Executer.java:64)
        at java.lang.Thread.run(Thread.java:695)

>
> On Wed, Oct 8, 2014 at 9:46 AM, Karsten <[hidden email]> wrote:
>
>> The problem with unique integers represented as float numbers starts much
>> earlier. You should not have more than 5 decimals at maximum to be sure not
>> to have mix-ups of labels. The problem is that there is always a conversion
>> from float to int using numbers as labels!
>> Karsten
>>
>> Am 08.10.2014 um 00:34 schrieb Doube, Michael <[hidden email]>:
>>
>>> integers above 2^24 (a bit more than 16 million) are
>>> not precisely represented by float. See e.g. this:
>>>
>>> http://www.ibm.com/developerworks/java/library/j-math2/index.html
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>
>
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Ignacio Arganda-Carreras]

You're right. I just fixed it and released a new jar.

Thanks for reporting!

ignacio

On Tue, Oct 14, 2014 at 11:29 AM, Jan Eglinger <[hidden email]>
wrote:

> Hi Ignacio,
>
> On 13.10.14 11:00, Ignacio Arganda-Carreras wrote:
>
>> OK, I have just updated the code so the labels are integers (converted to
>> floats).
>>
>
> Now I get the stack trace pasted below when running AnalyzeSkeleton_.run.
> I think the problem is caused by `treeIS` containing FloatProcessors since
> your recent commit:
> https://github.com/fiji/AnalyzeSkeleton/commit/ec7bfcf0
> but `getShortPixel()` wants to cast them to Short.
>
> Many greetings,
> Jan
>
>
> (Fiji Is Just) ImageJ 2.0.0-rc-15/1.49i; Java 1.6.0_65 [64-bit]; Mac OS X
> 10.9.5; 45MB of 4075MB (1%)
>
> java.lang.ClassCastException: [F cannot be cast to [S
>         at skeleton_analysis.AnalyzeSkeleton_.
> getShortPixel(AnalyzeSkeleton_.java:2900)
>         at skeleton_analysis.AnalyzeSkeleton_.
> getShortPixel(AnalyzeSkeleton_.java:2914)
>         at skeleton_analysis.AnalyzeSkeleton_.divideVoxelsByTrees(
> AnalyzeSkeleton_.java:1210)
>         at skeleton_analysis.AnalyzeSkeleton_.processSkeleton(
> AnalyzeSkeleton_.java:903)
>         at skeleton_analysis.AnalyzeSkeleton_.run(
> AnalyzeSkeleton_.java:367)
>         at sprouting.Sprout_Analyzer.analyzeSproutSkeleton(Sprout_
> Analyzer.java:885)
>         at sprouting.Sprout_Analyzer.processAndShow(Sprout_
> Analyzer.java:590)
>         at sprouting.Sprout_Analyzer.run(Sprout_Analyzer.java:442)
>         at ij.plugin.filter.PlugInFilterRunner.processOneImage(
> PlugInFilterRunner.java:262)
>         at ij.plugin.filter.PlugInFilterRunner.<init>(
> PlugInFilterRunner.java:111)
>         at ij.IJ.runUserPlugIn(IJ.java:204)
>         at ij.IJ.runPlugIn(IJ.java:166)
>         at ij.Executer.runCommand(Executer.java:131)
>         at ij.Executer.run(Executer.java:64)
>         at java.lang.Thread.run(Thread.java:695)
>
>
>
>
>
>> On Wed, Oct 8, 2014 at 9:46 AM, Karsten <[hidden email]> wrote:
>>
>>  The problem with unique integers represented as float numbers starts much
>>> earlier. You should not have more than 5 decimals at maximum to be sure
>>> not
>>> to have mix-ups of labels. The problem is that there is always a
>>> conversion
>>> from float to int using numbers as labels!
>>> Karsten
>>>
>>> Am 08.10.2014 um 00:34 schrieb Doube, Michael <[hidden email]>:
>>>
>>>  integers above 2^24 (a bit more than 16 million) are
>>>> not precisely represented by float. See e.g. this:
>>>>
>>>> http://www.ibm.com/developerworks/java/library/j-math2/index.html
>>>>
>>>
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>
>>>
>>
>>
>>

--
Ignacio Arganda-Carreras, Ph.D.
Seung's lab, 46-5065
Department of Brain and Cognitive Sciences
Massachusetts Institute of Technology
43 Vassar St.
Cambridge, MA 02139
USA

Phone: [phone]
Website: http://bioweb.cnb.csic.es/~iarganda/index_EN.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Jan Eglinger]

Hi Ignacio,

you were so fast, it's amazing!
Thanks a lot, I tested it and it works as expected now.

:)
Jan


On 14.10.14 11:56, Ignacio Arganda-Carreras wrote:

> You're right. I just fixed it and released a new jar.
>
> Thanks for reporting!
>
> ignacio
>
> On Tue, Oct 14, 2014 at 11:29 AM, Jan Eglinger <[hidden email]>
> wrote:
>
>> Hi Ignacio,
>>
>> On 13.10.14 11:00, Ignacio Arganda-Carreras wrote:
>>
>>> OK, I have just updated the code so the labels are integers (converted to
>>> floats).
>>>
>>
>> Now I get the stack trace pasted below when running AnalyzeSkeleton_.run.
>> I think the problem is caused by `treeIS` containing FloatProcessors since
>> your recent commit:
>> https://github.com/fiji/AnalyzeSkeleton/commit/ec7bfcf0
>> but `getShortPixel()` wants to cast them to Short.
>>
>> Many greetings,
>> Jan
>>
>>
>> (Fiji Is Just) ImageJ 2.0.0-rc-15/1.49i; Java 1.6.0_65 [64-bit]; Mac OS X
>> 10.9.5; 45MB of 4075MB (1%)
>>
>> java.lang.ClassCastException: [F cannot be cast to [S
>>          at skeleton_analysis.AnalyzeSkeleton_.
>> getShortPixel(AnalyzeSkeleton_.java:2900)
>>          at skeleton_analysis.AnalyzeSkeleton_.
>> getShortPixel(AnalyzeSkeleton_.java:2914)
>>          at skeleton_analysis.AnalyzeSkeleton_.divideVoxelsByTrees(
>> AnalyzeSkeleton_.java:1210)
>>          at skeleton_analysis.AnalyzeSkeleton_.processSkeleton(
>> AnalyzeSkeleton_.java:903)
>>          at skeleton_analysis.AnalyzeSkeleton_.run(
>> AnalyzeSkeleton_.java:367)
>>          at sprouting.Sprout_Analyzer.analyzeSproutSkeleton(Sprout_
>> Analyzer.java:885)
>>          at sprouting.Sprout_Analyzer.processAndShow(Sprout_
>> Analyzer.java:590)
>>          at sprouting.Sprout_Analyzer.run(Sprout_Analyzer.java:442)
>>          at ij.plugin.filter.PlugInFilterRunner.processOneImage(
>> PlugInFilterRunner.java:262)
>>          at ij.plugin.filter.PlugInFilterRunner.<init>(
>> PlugInFilterRunner.java:111)
>>          at ij.IJ.runUserPlugIn(IJ.java:204)
>>          at ij.IJ.runPlugIn(IJ.java:166)
>>          at ij.Executer.runCommand(Executer.java:131)
>>          at ij.Executer.run(Executer.java:64)
>>          at java.lang.Thread.run(Thread.java:695)
>>
>>
>>
>>
>>
>>> On Wed, Oct 8, 2014 at 9:46 AM, Karsten <[hidden email]> wrote:
>>>
>>>   The problem with unique integers represented as float numbers starts much
>>>> earlier. You should not have more than 5 decimals at maximum to be sure
>>>> not
>>>> to have mix-ups of labels. The problem is that there is always a
>>>> conversion
>>>> from float to int using numbers as labels!
>>>> Karsten
>>>>
>>>> Am 08.10.2014 um 00:34 schrieb Doube, Michael <[hidden email]>:
>>>>
>>>>   integers above 2^24 (a bit more than 16 million) are
>>>>> not precisely represented by float. See e.g. this:
>>>>>
>>>>> http://www.ibm.com/developerworks/java/library/j-math2/index.html
>>>>>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Simon_Carr]

Dear Ignacio,

Just to say a great big thank-you... Your revised code works just fine, and is generating my large datasets of void skeletons just perfectly!

Regards,

Simon

Dr Simon Carr
School of Geography
Queen Mary University of London
Mile End Road
London E1 4NS
T: 020 7882 2780
F:
Twitter: @drsimoncarr

> On 14 Oct 2014, at 15:54, Jan Eglinger <[hidden email]> wrote:
>
> Hi Ignacio,
>
> you were so fast, it's amazing!
> Thanks a lot, I tested it and it works as expected now.
>
> :)
> Jan
>
>
>> On 14.10.14 11:56, Ignacio Arganda-Carreras wrote:
>> You're right. I just fixed it and released a new jar.
>>
>> Thanks for reporting!
>>
>> ignacio
>>
>> On Tue, Oct 14, 2014 at 11:29 AM, Jan Eglinger <[hidden email]>
>> wrote:
>>
>>> Hi Ignacio,
>>>
>>>> On 13.10.14 11:00, Ignacio Arganda-Carreras wrote:
>>>>
>>>> OK, I have just updated the code so the labels are integers (converted to
>>>> floats).
>>>>
>>>
>>> Now I get the stack trace pasted below when running AnalyzeSkeleton_.run.
>>> I think the problem is caused by `treeIS` containing FloatProcessors since
>>> your recent commit:
>>> https://github.com/fiji/AnalyzeSkeleton/commit/ec7bfcf0
>>> but `getShortPixel()` wants to cast them to Short.
>>>
>>> Many greetings,
>>> Jan
>>>
>>>
>>> (Fiji Is Just) ImageJ 2.0.0-rc-15/1.49i; Java 1.6.0_65 [64-bit]; Mac OS X
>>> 10.9.5; 45MB of 4075MB (1%)
>>>
>>> java.lang.ClassCastException: [F cannot be cast to [S
>>>         at skeleton_analysis.AnalyzeSkeleton_.
>>> getShortPixel(AnalyzeSkeleton_.java:2900)
>>>         at skeleton_analysis.AnalyzeSkeleton_.
>>> getShortPixel(AnalyzeSkeleton_.java:2914)
>>>         at skeleton_analysis.AnalyzeSkeleton_.divideVoxelsByTrees(
>>> AnalyzeSkeleton_.java:1210)
>>>         at skeleton_analysis.AnalyzeSkeleton_.processSkeleton(
>>> AnalyzeSkeleton_.java:903)
>>>         at skeleton_analysis.AnalyzeSkeleton_.run(
>>> AnalyzeSkeleton_.java:367)
>>>         at sprouting.Sprout_Analyzer.analyzeSproutSkeleton(Sprout_
>>> Analyzer.java:885)
>>>         at sprouting.Sprout_Analyzer.processAndShow(Sprout_
>>> Analyzer.java:590)
>>>         at sprouting.Sprout_Analyzer.run(Sprout_Analyzer.java:442)
>>>         at ij.plugin.filter.PlugInFilterRunner.processOneImage(
>>> PlugInFilterRunner.java:262)
>>>         at ij.plugin.filter.PlugInFilterRunner.<init>(
>>> PlugInFilterRunner.java:111)
>>>         at ij.IJ.runUserPlugIn(IJ.java:204)
>>>         at ij.IJ.runPlugIn(IJ.java:166)
>>>         at ij.Executer.runCommand(Executer.java:131)
>>>         at ij.Executer.run(Executer.java:64)
>>>         at java.lang.Thread.run(Thread.java:695)
>>>
>>>
>>>
>>>
>>>
>>>> On Wed, Oct 8, 2014 at 9:46 AM, Karsten <[hidden email]> wrote:
>>>>
>>>>  The problem with unique integers represented as float numbers starts much
>>>>> earlier. You should not have more than 5 decimals at maximum to be sure
>>>>> not
>>>>> to have mix-ups of labels. The problem is that there is always a
>>>>> conversion
>>>>> from float to int using numbers as labels!
>>>>> Karsten
>>>>>
>>>>> Am 08.10.2014 um 00:34 schrieb Doube, Michael <[hidden email]>:
>>>>>
>>>>>  integers above 2^24 (a bit more than 16 million) are
>>>>>> not precisely represented by float. See e.g. this:
>>>>>>
>>>>>> http://www.ibm.com/developerworks/java/library/j-math2/index.html
>>>>>>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Doube-4]

BoneJ (testing version) updated with this change too:

http://bonej.org/download/testing/BoneJ_.jar

(yes, one day we'll reuse and not copy-paste, I hope...)

Michael

On 14/10/14 22:20, Simon Carr wrote:

> Dear Ignacio,
>
> Just to say a great big thank-you... Your revised code works just fine, and is generating my large datasets of void skeletons just perfectly!
>
> Regards,
>
> Simon
>
> Dr Simon Carr
> School of Geography
> Queen Mary University of London
> Mile End Road
> London E1 4NS
> T: 020 7882 2780
> F:
> Twitter: @drsimoncarr
>
>> On 14 Oct 2014, at 15:54, Jan Eglinger <[hidden email]> wrote:
>>
>> Hi Ignacio,
>>
>> you were so fast, it's amazing!
>> Thanks a lot, I tested it and it works as expected now.
>>
>> :)
>> Jan
>>
>>
>>> On 14.10.14 11:56, Ignacio Arganda-Carreras wrote:
>>> You're right. I just fixed it and released a new jar.
>>>
>>> Thanks for reporting!
>>>
>>> ignacio
>>>
>>> On Tue, Oct 14, 2014 at 11:29 AM, Jan Eglinger <[hidden email]>
>>> wrote:
>>>
>>>> Hi Ignacio,
>>>>
>>>>> On 13.10.14 11:00, Ignacio Arganda-Carreras wrote:
>>>>>
>>>>> OK, I have just updated the code so the labels are integers (converted to
>>>>> floats).
>>>>>
>>>>
>>>> Now I get the stack trace pasted below when running AnalyzeSkeleton_.run.
>>>> I think the problem is caused by `treeIS` containing FloatProcessors since
>>>> your recent commit:
>>>> https://github.com/fiji/AnalyzeSkeleton/commit/ec7bfcf0
>>>> but `getShortPixel()` wants to cast them to Short.
>>>>
>>>> Many greetings,
>>>> Jan
>>>>
>>>>
>>>> (Fiji Is Just) ImageJ 2.0.0-rc-15/1.49i; Java 1.6.0_65 [64-bit]; Mac OS X
>>>> 10.9.5; 45MB of 4075MB (1%)
>>>>
>>>> java.lang.ClassCastException: [F cannot be cast to [S
>>>>         at skeleton_analysis.AnalyzeSkeleton_.
>>>> getShortPixel(AnalyzeSkeleton_.java:2900)
>>>>         at skeleton_analysis.AnalyzeSkeleton_.
>>>> getShortPixel(AnalyzeSkeleton_.java:2914)
>>>>         at skeleton_analysis.AnalyzeSkeleton_.divideVoxelsByTrees(
>>>> AnalyzeSkeleton_.java:1210)
>>>>         at skeleton_analysis.AnalyzeSkeleton_.processSkeleton(
>>>> AnalyzeSkeleton_.java:903)
>>>>         at skeleton_analysis.AnalyzeSkeleton_.run(
>>>> AnalyzeSkeleton_.java:367)
>>>>         at sprouting.Sprout_Analyzer.analyzeSproutSkeleton(Sprout_
>>>> Analyzer.java:885)
>>>>         at sprouting.Sprout_Analyzer.processAndShow(Sprout_
>>>> Analyzer.java:590)
>>>>         at sprouting.Sprout_Analyzer.run(Sprout_Analyzer.java:442)
>>>>         at ij.plugin.filter.PlugInFilterRunner.processOneImage(
>>>> PlugInFilterRunner.java:262)
>>>>         at ij.plugin.filter.PlugInFilterRunner.<init>(
>>>> PlugInFilterRunner.java:111)
>>>>         at ij.IJ.runUserPlugIn(IJ.java:204)
>>>>         at ij.IJ.runPlugIn(IJ.java:166)
>>>>         at ij.Executer.runCommand(Executer.java:131)
>>>>         at ij.Executer.run(Executer.java:64)
>>>>         at java.lang.Thread.run(Thread.java:695)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Wed, Oct 8, 2014 at 9:46 AM, Karsten <[hidden email]> wrote:
>>>>>
>>>>>  The problem with unique integers represented as float numbers starts much
>>>>>> earlier. You should not have more than 5 decimals at maximum to be sure
>>>>>> not
>>>>>> to have mix-ups of labels. The problem is that there is always a
>>>>>> conversion
>>>>>> from float to int using numbers as labels!
>>>>>> Karsten
>>>>>>
>>>>>> Am 08.10.2014 um 00:34 schrieb Doube, Michael <[hidden email]>:
>>>>>>
>>>>>>  integers above 2^24 (a bit more than 16 million) are
>>>>>>> not precisely represented by float. See e.g. this:
>>>>>>>
>>>>>>> http://www.ibm.com/developerworks/java/library/j-math2/index.html
>>>>>>>
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
Dr Michael Doube
BPhil BVSc PhD MRCVS
Lecturer, Comparative Biomedical Sciences
The Royal Veterinary College, University of London
London NW1 0TU
United Kingdom

[phone] (Internal: 5503)

<http://www.rvc.ac.uk>

This message, together with any attachments, is intended for the stated addressee(s) only and may contain privileged or confidential information. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Royal Veterinary College.

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html