Image class

[Thomas Caswell]

You can get around some of the issues with slicing out scalars by
being careful with how some of the function are overloaded (and an
outstanding bug in numpy https://github.com/numpy/numpy/pull/4619).
An example of this is
https://github.com/soft-matter/pims/blob/master/pims/frame.py

The light-weight numpy wrapper is a convenient thing for handling I/O
I think that having a preferred set of kwargs and up-packing into
functions is a better course for libraries as it is (more) agnostic to
how the users want to deal with their data.  Having to do

>> slic(image_subclass, **image_subclass.md)

is less annoying than having to do

>> tmp_image = SkImg_ndsbuclass(my_data, my_meta_data)
>> slic(tmp_image)

Tom

On Mon, Sep 1, 2014 at 3:23 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
> On Mon, Sep 1, 2014 at 2:45 AM, Guillaume Gay
> <guillaume at mitotic-machine.org> wrote:
>> Hi all
>>
>> +1 on metadata handling, it is surely of prime importance.
>>
>> Maybe this is far too domain specific, but I would suggest relying on
>> OME.XML tags as keys for the metadata dic (or the subset of it that concerns
>> images). The whole schema can be found here:
>> http://www.openmicroscopy.org/Schemas/OME/2011-06/ome.xsd
>>
>>  Those tags are used in the ome.tiff format, and are recognized by lots of
>> tools, of which by C. Gohlke's tifffile.py is used as io in skimage...
>>
>> Of course that doesn't have the out of the box advantage of being able to
>> call func(image, **metadata).
>>
>> One last advantage is providing an easy route to persistence via the
>> ome.tiff image format.
>>
>> Best,
>>
>> Guillaume
>>
>>
>> Le 01/09/2014 08:03, Juan Nunez-Iglesias a écrit :
>>
>> Hi everyone,
>>
>> I generally love scikit-image’s approach of a numpy array is identically an
>> image, with no added cruft. Having a subclass can be problematic, as we saw
>> with the various bugs caused by things like:
>>
>> ```python
>>>>> im[0, 0]
>> Image([255], dtype=np.uint8)
>> ```
>>
>> However, watching the below talk from Image.jl’s Tim Holy, I was reminded of
>> the importance of metadata in a lot of image processing:
>>
>> https://www.youtube.com/watch?v=FA-1B_amwt8
>>
>> (Incidentally, the talk is worth watching, especially towards the end when
>> he talks about performance tricks.)
>>
>> Someone (I forget who, sorry!) told me that they’d solved the
>> slicing/scalars problem in a different numpy wrapper, so that might be
>> feasible if we went back to having a light numpy array subclass, which could
>> have a simple metadata attribute in the form of a dict with arbitrary keys
>> (with some prescriptions, such as “spacing” for the resolution, same as we
>> have prescribed ranges for specific image data types).
>>
>> Alternatively, we might want to have a unified “metadata” dictionary format
>> that would unwrap nicely into our preferred kwarg format, e.g. if we did
>> `slic(image, **metadata)` it would just work.
>>
>> Just a couple of ideas. There may be other solutions, but my main point is
>> that we might want to unify our metadata handling, rather than letting the
>> user always worry about it.
>>
>> Thanks for listening! =)
>>
>> Juan.
>
> We run into this a lot in brain imaging too.  It made me think of some
> work that Fernando Perez and Mike Trumpis were doing on attaching data
> to axes:
>
> https://github.com/fperez/datarray
>
> Cheers,
>
> Matthew
>
> --
> 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/d/optout.



-- 
Thomas Caswell
tcaswell at gmail.com