<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Andrew and list subscribers, <div><br></div><div>I have some comments to add regarding the OME.TIFF and OME.XML requirements for changes. The current description of our issue is:</div><div><span class="Apple-style-span" style="font-family: 'Lucida Grande', Arial, sans-serif; font-size: 12px; line-height: 18px; "><pre class="wiki" style="margin-top: 10px; margin-right: 5px; margin-bottom: 10px; margin-left: 5px; padding-top: 6px; padding-right: 6px; padding-bottom: 6px; padding-left: 6px; border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; border-left-width: 1px; border-top-style: solid; border-right-style: solid; border-bottom-style: solid; border-left-style: solid; border-top-color: rgb(221, 221, 221); border-right-color: rgb(221, 221, 221); border-bottom-color: rgb(221, 221, 221); border-left-color: rgb(221, 221, 221); background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: rgb(248, 248, 248); font-family: Monaco, monospace; position: static; z-index: auto; ">* EMBL Screening (Ruben Muñoz, Jan Ellenberg)
* Not duplicating XML for each field, _plane_, etc.</pre></span></div><div><span class="Apple-style-span" style="font-family: 'Lucida Grande', Arial, sans-serif; font-size: 12px; line-height: 18px; "></span></div><div>I would like to add that our use case, will apply to each user of the OME.TIF multi-file export option. </div><div><br></div><div>We previously pointed out that the number of planes that are stored per OME-TIFF has a big impact in each file's size. For multi-file datasets, the conversion output will be exponentially bigger than the raw data.</div><div><br></div><div>At EMBL-Heidelberg HCS Facility, we have used this as internal standard, with the pre-requisite of having one single plane per file. </div><div>The reasons to do that can be summarized: gives maximum compatibility with software for image processing, online control of the microscope and visualization, even after instrument/power failure. This software includes in-house developments: CellCognition, Micropilot, Cellbase and 3rd-party projects: CellProfiler, Image J/FIJI.</div><div><br></div><div>Given this scenario we found OME.TIF convenient because it has the correct conversion tools and an evolving metadata structure, in addition the commercial adoption of the format is growing.</div><div><br></div><div>In the practice, a lot of the metadata consist in "<Plate>", "<Image>" and "<Pixel>" elements (describing the SPW, dimensionally and the references to the files in the set). </div><div><br></div><div>That can be prohibitive at the processing and the storage stage.</div><div>Some options to simplify the format have ben discussed as follows:</div><div><br></div><div> - The master/slave approach. All files will reference the one that contains the complete headers.</div><div> - "<Plate>", "<Image>" and "<Pixel>" elements could be grouped when similar (e.g. reg. expressions following a pattern)</div><div> - The "<Plate>", "<Image>" and "<Pixel>" could be extracted to a separate file.</div><div><br></div><div>The first alternative was supported by Andrew. I suggested the second, but the project philosophy is opposite to the third. </div><div><br></div><div>Are there other suggestions? I would like to keep this discussion open and to help to define more details if needed.</div><div><br></div><div>Best,</div><div>Rubén</div><div><br><div><div>On Dec 7, 2010, at 4:03 PM, <a href="mailto:ome-devel-request@lists.openmicroscopy.org.uk">ome-devel-request@lists.openmicroscopy.org.uk</a> wrote:</div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>Date: Tue, 7 Dec 2010 13:07:49 +0000<br>From: Andrew Patterson <<a href="mailto:ajpatterson@lifesci.dundee.ac.uk">ajpatterson@lifesci.dundee.ac.uk</a>><br>To: <a href="mailto:ome-devel@lists.openmicroscopy.org.uk">ome-devel@lists.openmicroscopy.org.uk</a>,<br><span class="Apple-tab-span" style="white-space:pre"> </span><a href="mailto:ome-users@lists.openmicroscopy.org.uk">ome-users@lists.openmicroscopy.org.uk</a><br>Subject: [ome-devel] OME-XML Updates<br>Message-ID:<br><span class="Apple-tab-span" style="white-space:pre"> </span><B5B2766B-2357-40C1-B1DD-06CCEC3A62C9@lifesci.dundee.ac.uk><br>Content-Type: text/plain; charset=us-ascii<br><br>Hello OME-XML & OME-TIFF users and potential users,<br><br>We are in the process of compiling requirements for changes to the way our OME-XML and OME-TIFF formats work. This is in response to the new ways people are wanting to use our formats, and drawbacks they have come across when storing datasets in certain circumstances.<br><br>Examples we have so far include:<br> * storing large datasets, one plane per OME-TIFF: this is a valid way to want to store data, but one which at the moment causes metadata duplication on disk.<br> * creating a 'lite' OME-TIFF for display or to pass to external applications.<br><br>A full list of our current thoughts is on the requirement ticket:<br>http://trac.openmicroscopy.org.uk/omero/ticket/3535<br><br>Some of these changes may effect key features of our formats, e.g. our current insistence that all matadata is stored in the same file as the image data. <br><br>We would really like to have your input on this feature, or any others.<br><br>If you have a use case that you think would help guide out future work we would love to hear from you. If you can reply on either of the mailing lists (OME-USER or OME-DEVEL), it will let others see and join in!<br><br>Thanks again for your help and support. <br><br>Cheers,<br><br>Andrew<br><br>--<br>Andrew Patterson<br>ajpatterson@lifesci.dundee.ac.uk<br>Software Developer, Open Microscopy Environment<br>Wellcome Trust Centre for Gene Regulation & Expression, University of Dundee<br></div></blockquote></div><br></div></body></html>