ndarray subclasses

[James Turner]

Maybe it's worth mentioning that astropy has also done a bit of
(incomplete) work on an nddata class that adds things like metadata,
error and mask information to ndarray. I think it's a wrapper rather
than a subclass. This might not be how you would do it for skimage
but it's just FYI (not particularly astronomy specific)...

   http://docs.astropy.org/en/latest/nddata/index.html

Just regarding "sampling" vs "resolution", IMHO the common use of
resolution to describe pixel density in computing is somewhat
erroneous. There isn't really a good substitute term for describing
the intrinsic analogue (eg. optical) resolution of an image or
waveform before it's digitized (bandwidth?) and (as someone else
pointed out) the digitized sampling density/spacing doesn't
necessarily tell you how much detail you have anyway.

Cheers,

JAmes.


On 23/09/13 12:43, Thomas A Caswell wrote:
> On Mon, Sep 23, 2013 at 2:24 AM, Almar Klein <almar.klein at gmail.com
> <mailto:almar.klein at gmail.com>> wrote:
>
>         As a skimage (very happy) user, I must say I find **very** convenient
>         that vanilla ndarrays are accepted throughout the libary, because image
>         metadata is a problem best kept away from the calculus, except in issues
>         of the 'sampling case' type, where I agree it is nicer to have it as a
>         clear function argument.
>
>     Just to be clear, I think skimage should *always* accept vanilla ndarrays,
>     and I agree that functions that can deal with anisotropy should have an
>     explicit (and optional) "sampling" argument.
>
>     I think my suggestion would be that such a function should check if the
>     array has a sampling attribute, and use that if the sampling argument is not
>     given. In that way, we could do "im =
>     imerode(imdilate(my_image_with_sampling_attr)", and things would just work
>     in the correct manner.
>
>
> My concern with this proposal is now the user has two independent ways to pass
> in the same information.  If inconsistent information is passed in the library
> has to make a decision about which one takes precedence.  This adds to the
> complexity of the function and can only lead to confusion on the part of the
> users when they think the precedence should have the opposite order.
>
> If you have a function `f(array, meta_data)` then I would add a thin wrapper for
> the sub-classed arrays as such: `s_f(sub_classed_array): return
> f(sub_classed_array, sub_classed_array.get_metadata())`.  This adds a lot more
> functions, but they can probably be auto-generated and don't add much
> complexity.  Maybe make them class methods of the sub-array class so they do not
> pollute the namespace.
>
> Tom
>
>     - Almar
>
>
>>     On 22 September 2013 05:57, Juan Nunez-Iglesias <jni.soma at gmail.com
>>     <mailto:jni.soma at gmail.com>> wrote:
>>
>>         On Sun, Sep 22, 2013 at 1:20 PM, Jaime Fern�ndez del R�o
>>         <jaime.frio at gmail.com <mailto:jaime.frio at gmail.com>> wrote:
>>
>>             So a pixel replicated TIFF image has twice the resolution, as per
>>             the above official definition, not the same resolution with twice
>>             the sampling.
>>
>>
>>         Even in this case, what we call sampling/spacing is the *inverse* of
>>         that definition of resolution.
>>
>>
>>     I think strictly speaking, the term "resolution" is a measure for
>>     visibility of detail. The term is used a lot to simply denote the *number*
>>     of pixels, e.g. 800x600, 1024x768, etc.  Spacing/sampling is really just a
>>     a measure (usually in mm) that specifies the distance between two pixels.
>>     If you know the number of pixels, and the sampling, you know the image
>>     size in physical units.
>>
>>     - Almar
>>     --
>>     You received this message because you are subscribed to the Google Groups
>>     "scikit-image" group.
>>     To unsubscribe from this group and stop receiving emails from it, send an
>>     email to scikit-image+unsubscribe at googlegroups.com
>>     <mailto:scikit-image+unsubscribe at googlegroups.com>.
>>     For more options, visit https://groups.google.com/groups/opt_out.
>
>         --
>         You received this message because you are subscribed to the Google
>         Groups "scikit-image" group.
>         To unsubscribe from this group and stop receiving emails from it, send
>         an email to scikit-image+unsubscribe at googlegroups.com
>         <mailto:scikit-image%2Bunsubscribe at googlegroups.com>.
>         For more options, visit https://groups.google.com/groups/opt_out.
>
>
>     --
>     You received this message because you are subscribed to the Google Groups
>     "scikit-image" group.
>     To unsubscribe from this group and stop receiving emails from it, send an
>     email to scikit-image+unsubscribe at googlegroups.com
>     <mailto:scikit-image%2Bunsubscribe at googlegroups.com>.
>     For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> --
> Thomas A Caswell
> PhD Candidate University of Chicago
> Nagel and Gardel labs
> tcaswell at uchicago.edu <mailto:tcaswell at uchicago.edu>
> jfi.uchicago.edu/~tcaswell <http://jfi.uchicago.edu/~tcaswell>
> o: 773.702.7204
>
> --
> You received this message because you are subscribed to the Google Groups
> "scikit-image" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to scikit-image+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.