ome/omero-metadata

Importing plate data per image

Opened this issue · 1 comments

Hi all,

as discussed a bit off-topic with @will-moore at will-moore/parade-crossfilter#17 I'm a bit unhappy with how the plate data upload works in omero-metadata.

At the moment I use Cellprofiler per Image result tables and generate a csv-file with KNIME out of it that is ready to use with populate metadata. Beside some manual definition (e.g. plate name) everything else is automated (including reconstruction of the image name, that is created in Omero for my plates e.g. "Index.idx.xml [Well 1, Field 1]", as our system PerkinElmer Operetta CLS always creates a Index.idx.xml file which is used for import into Omero) .

So in theory everything is fine from data perspective, but I have a lot of trouble to get the data into Omero. Please find below an example file, that I would like to upload.
Omero_Metadata_Plate_perImage_example.csv

The idea is to include all information that I have (plate,well,image), to be able to populate on the layer of plates or screens. But this is not possible due to several reasons:

  1. the well and image information cannot be included at the same time: omero_metadata.populate.MetadataError: Well Column and Image Column cannot be resolved at the same time. Pick one.
  2. the image name cannot be resolved: ValueError: invalid literal for int() with base 10: 'Index.idx.xml [Well 1 Field 1]' (see full log in above cross-linked issue) => although this is possible for dataset/image!
  3. the plate column name may not be included, when uploaded to a plate: AttributeError: 'PlateWrapper' object has no attribute 'value_resolver'
  4. I would like to add also ROIs per image, but this does not make any sense if I am unable to map them to a specific image (not well)

So from my point of view it should be possible to add all given information and omero-metadata should just use the most granular one (plate > well > image > roi ). It should not block the upload just due to too many information.

This topic might a an extension of #51, but covers more, so I wanted to create it separately. Especially because of the image name resolution.

I appreciate any thoughts or changes of the current situation.

Thanks, Anna

Working on this at #64