[ome-users] OMERO clients user's comments
Jason Swedlow
jason at lifesci.dundee.ac.uk
Tue Jan 13 23:31:33 GMT 2009
Dear Caterina-
Thanks for your comments. Indeed everything you have asked for is
going into Beta4, so you should see much of this either in mid-
February or possibly ~May/June. However, cut n paste of images
between datasets should work already in Beta3.2. Give it a try, and
if it is not working, let us know.
Just FYI, our updated roadmaps for 2009 are up at:
http://trac.openmicroscopy.org.uk/omero/roadmap
http://trac.openmicroscopy.org.uk/shoola/roadmap
Thanks for the great feedback-- this is really terrific, and very
useful. Anyone else want to weigh in?
Cheers,
Jason
On 13 Jan 2009, at 16:02, Caterina Strambio De Castillia wrote:
> 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!
>
>
>
> _______________________________________________
> ome-users mailing list
> ome-users at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users
**************************
Wellcome Trust Centre for Gene Regulation & Expression
College of Life Sciences
MSI/WTB/JBC Complex
University of Dundee
Dow Street
Dundee DD1 5EH
United Kingdom
phone (01382) 385819
Intl phone: 44 1382 385819
FAX (01382) 388072
email: jason at lifesci.dundee.ac.uk
Lab Page: http://www.dundee.ac.uk/lifesciences/swedlow/
Open Microscopy Environment: http://openmicroscopy.org
**************************
The University of Dundee is a Scottish Registered Charity, No. SC015096.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-users/attachments/20090113/980601c9/attachment.html>
More information about the ome-users
mailing list