simleo
commented
8 years ago All looks good from my standpoint. Although this is a general framework proposal, I think it's useful to compare it to our current use case. The structure of the current feature record is defined in https://github.com/simleo/pydoop-features/blob/master/src/main/avro/featureset.avdl.
Data:
The feature set consists of 2919 values distributed across 214 vectors (the array<double> entries). Note that WND-CHARM outputs a single vector with 2919 components, which is broken down into sub-vectors by pydoop-features. The only scalar features are the gini_coefficient_* ones (although they are represented as 1-length vectors for consistency/simplicity). The data type is double for all features, although this is probably the result of a generalization step within WND-CHARM (i.e., looking at the output records, it seems that many sub-vectors can be safely cast to integer arrays).
Metadata: All remaining fields represent metadata:
- version: WND-CHARM feature vector version number
- name: merges image basename and series index. Mostly useful for consistency checks on computation results, I wouldn't store this in the OMERO table
- img_path: the image path originally fed to the B-F reader
- series, z, c, t: the usual B-F plane coordinates. The mapping from the series index to the well can be obtained from the OMERO server
- x, y, w, h: rectangular image tile this record refers to
manics
joshmoore
cc @joshmoore @simleo