[ImageJ-devel] Naming [was: Re: [fiji-devel] RegionOfInterestCursor considered misnamed]

Andreas Maier akmaier at stanford.edu
Tue Oct 12 02:20:55 CDT 2010


Sounds like a good idea. By the way, I personally like 
"accumulativeness". ;)

Andreas

Am 11.10.2010 19:48, schrieb Stephan Preibisch:
> Hi everybody,
>
> First of all, I do not like "grid" too much as it assumes uniformly arranged
> data which is not necessarily true. Although it is right now to be fair :)
> At the end it also not necessarily an image, it might as well be a DNA
> sequence for example. So if we try to be exact, we should rather name it
> something more generic like Collection, maybe something from
> http://www.dict.cc/?s=ansammlung? Right now, I find "pool" appealing...
>
> Let's discuss it next week when Curtis is in Dresden...I am optimistic we
> will find a solution!
>
> Have a nice day,
> Steffi
>
> -----Original Message-----
> From: imagej-devel-bounces at imagejdev.org
> [mailto:imagej-devel-bounces at imagejdev.org] On Behalf Of Andreas Maier
> Sent: Tuesday, October 12, 2010 3:36 AM
> To: imagej-devel at imagejdev.org
> Subject: Re: [ImageJ-devel] Naming [was: Re: [fiji-devel]
> RegionOfInterestCursor considered misnamed]
>
> Hi,
>
> why not use the term "grid"?
>
> Best,
>
> Andreas
>
> Am 11.10.2010 18:34, schrieb Grant B. Harris:
>    
>>   Stephan,
>>
>> "Domain" is appealing in that it can be interpreted broadly - images
>> and signals can "be in" the spatial domain, frequency domain, or
>> wavelet domain.  And it doesn't have any implied dimensionality
>> (unlike "space" which has some connotation of only 3-D).
>>
>> Also, I like the idea of a sub-interface called `Tensors' for a
>> discrete regular grid.
>>
>> - Grant
>>
>>
>> On 10/11/2010 4:17 PM, Stephan Saalfeld wrote:
>>      
>>> Hi,
>>>
>>>        
>>>> I vote for interface "Tensor".
>>>>
>>>> The misnamed "imglib" is a tensor lib.
>>>>
>>>>
>>>>   From http://en.wikipedia.org/wiki/Tensor :
>>>>
>>>> "... tensors in general can be considered as a multidimensional array
>>>> of numbers"
>>>>
>>>>          
>>> ... which is true for only the most basic concepts to be expressed by
>>> the intended interface `Image'.  Already a sparsely sampled space is not
>>> a tensor any more, neither is a 3d-scene description or a
>>> hyper-spherical mask (actually anything that is not a box and discrete).
>>> Yes, you can sample these Images in a discrete raster but you don't have
>>> to.  Positionables in real space (Interpolators) are the most trivial
>>> example.  The Iterator already does it's own magic.
>>>
>>> The true meaning of the interface Image is that it spans and limits a
>>> function-space or domain, so we could call it `Function', `Space' or
>>> `Domain', great for math-agnostic developers learning the API (though
>>> not as horrible as LocalizableByDimCursor ;)).  `Tensors' could then be
>>> a sub-interface that guarantees that the samples are on a discrete
>>> regular grid of a box.
>>>
>>> I completely agree that it sucks to collide with java.awt.Image.
>>> Besides, I am quite sure that, in the global Java namespace, there is
>>> little room for non-colliding names except we call it a silly name.  I
>>> am pro:
>>>
>>> Img (favorite), Domain (promising collisions), Space, Scene, Function
>>> (best choice but promising collisions and missleading expectations).
>>>
>>> The most recent developments are tracked in the branch sampler-link
>>> (which stems from sampler but got rid of the links...) where development
>>> was recently stopped for too long time by the silly CellContainer bug
>>> that came from master but I was searching in the changes...
>>>
>>>
>>> Best,
>>> Stephan
>>>
>>>        
>>>> Albert
>>>>          
>> _______________________________________________
>> ImageJ-devel mailing list
>> ImageJ-devel at imagejdev.org
>> http://imagejdev.org/mailman/listinfo/imagej-devel
>>      
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagejdev.org
> http://imagejdev.org/mailman/listinfo/imagej-devel
>
>    





More information about the ImageJ-devel mailing list