The initial logic of the rendering plugin has been primarily driven by the high-content screening use case i.e. fairly homogeneous imaging datasets where a single rendering file can be applied to all images within a plate. In the case of IDR experiments, datasets can be much more heterogeneous with mixed dimensionalities and modalities. In many cases, a single set of rendering settings is not sufficient.
The https://github.com/IDR/idr0067-king-yeastmeiosis was fairly representative in the sense that datasets contained fluorescence multi-C multi-Z, fluorescence multi-C maximally projected and single channel brightfield images and each image needed to be adjusted individually. During the curation, I used a branch with the following changes:
- dff6900 adds an option allowing to store rendering settings in a directory structure. The return value of
render_images API is expanded to include a string context in addition to list of images. This context is then used for creating the directory tree, e.g. if the command target is a project, the layout is <project_name>/<dataset_name>/<image_name>.yml
- 5850f28 updates the
set command to be able to consume rendering settings using the layout above.
With both changes, bin/omero render info -f Project:<id> was used to recursively extract the imported rendering settings. After curation bin/omero render set -f Project:<id> was invoked to recursively update all images in the project:
Based on recent IDR examples, my impression is that such a functionality would be valuable to backport to the render plugin. Before consolidating the prototype as well as adding tests, I am opening as an issue in case we need to capture similar use cases that should be also considered like:
/cc @joshmoore @dominikl
The initial logic of the rendering plugin has been primarily driven by the high-content screening use case i.e. fairly homogeneous imaging datasets where a single rendering file can be applied to all images within a plate. In the case of IDR experiments, datasets can be much more heterogeneous with mixed dimensionalities and modalities. In many cases, a single set of rendering settings is not sufficient.
The https://github.com/IDR/idr0067-king-yeastmeiosis was fairly representative in the sense that datasets contained fluorescence multi-C multi-Z, fluorescence multi-C maximally projected and single channel brightfield images and each image needed to be adjusted individually. During the curation, I used a branch with the following changes:
render_imagesAPI is expanded to include a string context in addition to list of images. This context is then used for creating the directory tree, e.g. if the command target is a project, the layout is<project_name>/<dataset_name>/<image_name>.ymlsetcommand to be able to consume rendering settings using the layout above.With both changes,
bin/omero render info -f Project:<id>was used to recursively extract the imported rendering settings. After curationbin/omero render set -f Project:<id>was invoked to recursively update all images in the project:Based on recent IDR examples, my impression is that such a functionality would be valuable to backport to the
renderplugin. Before consolidating the prototype as well as adding tests, I am opening as an issue in case we need to capture similar use cases that should be also considered like:-f %p/%d/%i.yml/cc @joshmoore @dominikl