[ome-devel] why is imge.pixels a list

Jason Swedlow jason at lifesci.dundee.ac.uk
Thu Mar 19 15:14:43 GMT 2009


Hi Bernard-

Just my 2 cents:

Your email generated a collective "Oh No!  Not that again!" from us.   
This is one of those things that we invented many years ago in the  
deep dark annals of OME, that we can see generates some benefit,  
especially from the standpoint of data models, but simply gives users  
headaches (note that Ilya's Analysis Engine-based implementation of  
WND-CHARM used this concept to great effect).  In short it's a notion  
that machines can be made to understand, but users.....forget it.

Some sense of the years of wrestling with this issue is captured in  
the discussion Chris referenced.  Take that pain, and raise it to some  
very large exponential power.

Cheers,

Jason


On 19 Mar 2009, at 14:16, Chris Allan wrote:

> On Fri, 2009-03-13 at 09:42 +0100, Bernhard Voigt wrote:
>> Hi!
>
> Hi Bernhard.
>
> Sorry for the delay, this is a topic of much debate within the project
> so I was just collecting as much detail for everyone as possible.
>
>>
>> I noticed a while ago that images can have more pixels associated  
>> with
>> it. Looking at the docs of the OME-xml
>> http://cvs.openmicroscopy.org.uk/svn/specification/Documentation/Generated/OME-2008-09/ome.xsd.html#element_Image
>> I find two different pixels types, default and aqcuired. I don't  
>> quite
>> understand the notation and how this maps to the image.pixels list:
>> DefaultPixels="  PixelsID   [1]
>> AcquiredPixels="  PixelsID   [0..1]
>
> The short answer is that this is legacy.
>
> The idea historically, was that processed sets of Pixels would be  
> linked
> to the same Image. For example: using a wide-field microscope you  
> could
> have an "acquired" set of Pixels and a "deconvolved" set of Pixels.
>
> Where this has been problematic is in understanding and visualizing  
> the
> linkage between other data types and Pixels and/or Image. For  
> instance:
>
> * The established link between a Dataset and an Image is of course not
> Pixels. This makes linking, using the above example again, the
> "deconvolved" set of Pixels to a particular Dataset problematic.
>
> * The linkage target for Instrument and Experiment is also Image level
> in a
> sense muddying the concrete source of a set of Pixels.
>
> Finally, it also creates several complications when deciding the
> default "view" for an
> Image in a client and our efforts to convince users that an Image is a
> singular
> container that might contain one or more "Pixels" has met with looks
> of bewilderment
> and disbelief. Quite simply, we have decided not to go there.
>
> These problems are, of course, not insurmountable. Ideas have been
> thrown around to make the target of any metadata or container  
> membership
> (as in the Dataset or Tag cases) linkage Pixels and not Image. The
> problem with this solution is that at best it de-values Image as a
> concept, basically relegating it to being a "container" for Pixels  
> when
> it was never really designed to be just that and at worst introduces
> another layer of both complexity to the user.
>
> In practice, you can have Images in OMERO with multiple sets of Pixels
> but we do not expose this in our clients and are unlikely to in the
> future. For all intents and purposes we consider this functionality
> deprecated in both OMERO and the OME-XML schema. What we suggest and  
> use
> ourselves (projections in OMERO are a good example) is the creation  
> of a
> new Image with the use of the "relatedto" attribute on Pixels to  
> qualify
> linkage.
>
> This does not mean that we think multiple sets of Pixels was a wholely
> bad idea or that a container for Pixels will not always be present in
> OMERO and the OME-XML schema. We have discussed at length the
> possibilites for cleaning this up over the past year or so, you can  
> read
> a little about the conversations here (under the "Josh multiple pixels
> per image" section):
>
> http://www.openmicroscopy.org/site/community/minutes/meetings/june-2008-developers
>
> any feedback would be most welcome.
>
>>
>> What is the purpose of having multiple pixels for one image and when
>> does it appear?
>>
>> Thanks! Bernhard
>
> Thanks.
>
> -Chris
>
> _______________________________________________
> ome-nitpick mailing list
> ome-nitpick at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-nitpick
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel



**************************
Wellcome Trust Centre for Gene Regulation & Expression
College of Life Sciences
MSI/WTB/JBC Complex
University of Dundee
Dow Street
Dundee  DD1 5EH
United Kingdom

phone (01382) 385819
Intl phone:  44 1382 385819
FAX   (01382) 388072
email: jason at lifesci.dundee.ac.uk

Lab Page: http://www.dundee.ac.uk/lifesciences/swedlow/
Open Microscopy Environment: http://openmicroscopy.org
**************************

The University of Dundee is a Scottish Registered Charity, No. SC015096.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20090319/cd2ef92e/attachment.htm 


More information about the ome-devel mailing list