[ome-users] OMERO clients user's comments

Tue Jan 13 16:02:00 GMT 2009

Dear OMERO developers,

as you know from Mario's postings we have been actively working on  
our OMERO implementation and testing project.

One think I have been doing is to test the usability side of the  
clients.

All my comments pertains to test done using the latest DB and client- 
suite versions available.

OMERO.db beta 3.2
OMERO. clients suite 3.2.1
                .importer pre beta4-4
                .insight beta3.2
                .editor main (3)1.0 _ not tested

Tests were done on a  Mac PowerBook G4 (client side) and a Dual  
Processor Power PC G5  (server side).

IN ALL CASES comments are made with the purpose of improving OMERO  
and helping the developers, maybe, seeing problems they had not  
thought about. Also the comments obviously reflect my personal view  
of priorities particularly in light of the beta4 release (if  
possible) and/or future releases.

Best regards

Caterina

_______________________

LIST OF COMMENTS

1) OMERO.webadmin:

Administering scientists and groups

* COMMENT_1: I think it is important to allow admin more flexibility  
in the administration of users  (i.e. scientists) and user's data
  Specifically admin should be able to remove user and user data from  
data base.
For what I can tell only a user without data can be deleted. This  
makes sense obviously but a real-world systems will require more  
flexibility.

Possible scenarios that would require such a measure:

When a user leaves a facility and his or her data need to be migrated  
to a new site.
During testing
In case of user's mistakes (especially likely to happen during large  
data migration or at db first instance installations)
Insertion of  "garbage data" in the db

At preset beta3 does not appear to allow users data to be deleted (in  
case it is there I did not find it).

		TWO POSSIBLE SOLUTIONS: either data should be erasable at admin  
side or at user side or both. This option should be set depending on  
the needs of each OMERO.db instance implementation. One possible  
GLP-			compliant implementation is suggested below.

2) OMERO.insight:

Administering image data hierarchical organization, data-sets and  
projects

  * COMMENT_2: (related to comment regarding admin flexibility):   
There has to be flexibility on the USER side on managing image data.  
I argue the user has to be able to remove data from the database, for  
example, in case of errors she/he made during import or in case of  
failed import executions.
Obviously, care should be taken in implementing DATA deletion from DB  
in order to comply to good laboratory practices (GLP) and ethical  
concerns.

		Possible controlled implementation of DATA deletion by user: USER  
moves it to "to be deleted" dataset or folder or other container and  
then admin delets upon permission from group owner or group leader.   
This would 		prevent accidental deletion of image data and malicious  
deletion of "not wanted" data. Specific options should be set  
depending on level of security privileges of individual user.

  * COMMENT_3: There has to be flexibility in administering image  
hierarchical organization on the side of end-user (i.e. scientist):
User has to be able to reassign flexibly image data from one data-set  
or project to another with the possibility of removing it from  
previous data-sets (even remove it from DB, see above).
At present I did not find beta3 facilities for performing these tasks.

3) OMERO.importer:

Administering batch import of images

COMMENT_ 4: There has to be a better way of batch-handling rendering  
settings, pixel properties and metadata options. This is particularly  
important in case of large data-sets migration into the database and  
as a consequence of poor metadata encoding in certain proprietary  
file formats (for examples see below).

EXAMPLE: during my import tests of various proprietary image data  
formats (.lif, .liff, .lsm, .stk, .tiff) I noticed that wavelength  
rendering, z- versus t- slices interpretation, sub-file hierarchy  
interpretation (see especially .lif and .liff) was often problematic.  
If left uncorrected this would definitely deter use.

SUGGESTION OF POSSIBLE SOLUTION:  user is allowed to set the correct  
metadata, pixel properties and rendering parameters upon batch import  
in order not to have to do it manually (which would defy the whole  
purpose of our collective exercise).  In addition there should be the  
possibility of batch changing rendering settings to whole data-sets  
and whole projects.

I noticed that OMERO.importer does furnish an option (METADATA  
DEFAULTS)  but upon several trial in various permutations the use of  
this did not change the outcome of image rendering. This might be due  
to poor knowledge of the program but if there is a way of doing it is  
very well disguised. I think it is very important to improve this for  
beta4 release.

Importing tests of various proprietary image data formats

*COMMENT_5: import of specific file formats

     * .lsm files imported properly but...
           o the wavelenght information was not interpreted correctly  
(see below on comments on Rendering)

     * .lif files: the import failed miserably.
One of the two files did not import, the other imported into its  
individual images but the images appeared as "crosses" and no image  
data corresponded to the files.
           a second attempt also failed; this time no images were  
imported

     * .stk worked fine but...:
           o DID not assign properly z veruss t and there is no way  
of manually changing it.

     * .liff worked fine but ...:
           o All images are in the same file. This is a problem  
with .liff as the different images could be z layers or t frames or  
various experiments all together. Not sure how to solve this. Would  
require much more flexibilty at import depending on file to import.

     *.tiff worked fine but...:
            Images pixel properties and metadata were not imported at  
all in the database. I imagine this is due to the .tiff format itself  
and I imaging the solution is not so easy. I think this case really  
underscores the importance for users to be able to set pixel  
properties and metadata in batch contextually to import or after import.

Rendering images

The rendering of images worked fine. Viewer works well, it is fast  
and has many nice features.

     * Rendering setting can be changed and rendering history can be  
stored. This is great.
     * Rendering can be copy-and-pasted to other images. This is  
great but...

     * COMMENT_6 : copy and paste of rendering settings should be  
doable in batch format. For example to be able to change the  
rendering settings of the entire content of a dataset or project.  
This is particularly important as the metadata handling is still not  
perfect and might never be. The formats are just too different and  
change frequently. So there needs to be control at import on  
rendering of for example wave length or z layers versus t series.  
This in certain formats is just nor "read" properly from the the  
metadata and the user has to be able to change it.

This is all folks!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-users/attachments/20090113/545bf4d2/attachment.html>