<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div>Dear OMERO developers,</div><div><br></div><div>as you know from Mario's postings we have been actively working on our OMERO implementation and testing project.</div><div><br></div><div>One think I have been doing is to test the usability side of the clients.</div><div><br></div><div>All my comments pertains to test done using the latest DB and client-suite versions available.</div><div><br></div><div>OMERO.db beta 3.2</div><div>OMERO. clients suite 3.2.1</div><div> .importer pre beta4-4</div><div> .insight beta3.2</div><div> .editor main (3)1.0 _ not tested</div><div><br></div><div>Tests were done on a Mac PowerBook G4 (client side) and a Dual Processor Power PC G5 (server side).</div><div><br></div><div>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.</div><div><br></div><div>Best regards</div><div><br></div><div>Caterina</div><div><br></div><div><br></div><div>_______________________</div><div><br></div><div>LIST OF COMMENTS</div><div><br></div><div><span class="Apple-style-span" style="text-decoration: underline;"><font class="Apple-style-span" size="4"><span class="Apple-style-span" style="font-size: 14px;">1) OMERO.webadmin:</span></font></span></div><div><br></div><div><b>Administering scientists and groups</b></div><div><br></div><div>* COMMENT_1: I think it is important to allow admin more flexibility in the administration of users (i.e. scientists) and user's data</div><div> Specifically admin should be able to remove user and user data from data base. </div><div>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.</div><div><br></div><div>Possible scenarios that would require such a measure:</div><div><br></div><div>When a user leaves a facility and his or her data need to be migrated to a new site. </div><div>During testing</div><div>In case of user's mistakes (especially likely to happen during large data migration or at db first instance installations)</div><div>Insertion of "garbage data" in the db</div><div><br></div><div>At preset beta3 does not appear to allow users data to be deleted (in case it is there I did not find it).</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>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-<span class="Apple-tab-span" style="white-space:pre"> </span>compliant implementation is suggested below.</div><div><br></div><div><span class="Apple-style-span" style="text-decoration: underline; -webkit-text-decorations-in-effect: underline; "><font class="Apple-style-span" size="4">2) OMERO.insight:</font></span></div><div><br></div><div><b>Administering image data hierarchical organization, data-sets and projects</b></div><div><br></div><div> * 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.</div><div>Obviously, care should be taken in implementing DATA deletion from DB in order to comply to good laboratory practices (GLP) and ethical concerns.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>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 <span class="Apple-tab-span" style="white-space:pre"> </span>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.</div><div><br></div><div> * COMMENT_3: There has to be flexibility in administering image hierarchical organization on the side of end-user (i.e. scientist): </div><div>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).</div><div>At present I did not find beta3 facilities for performing these tasks. </div><div><br></div><div><br></div><div><span class="Apple-style-span" style="text-decoration: underline; -webkit-text-decorations-in-effect: underline; "><font class="Apple-style-span" size="4">3) OMERO.importer:</font></span></div><div><font class="Apple-style-span" size="4"><span class="Apple-style-span" style="font-size: 14px; text-decoration: underline;"><br></span></font></div><div><font class="Apple-style-span" size="4"><span class="Apple-style-span" style="font-size: 14px; "><span class="Apple-style-span" style="font-size: 12px; font-weight: bold; ">Administering batch import of images</span></span></font></div><div><b><br></b></div><div><font class="Apple-style-span" color="#000000">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).</font></div><div><font class="Apple-style-span" color="#000000"><br></font></div><div><font class="Apple-style-span" color="#000000">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.</font></div><div><font class="Apple-style-span" color="#000000"><br></font></div><div><font class="Apple-style-span" color="#000000">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.</font></div><div><br></div><div><font class="Apple-style-span" color="#000000">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.</font></div><div><br></div><div><br></div><div><b>Importing tests of various proprietary image data formats</b></div><div><br></div><div>*COMMENT_5: import of specific file formats</div><div><br></div><div> <span class="Apple-style-span" style="text-decoration: underline;">* .lsm files imported properly but...</span></div><div> o the wavelenght information was not interpreted correctly (see below on comments on Rendering)</div><div><br></div><div> <span class="Apple-style-span" style="text-decoration: underline;">* .lif files: the import failed miserably</span>. </div><div>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.</div><div> a second attempt also failed; this time no images were imported </div><div><br></div><div> <span class="Apple-style-span" style="text-decoration: underline;"> * .stk worked fine but...:</span></div><div> o DID not assign properly z veruss t and there is no way of manually changing it. </div><div><br></div><div> <span class="Apple-style-span" style="text-decoration: underline;"> * .liff worked fine but ...:</span></div><div> 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. </div><div><br></div><div> <span class="Apple-style-span" style="text-decoration: underline;">*.tiff worked fine but...:</span></div><div> 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.</div><div><br></div><div><font class="Apple-style-span" color="#000000"><b>Rendering images</b></font></div><div><br></div><div>The rendering of images worked fine. Viewer works well, it is fast and has many nice features.</div><div><br></div><div> * Rendering setting can be changed and rendering history can be stored. This is great.</div><div> * Rendering can be copy-and-pasted to other images. This is great but... </div><div> </div><div> * 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. </div> <br><div><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>This is all folks!</div><div><br></div></div></div></span></span><br class="Apple-interchange-newline"></span></span></span> </div><br></body></html>