[ImageJ-devel] Labeling - Revised Branch

[Tobias Pietzsch]

Hi,

On 03/20/2012 06:55 PM, Christian Dietz wrote:
> 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).

It would be great, if you could push this test to the 
"labeling-revised-revised" branch as a JUnit test, like Johannes proposed.

I guess it is likely, that your change of the Labeling-list index from
"N extends Number" to "int" increased performance. Maybe that levels out
the SamplerConverter overhead? I don't know, it's a possibility.


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

There is a solution to this now.
There is a method

public static < T > IterableInterval< T > iterable( final 
RandomAccessibleInterval< T > randomAccessibleInterval )

in Views.
It simply returns randomAccessibleInterval if it is an IterableInterval. 
Otherwise it is wrapped into a
IterableRandomAccessibleInterval.

So, one should now use this method, when one needs to make a
RandomAccessibleInterval iterable. If the Labeling has been constructed
with an Img, you will get the "native" Cursor.

best regards,
Tobias

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