<div dir="ltr">Hi Chris,<div><br></div><div><div>> You mention one reason for this below, which is that people tend to</div><div>> lose the companion file. Are there other reasons to avoid doing this?</div></div><div><br></div><div>People tend to lose it, and also to edit it. There are a certain class of people who would never ever edit it, for fear of breaking something. But then there are a class of users who do these sorts of things, and then get confused when things stop working.</div><div><br></div><div>A few years back, LOCI explored the idea of allowing edits to the companion file to "take precedence" over what is in the embedded OME-XML, as long as the former was well-formed, but that was part of a now-long-abandoned "OME Metadata Editor" project. Nothing like that ever became standard across the whole suite of OME tools.</div><div><br></div><div>One of OME's founding principles for data storage was that your whole dataset—pixels and metadata—should be stored in one single file, to minimize the chance of data loss. But that attitude has certainly evolved a lot over the past 15 years, and these days I don't think anyone is too militant about it. I just wanted to mention that historically it has been an issue in practice. But I guess Micro-Manager has plenty of evidence/experience with its metadata.txt file: how often do people lose that? etc.</div><div><br></div><div><div>> We also cannot rely on being able to embed the XML in every TIFF</div></div><div><br></div><div>Yeah, I wouldn't think you should embed it in _every_ TIFF. But probably more than one would be nice, in case the "lynchpin" TIFF gets lost.</div><div><br></div><div><div>> we may butt up against the 4GB limit</div></div><div><br></div><div>Heh, it might not be a big deal, since the limit is not actually 4GB... but rather 32-bit offset pointer and 32-bit length, yeah? So as long as the OME-XML is appended to the very end of the file, and _starts_ before the 4GB cutoff, and is less than another 4GB in length (highly likely ;-), you should be OK? Worth testing anyway.</div><div><br></div><div>Regards,</div><div>Curtis</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><span style="font-size:12.8px">--</span></div><div><span style="font-size:12.8px">Curtis Rueden</span><br></div><div><span style="font-size:12.8px">LOCI software architect - <a href="http://loci.wisc.edu/software" target="_blank">http://loci.wisc.edu/software</a></span></div><div>ImageJ2 lead, Fiji maintainer - <span style="font-size:12.8px"><a href="http://imagej.net/User:Rueden" target="_blank">http://imagej.net/User:Rueden</a></span></div><div>Did you know ImageJ has a forum? <a href="http://forum.imagej.net/" target="_blank">http://forum.imagej.net/</a></div><div><br></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Apr 13, 2016 at 1:49 PM, Chris Weisiger <span dir="ltr"><<a href="mailto:cweisiger@msg.ucsf.edu" target="_blank">cweisiger@msg.ucsf.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi Curtis,<br><br></div>First I just want to say thank you very much for the detailed breakdown. It's great to get insight into the design processes that other groups have gone through, to help guide our own design decisions and avoid reinventing wheels. In the long term, we're going to be taking a close, hard look at how we deal with files and what we ought to be doing differently; there are things we want to be able to do that the current format is not well-suited for, in particular dealing with high-speed acquisitions and handling data whose parameters can't be known prior to starting writing. That's all matters for another day, however.<br></div><div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Apr 13, 2016 at 11:16 AM, Curtis Rueden <span dir="ltr"><<a href="mailto:ctrueden@wisc.edu" target="_blank">ctrueden@wisc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Chris,<div><br></div><div>TL;DR: Embed the OME-XML into one or more OME-TIFF headers. Do not rely solely on a companion file.</div></div></blockquote><div><br></div></span><div>You mention one reason for this below, which is that people tend to lose the companion file. Are there other reasons to avoid doing this?<br><br></div><div>In µManager currently, there is already only one file that contains the OME-XML, and that file must be present if users are to load their data. So effectively, we already have one "companion file", that happens to be bundled together with image data. If users lose the special TIFF that contains the XML, then they will be unable to load their data.<br><br></div><div>One of the goals of this change is to make it easier for users to separate out individual subsets of their data. For example, if a user does a 96-well-plate acquisition and wants to be able to look at a single well, currently they must retain the entire dataset, or else figure out which of the TIFF files contains the XML; otherwise that single well's data cannot be loaded. <br><br>Please do correct me if I'm wrong, but doesn't the BinaryOnly system only allow you to point to a single source for the "external" XML? Thus if we rely on XML embedded in the TIFF headers, we cannot use the external file as a fallback, and thus are unable to separate a single TIFF from the dataset as a whole.<br><br></div><div>We also cannot rely on being able to embed the XML in every TIFF, as we may butt up against the 4GB limit, and the XML cannot be written until after acquisition is completed. Currently we write the XML to the tail end of one of the TIFFs (that has enough room under the 4GB limit), and then modify the headers of each TIFF to point to that location.<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div class="gmail_quote">-Chris<br></div><div class="gmail_quote"><br></div></font></span></div></div></div>
<br>_______________________________________________<br>
ome-devel mailing list<br>
<a href="mailto:ome-devel@lists.openmicroscopy.org.uk">ome-devel@lists.openmicroscopy.org.uk</a><br>
<a href="http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel" rel="noreferrer" target="_blank">http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel</a><br>
<br></blockquote></div><br></div>