We're Hiring!

Hierarchy for storing processed image data

General user discussion about using and improving the OME Data Model. Please ask new questions at https://forum.image.sc/tags/ome-xml
Please note:
Historical discussions about the OME Data Model. Please look for and ask new questions at https://forum.image.sc/tags/ome-xml

Hierarchy for storing processed image data

Postby graeme_b » Fri Jun 10, 2011 4:14 pm

We have installed an OMERO server in our department (Oxford Biochemistry / Micron advanced Imaging facility), and have been using the system in anger for a few months now. One of the main gripes we hear from our users is that there appears to be no easy way to associate processed image data with its original source. A very common example is where a user deconvolves wide-field data (which is slow), and wants to keep the source data as well as the deconvolved result. Basically, it seems to us that the current hierarchy lacks one level. The ideal solution for us would be to introduce a "processed image" one level below the raw data (a bit like the way an 'ROI' is currently associated with an 'image' perhaps?) Even better would be for the importer to associate raw and processed data in such a way upon import by using filenames, filters or metadata. One step at a time though.

Although one *could* use a 'Dataset' for each image file, and store various processed versions within the dataset, this is not how we tend to use a dataset - rather, we use a dataset to organize related images (e.g. repeats of the same experiment). However we look at it, one more level in the hierarchy would be extremely useful.

I hope I have described clearly what our problem is - please let me know if it is not clear, or if I have missed a solution in the current implementation.

Thanks & best regards,

Graeme
graeme_b
 
Posts: 10
Joined: Tue Nov 02, 2010 2:51 pm

Re: Hierarchy for storing processed image data

Postby jmoore » Fri Jun 10, 2011 6:19 pm

Hi Graeme,

you are certainly not unique in your request. There are several parts to how we plan to address it.

In terms of the model, the plan is to allow explicit linkages between images. You might want to take a look at #1863 or #2552.

It's not yet clear how those linkages will be displayed in the user interface, but a different change, which will be our next major development effort and will clearly show up in the UI is FS (requirement #2128). The intent is that users could then organize derived images in subdirectories in a site-specific way.

We'll be discussing FS at the users' meeting in Paris next week. Any and all input would be greatly appreciated.

Cheers,
~Josh
User avatar
jmoore
Site Admin
 
Posts: 1591
Joined: Fri May 22, 2009 1:29 pm
Location: Germany


Return to User Discussion and Suggestions

Who is online

Users browsing this forum: No registered users and 1 guest

cron