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

[Chris Allan]

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