[ome-devel] Re: [ome-users] importing multiples pixel sets ?
Ilya Goldberg
igg at nih.gov
Wed Feb 1 06:10:27 GMT 2006
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
>
More information about the ome-devel
mailing list