<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Dear Caterina<div><br></div><div><br></div><div>Thanks for your feedback.</div><div>As Jason mentioned, some functionalities are already there or will be in the coming releases.</div><div><br></div><div><br></div><div><blockquote type="cite"><blockquote type="cite"><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="color: rgb(0, 0, 0); "><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "></div></div></span></div></blockquote></blockquote></div><div><br></div><div>Note that the rendering history is not stored in the DB. </div><div>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.</div><div><br></div><div>We will probably need to improve the workflow so that the option is clearly availables. </div><div><br></div><div><br></div><div><blockquote type="cite"><blockquote type="cite"><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></blockquote></blockquote><div><br></div><blockquote type="cite"><blockquote type="cite"><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></blockquote></blockquote><div><br></div><div>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)</div><div>In this first implementation, this operation can take time, we will have a faster implementation in beta4.1/4.2</div><div><br></div><div>As Jason mentioned, Moving images between datasets is already available. </div><div>Same as above, we need to improve the workflow so that the option is clearly available.</div><div><br></div><div><br></div><div>Thanks again for your comments</div><div><br></div><div><br></div><div>Jmarie</div></div></body></html>