Re: BoneJ Analyze Skeleton on Skeletons with >32766 components?

Posted by Simon_Carr on
URL: http://imagej.273.s1.nabble.com/BoneJ-Analyze-Skeleton-on-Skeletons-with-32766-components-tp5009924p5010039.html

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