[ome-devel] Simple questions about files versus pixels
Ilya Goldberg
igg at nih.gov
Mon Dec 13 18:17:32 GMT 2004
On Dec 10, 2004, at 2:21 PM, Zachary Pincus wrote:
> Sorry for continually spamming the list! (And I hope you all are
> recovering well from ASCB...)
>
> Anyhow, I've got an amendment to one of the questions I asked
> yesterday:
>
>> First, is there any way to determine the original file a Pixels
>> object or Image object came from? I see the OriginalFile STs in OME,
>> but there doesn't seem to be a way to link those to anything else.
>
> Upon close review, it seems that the way to do this is to:
> (1) Take a pixels object, and look at it's ModuleExecution
> (2) One of the inputs to that MEX will be something with a FormalInput
> type of "OriginalFiles"
> (3) Look at the ID of the input_module_execution that created the
> input found in (2)
> (4) Search for OriginalFiles objects with MEXs that have the ID found
> in (3)
>
> This procedure works great for images that I imported one at a time.
> However, when I import two images at once via the web UI, it breaks.
> (Which is what caused me to ask the original question, I now see.)
>
> Specifically, if a pixels object was created as part of a batch
> import, step 4 fails -- there are no OriginalFiles objects associated
> with the MEX that created the Pixels object, or any of the MEX inputs
> to that MEX (and so forth up the chain).
>
> Moreover, if you then look at the OriginalFiles objects that were
> created, they have a MEX associated that is never referenced by any
> ActualInput...
>
> Is this a bug, or am I failing to understand some sort of "tee"
> mechanism or something like that? (I presume the latter...)
If you trace backward using the web UI, you can see that the inputs
used by the "Image import" MEX were the one or more OriginalFiles that
comprise your Pixels. How does that happen?
Step 0: What files were used to get the pixels in an image who's name
starts with 'nfat10x3'
ome=# select * from images where name like 'nfat10x3%';
image_id | image_guid | group_id | description | name
| pixels_id | created | experimenter_id |
inserted
----------+-------------------+----------+-------------
+---------------------+-----------+-------------------------------
+-----------------+-------------------------------
7 | 00:0a:95:9f:52:86 | 4 | | nfat10x3
good2_D12 | 52 | 2004-12-02 21:08:38.116632-05 | 1
| 2004-12-02 21:08:38.116632-05
(1 row)
We see that default pixels_id for this image is 52.
Step 1:
ome=# select * from image_pixels where attribute_id=52;
attribute_id | repository | size_c | size_y | pixel_type | size_x |
image_id | size_z | module_execution_id | file_sha1
| image_server_id | size_t
--------------+------------+--------+--------+------------+--------
+----------+--------+---------------------
+------------------------------------------+-----------------+--------
52 | 2 | 3 | 512 | uint16 | 640 |
7 | 1 | 9 |
2079147ce94c9069699fa4495c6360eefd2bc5ee | 7 | 1
(1 row)
We see that this Pixels attribute came from module_execution_id=9 (MEX
9).
Step 2:
Find inputs who's module_execution_id (not input_module_execution_id)
is the MEX that produced our pixels:
ome=# select * from actual_inputs where module_execution_id=9;
actual_input_id | module_execution_id | formal_input_id |
input_module_execution_id
-----------------+---------------------+-----------------
+---------------------------
3 | 9 | 3 |
16
(1 row)
We see that the only input for MEX 9 came from MEX 16. As there is
only one formal input declared for the Image import module (Original
Files), that's what we expect.
Step 3:
We look at MEX 16:
ome=# select module_id,virtual_mex from module_executions where
module_execution_id=16;
module_id | virtual_mex
-----------+-------------
1 | t
(1 row)
There are several more columns there, but the only important one is
"virtual_mex". Since its true, the inputs for MEX 9 (that produced the
Pixels) came from a virtual MEX (vMEX 16).
Step 4:
We look at virtual_mex_map for module_execution_id=16:
ome=# select * from virtual_mex_map where module_execution_id=16;
attribute_id | module_execution_id
--------------+---------------------
53 | 16
55 | 16
54 | 16
(3 rows)
And we see that this virtual mex produced three attributes (which are
of type OriginalFiles as specified by formal_input_id=3).
Step 5:
We look at original_files with attribute IDs 53,55,54:
ome=# select * from original_files where attribute_id in (53,55,54);
attribute_id | repository | sha1 |
file_id | module_execution_id | format | path
--------------+------------+------------------------------------------
+---------+---------------------+--------+----------------------------
53 | 2 | 4911ef94ee9104171622981248ecb776af217c25 |
2739 | 2 | TIFF | nfat10x3 good2_D12_w1.TIF
55 | 2 | bbc58fd89cf7e5b379b89269ac6209adbbdb1cbe |
2741 | 2 | TIFF | nfat10x3 good2_D12_w3.TIF
54 | 2 | a8a80379c3a22ce3ddf69567f7343ab7b48bf27b |
2740 | 2 | TIFF | nfat10x3 good2_D12_w2.TIF
(3 rows)
And there you have it.
vMEXes were introduced in order to deal with the situation where a
subset of a MEX's outputs are used as inputs to a subsequent MEX.
There's an API call to get all the attributes for a MEX (virtual or
otherwise):
OME::Tasks::ModuleExecutionManager->getAttributesForMEX
(16,'OriginalFile');
Note that you supply the MEX that actually produced those attributes
(the input MEX for the "Image import" MEX that gave you Pixels).
Note also that the MEX associated with these attributes is 2. This is
a run of the Original files module that processed this "bulk" import,
so the entire group of files you imported would have the same MEX. A
consequence of vMEXes is that attributes may have more than one
associated MEX, and there's an API call for that as well:
OME::Tasks::ModuleExecutionManager->getMEXesForAttribute (53);
-Ilya
>
> Thanks,
>
> Zach
>
> _______________________________________________
> 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