[ome-users] OMERO clients user's comments

[jburel]

Dear Caterina


Thanks for your feedback.
As Jason mentioned, some functionalities are already there or will be  
in the coming releases.


>> 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.
>>


Note that the rendering history is not stored in the DB.
It is currently possible to select the rendering settings of an image  
and then apply them to all the images of a dataset or a project. We  
have noticed that this operation can be slow, we are tracking down the  
problem.

We will probably need to improve the workflow so that the option is  
clearly availables.


>> 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.
>>

Delete for images will be in beta4 (mid-feb). It will be also possible  
to delete a dataset (/project) and all the images contained in the  
dataset (/project)
In this first implementation, this operation can take time, we will  
have a faster implementation in beta4.1/4.2

As Jason mentioned, Moving images between datasets is already available.
Same as above, we  need to improve the workflow so that the option is  
clearly available.


Thanks  again for your comments


Jmarie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-users/attachments/20090114/580f8564/attachment.html>