[ome-devel] importing multiples pixel sets ?
kris
kris at cs.ucsb.edu
Wed Feb 1 22:39:44 GMT 2006
Thanks for the comprehensive response. I've opted
for a image level ST with a key to the Pixels type and a string.
The label (if available) will display in our UI and will
be used by special renderers when defined. I still
thing a simple descriptive tag in the Pixel type ST might be
useful, but that is, of course, debatable.
I am intrigued by the notion of subclassing STs. I had
not noticed this in the documentation nor the code.
We actually have a need for specialized image types
where we will display the images with overlayed metadata
when available. Currently we use image level ST to "tag"
an image as a special type and then select a renderer
to actually show the image and the associated metadata a
complete unit if the "tag" exists.
However, I would like very much to be able
to define subclass of Image and simple define our more specialized
image types when appropriate. Do you plan on supporting
some type structure of STs in the future or is it a passing thing?
How far to you plan on taking it i.e multiple inheritance etc
If it will be maintained we may go with subclassing
both Image STs and PixelSets.
On the topic of supporting ST changes on the fly,
has anyone looked at Alzabo[1] which claims to support
database changes based on class changes? We find that
identifying the proper fields for STs to be actually
a reasonably hard part of the process and having the
ability to change on the fly would be very helpful.
[1] http://www.alzabo.org/
On Wed, 2006-02-01 at 01:10 -0500, Ilya Goldberg wrote:
> Hi Kris
> There's been some discussion about managing multi-pixel images in
> UI. Its a problem of context - how do we differentiate the different
> pixels. One available mechanism is their origin. Differentiating by
> origin or even better - provenance, allows preserving the
> universality of the data type (they're all pixels and therefore
> interchangeable in one sense), while at the same time allowing them
> to be differentiated ("color enhanced" pixels are different from raw
> pixels due to their origin). If the pixels came from different
> modules, then they could easily be differentiated based on the names
> of the modules for the originating MEXes:
> @pixels = $factory->findObjects ('@Pixels', {
> image => $myImage,
> module_execution.module.name = 'Image import'
> }
> will get the ones created at import, while
> @pixels = $factory->findObjects ('@Pixels', {
> image => $myImage,
> module_execution.module.name = 'ColorEnhancement'
> }
> will get the ones created by the "ColorEnhancement" module.
>
> Of course this organizational scheme will only work if things are
> organized by origin in the first place, which is not always what you
> want. If everything comes out of 'Image import', then something else
> is needed.
> One option is what you suggest - adding a text label to the pixels
> datatype. This would work, but potentially its disadvantage would be
> if UI code is bound to certain label values which are not necessarily
> strictly controlled. Basically there is no general way to enforce a
> type specified in this way at a system level. But, the UI could
> display the labels next to the pixels so that the user can chose the
> proper ones (the labels are used as user-land mnemonics). Pixel
> labels are a good thing.
>
> Another option is creating your own datatype to designate certain
> types of pixels. For example you can create an ST called
> "ColorEnhancedPixels", which contains a reference to a Pixels. In
> effect, "ColorEnhancedPixels" is a sub-class of Pixels, which just
> has a different name. Then, when you want your UI to display a
> certain kind of pixels, you just make it display the correct
> datatype. You import code would produce all the different pixels,
> and in addition emit "ColorEnhancedPixels" (or whatever) to specify
> their type further. There is a fair bit of support for this kind of
> sub-classing. The only thing to do is to name the Pixels reference
> "Parent". The "Parent" convention isn't supported everywhere (though
> references of course are). This is used extensively in the
> implementation of image classification (src/xml/README.Classifier),
> including frequency space pixels, gradient pixels, and things like
> planes, etc. This way you have a new class if you know how to
> interpret it, and you still have the original Pixels class intact to
> do Pixelish things with. The web UI will display a clickable
> thumbnail for the Pixels reference when looking at a
> ColorEnhancedPixels, for example.
>
> By the same token, you can have a PixelsLabel ST which contains a
> reference to Pixels and a text label. Is PixelsLabel a subclass of
> Pixels? Its not really a Pixels, its a Label, so calling the
> reference to Pixels "Parent" is probably not the right thing here.
>
> Unfortunately, there's no high level interface for editing STs "in
> flight". The database delegate class (OME::Database::Delegate)
> provides most of the functionality, and there are examples of doing
> this in the updates directory. Generally, when we develop new STs,
> we make a development DB to work from and dump it out. Then we
> import our STs and try them out. If we don't like them, we drop the
> DB and restore from the dump. Even though that's pretty clunky, the
> drop/restore operation is pretty quick (you don't need to do anything
> with your OMEIS, or installation or whatever). Changing STs in
> flight can be an almost arbitrarily tricky proposition - especially
> if you want to preserve the integrity of the data. If you don't care
> about the data, a way to wipe out all dependent data and edit the ST
> would probably not be a bad idea. Wiping out the data would be easy
> - you just wrap the delete script with a query to get the dependent
> mexes. The delete script can do the deletion of the ST as well, but
> this is a different set of dependencies than mexes and attributes,
> and would be a separate (new) piece of code.
>
> -Ilya
>
>
>
>
>
>
>
> On Jan 30, 2006, at 7:28 PM, kris wrote:
>
> >
> > I've modified our image importers to add pixel sets
> > to an image if the basename of an image file
> > is the same as an existing image.
> >
> > The process is very similar to the way a single
> > 5D image is composed from several distinct files.
> > i.e __getRegexGroups allows several distinct files to define
> > a pixel set.
> >
> > In our case, a group of files define a single pixel
> > set of a related image. We determine related pixel
> > sets using a regexp..For example a projection/Z-series
> > image has a P/Z embedded in the Name. Color enhanced
> > image pixels sets have a trailing tag (_enhanced).
> >
> > However, I now face an issue that I would like
> > to distinguish those pixel sets in the interface.
> > I would like to label some 3-d pixel set as 'zseries'
> > and the related projection as 'projection',
> > the enhanced pixles 'color equalized', etc.
> > We can then modify our interface code to select
> > the proper pixel set based on the context or user options.
> > One could also be labeled 'default' for general queries.
> > I think the most natural place would be a string tag in the
> > "Pixels" Semantic Type. What is the general opinion
> > out there? Would this be useful to anyone else or
> > is there a better alternative?
> >
> > Bringing me to second question:
> > Why can we not currently redefine a semantic
> > type once it's imported into the system? In most
> > cases I would like to add/delete a column which are
> > operations supported by postgres. Is there an
> > accepted alternative currently other than going
> > through and either removing the offending semantic
> > type by hand and re-importing or by doing it some low-level
> > sql operations?
> >
> >
> > Thanks for any pointers,
> > kris
> >
> >
> >
> >
> >
> > On Wed, 2006-01-11 at 17:03 -0500, Josiah Johnston wrote:
> >> I think your best bet will be a custom importer or a perl script. The
> >> API for creating module executions, and tying inputs and outputs to
> >> them is readily available to perl scripts. The relevant functions are
> >> in OME/src/perl2/OME/Tasks/ModuleExecutionManager.pm
> >>
> >> The steps to the scripts roughly are:
> >> write a placeholder module to describe each transformation. You can
> >> base this off a combination of
> >> OME/src/xml/OME/Annotations/AnnotationModule.ome and
> >> OME/src/xml/OME/Analysis/Filters/HighPassFilter.ome
> >> write a script that, given an original image file and a derived
> >> image,
> >> will
> >> i) import the original image into OME,
> >> ii) use OME::Tasks::ModuleExecutionManager->createMEX(...) to
> >> initiate
> >> an 'execution' of your placeholder module against your newly imported
> >> image
> >> iii) use OME::Tasks::ModuleExecutionManager->addActualInput(...) to
> >> register the image's pixels as inputs to your new MEX
> >> iv) use OME::Tasks::PixelsManager->createPixels(...) to start a
> >> new set
> >> of pixels that will store your derived image
> >> v) use the returned $pixels_data object to write the derived image's
> >> binary data to the image server
> >> vi) use OME::Tasks::PixelsManager->finishPixels(...) to finalize the
> >> pixels
> >> vii) register the mex as finished by calling $MEX->status
> >> ( 'FINISHED' );
> >> viii) commit the database transaction (e.g.
> >> $session->commitTransaction() )
> >>
> >> Ideally, you would also set the timing information for the MEX, but
> >> that's somewhat optional.
> >>
> >> The alternative is to write module wrappers for your transformations,
> >> and execute a chain on the original images. If your
> >> transformations can
> >> be executed on the command line, then I will fix the command line
> >> handler to execute one of your functions. I have been contemplating
> >> fixing it for a while, but lack a use case.
> >>
> >> -Josiah
> >>
> >> On Jan 11, 2006, at 4:31 PM, kristian kvilekval wrote:
> >>
> >>>
> >>> We have several related images that could possible
> >>> be stored as pixel sets. These include
> >>> Z-series, projections, normalized images
> >>> and color equalized images.
> >>>
> >>> These are currently stored in different files.
> >>> Is there an easy way to import these as several
> >>> pixel sets of the same image or will a custom importer need
> >>> to be written.
> >>>
> >>> In a similar vein, we would like capture the relationship
> >>> between the pixel sets using something similar to a module
> >>> execution identifier. Is this supported?
> >>>
> >>> Thanks,
> >>> kris
> >>>
> >>> --
> >>> Kristian Kvilekval
> >>> kris at cs.ucsb.edu http://www.cs.ucsb.edu/~kris w:805-893-2526
> >>> h:504-9756
> >>>
> >>> _______________________________________________
> >>> ome-users mailing list
> >>> ome-users at lists.openmicroscopy.org.uk
> >>> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users
> >>>
> > --
> > Kristian Kvilekval
> > kris at cs.ucsb.edu http://www.cs.ucsb.edu/~kris w:805-893-2526 h:
> > 504-9756
> >
> > _______________________________________________
> > ome-devel mailing list
> > ome-devel at lists.openmicroscopy.org.uk
> > http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
> >
--
Kristian Kvilekval
kris at cs.ucsb.edu http://www.cs.ucsb.edu/~kris w:805-893-2526 h:504-9756
More information about the ome-devel
mailing list