Task #2552 (new)
ImageContainer-MultiImage or ???
|Reported by:||jburel||Owned by:|
|Keywords:||n.a.||Cc:||wmoore, cxallan, jamoore, dzmacdonald, jrswedlow, ajpatterson|
Description (last modified by wmoore)
Following discussing on N-Dim, it is URGENT to introduce
the concept of ImageContainer. Not sure we need to model it (for now)
Why is it that important?
- Multi-images file e.g. lei. Problems are:
- users does not recognize the file. Known fact, we have lost some potential users b/c of that. We can argue that others use the system even if we don't have that in place.
- Most importantly. When I import an .lei file (3 images). I select one file (.lei), import it (with archived on) and end up with 3 OMERO images. Problem is when I want to download the file back, it is impossible to select only one image. I need to select 3 images (which means I have to remember all components 3 ok but Martin has >20 images), download and then... figure out where the .lei file is (file annotation). Conclusion: The workflow is broken.
- Sparse data. They are in a sense similar to the multi-images file problem for storing, the way we will handle them is different.
- Stitched Images. If I stitch a bunch of images together, the result is a single image, but I may not want to duplicate the pixel data. In that case, the image container simply stores the transformations required to stitch it's images into a single image.
- Other possibilites...
ImageContainer will have a type field indicating if it is a multi-image, sparse etc.
A dataset will then be linked to ImageContainer or Image. One way to possibly make the linkage to dataset cleaner is to have multi-image subclass from image. This would seem to fit with the concept established in Paris of an "ImageTransform. (See "Day 2 Discussions"). Many images are the input to an ImageTrannsform and a single image is the output.