[ImageJ-devel] Labeling - Revised Branch

Christian Dietz christian.dietz at uni-konstanz.de
Tue Mar 20 12:55:09 CDT 2012


Hi Tobi,

About the SamplerConverter:
this is only one method call more I guess? In the case of get() on the
cursor there is no overhead at all.
Anyway, I just tested it _very_ briefly using a Labeling with (Int.MAX_VALUE
/ 200) entries and iterated 10000 times over it using a Cursor with the
current Labeling and the revised-Labeling implementations.
There is really no difference in runtime (Average runtime in both cases ~66
seconds).


About RandomAccessibleInterval<? extends IntegerType<?>>:
Yes sure thats an good idea! But: shouldn't it still be an
IterableInterval<? extends IntegerType<?>>: In the case of an Img for
example, if I would create an IterableRandomAccessibleInterval<? extends
IntegerType<?>> using the Img as  RandomAccessibleInterval<? extends
IntegerType<?>> I would have a much slower cursor than the "native" Cursor
provided by the Img, right? If this is not the case it would be completely
fine to use a RandomAccessibleInterval<? extends IntegerType<?>> and create
the Cursor using IterableRandomAccessibleInterval<? extends IntegerType<?>>
then. 


Maybe we're completely wrong here ;)

Martin & Christian


-----Original Message-----
From: Tobias Pietzsch [mailto:pietzsch at mpi-cbg.de] 
Sent: Dienstag, 20. März 2012 17:27
To: Christian Dietz; martin.horn at uni-konstanz.de
Cc: ImageJ-devel
Subject: Re: [ImageJ-devel] Labeling - Revised Branch

On 03/20/2012 05:01 PM, Tobias Pietzsch wrote:
> The main point for you is, that now you can use "smaller" IntegerTypes
> (eg. Byte) to store the Labeling, so you save memory, right?
>
> That's cool, but it comes with the additional overhead of using a
> SamplerConverter for the Accessors. So you trade of memory vs
> computation time. Did you do any benchmarks to see how much
> runtime-overhead you have there?

An alternative way to achieve this would be to make LabelingType an 
interface a la
public interface LabelingType<T extends LabelingType<T> & Comparable<T>> 
extends NativeType<T>
and provide implementations mapping to different basic type arrays.

Did you consider this alternative?

best regards,
Tobias


>
>
> best regards,
> Tobias
>
>
> On 03/19/2012 10:05 PM, Christian Dietz wrote:
>> Hi Tobi & Lee,
>>
>> I created a new branch with some changes of Martin Horn and me
>> concerning the Labeling (labeling-revised).
>> Actually the we changed only a little.
>>
>> The main differences are:
>>
>> - Generic Labeling of any IntegerType (Bit, Byte, Short, Int and so on)
>>
>> - Labeling is not an Img<LabelingType<?>> anymore, but still
>> IterableInterval<LabelingType<?>> and RandomAccessible<LabelingType<?>>
>>
>> - The Labeling is created a little different now (Img<? extends
>> IntegerType<?>> is provided in the constructor as the storage).
>>
>> Please see this as some suggestions from our side and we are pretty sure
>> it's not perfect or even good ;) But maybe it's a good starting point
>> for some future discussions.
>>
>> Thank you for your comments in advance,
>>
>>
>> Martin & Christian :)
>>
>
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/listinfo/imagej-devel




More information about the ImageJ-devel mailing list