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

[Bernhard Voigt]

Hi Jason and Chris!

Sorry for digging something up that has been discussed previously. I
was just curious and couldn't make much sense of it. Your explanations
and the use case for reconstructed pixels sounds reasonable. For me
it's enough to know that it is most likely not support and I don't
have to care.

Thanks! Bernhard

On Thu, Mar 19, 2009 at 4:14 PM, Jason Swedlow
<jason at lifesci.dundee.ac.uk> wrote:
> 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.
>
>
>