[ImageJ-devel] OffsetImg

[Lee Kamentsky]

I have some code for the translation case - in 
net.imglib2.img.transform.ImgTranslationAdapter. It's ok if you 
implement it in views and tell me when you have. I'll remove my code and 
use yours.

On 6/3/2011 11:04 AM, Stephan Preibisch wrote:
> Hi Lee,
>
> I seems to me that representing it as a View is right thing to do as
> Johannes suggested. Views do not iterate yet, but they will in the future.
> So that is maybe the right time to implement it :)
>
> Tobias has his defense on Tuesday, I guess we could implement it
> afterwards...
>
> Would that be ok for you?
>
> Nice greetings,
> Steffi
>
>> Oops - doesn't quite work because the views deal with RandomAccessibles
>> or RandomAccess. I need one that works off of IterableIntervals and
>> Cursors. I think that an IterableInterval is a considerably constrained
>> case - you could translate it or reflect it or transpose axes, but very
>> little else (I don't think even periodic makes sense).
>>
>> For a few seconds I was really excited because I didn't have to do any
>> extra work, so please, someone tell me that I'm wrong and it's easy to
>> do in the current code base.
>>
>> --Lee
>>
>> On 6/2/2011 10:17 AM, Johannes Schindelin wrote:
>>> Hi Lee,
>>>
>>> On Thu, 2 Jun 2011, Lee Kamentsky wrote:
>>>
>>>> I have this case - you have some region of interest represented by a
>>>> binary bitmap and the bitmap, for one reason or another is offset in
>>>> space (In Yiddish: it's "in mitten drinnen", don't know if that
>>>> translates to German and there's a good chance that the way it was used
>>>> in my family is the exact opposite of its literal meaning)
>>> That sounds Yiddish alright, and I think Germans do understand it. But
>>> then, it might also be just due to my family that I am familiar with a
>>> couple of Yiddish terms...
>>>
>>>> but otherwise is best suited as an array. You don't want to represent
>>>> it
>>>> using an ArrayImg<BitType>   because everything from the origin to the
>>>> first pixel will be uniformly false, otherwise, the ArrayImg is the
>>>> right choice. The obvious solution here is to have some sort of adapter
>>>> object to hold the Img and for it to do some lying about where the
>>>> thing
>>>> is in space - every Localizable and Positionable needs to be wrapped in
>>>> something that adds or subtracts the offset.
>>>>
>>>> Is that a reasonable thing to add to Imglib? Where would it live and
>>>> what would you call it? Also, an Img isn't Localizable and Positionable
>>>> and perhaps this thing should be?
>>> Would it maybe work if you used an "offsetting" View of an ArrayImg?
>>>
>>> Ciao,
>>> Dscho
>>>
>>
>