<div dir="ltr"><div class="gmail_quote"><div dir="ltr">Hi Heinrich,<span class=""><div><br></div><div>[Resending to the actual ome-devel list, since that address got mangled in the reply chain before.]</div><div><br></div><div><div>> Could you elaborate a bit on how you do the OmeXML injection into the</div><div>> completed tiff? And why can't the stub description be longer than 4</div><div>> chars?</div></div><div><br></div></span><div>According to the TIFF specification [1], an IFD Directory Entry has a type, a length and a value/offset. The length and value/offset are each 4 bytes. The clever thing is if the value fits into 4 bytes or less, it is inlined, but if the value is longer than 4 bytes, then those 4 bytes are treated as an offset into the file where the value is actually stored.</div><div><br></div><div>So, you tell libtiff to write "xx" into the ImageDescription field, which will cause it to create a directory entry for ImageDescription when writing the TIFF header. Then later, after libtiff has closed out the TIFF file and considers it done, you can append your actual OME-XML string to the file, then seek back to the ImageDescription directory entry and change the length from 2 (which was the length of "xx") to your actual OME-XML string length, and change the _value_ field to an _offset_ to the previous file length (since that is now the byte offset of the OME-XML string due to the append).</div><div><br></div><div><div>I pasted the C++ code we use in WiscScan to do this. Find it here:</div><div>   <a href="https://gist.github.com/ctrueden/6a91656fa9804d1a874a" target="_blank">https://gist.github.com/ctrueden/6a91656fa9804d1a874a</a><br></div><div><br></div><div>(In general that project is closed-source, so I cannot link you to the repository proper, unfortunately.)</div><div><br></div><div></div></div><div>We also have Java code in Bio-Formats that does this, which you could study:</div><div>  <a href="https://github.com/openmicroscopy/bioformats/blob/v5.1.0-m4/components/formats-bsd/src/loci/formats/tiff/TiffSaver.java#L736-L866" target="_blank">https://github.com/openmicroscopy/bioformats/blob/v5.1.0-m4/components/formats-bsd/src/loci/formats/tiff/TiffSaver.java#L736-L866</a><br></div><div><br></div><div>That code is actually a little more sophisticated that what I described above, since it does not _always_ overwrite the comment, depending on a few factors. But the overall approach is the same.<br><br></div><div>One other thing: be careful of TIFF files over 4GB. Those need to be written a little differently, as BigTIFF, which uses 64-bit offsets. The libtiff library _does_ currently handle this properly, but the code I linked here would need to change to handle that case, too.<br></div><div><br></div><span class=""><div>> For 64bit, I cannot find them, and I am not familiar (and don't have<br></div><div><div>> the infractructure set up) for makefile processing. Might you have a</div><div>> libtiff for 64bit to send me or a link?</div></div><div><br></div></span><div>Here is an SO question someone asked about that, with a self-answer using Visual Studio 2008:</div><div><br></div><div>  <a href="http://stackoverflow.com/q/13496980" target="_blank">http://stackoverflow.com/q/13496980</a><br></div><div><br></div><div>Maybe you could do something similar with a more recent version MSVS, assuming you are using that tool chain?</div><div><br></div><div>Regards,<br></div><div>Curtis</div><div><br></div><div>[1] <a href="https://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf" target="_blank">https://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf</a></div></div><div class=""><div class="h5"><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 19, 2015 at 8:01 PM, Grabmayr, Heinrich <span dir="ltr"><<a href="mailto:Heinrich.Grabmayr@ph.tum.de" target="_blank">Heinrich.Grabmayr@ph.tum.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Curtis,<br>
<br>
Thanks very much for all these options. I think that 4) sounds most practicable for me now. Could you elaborate a bit on how you do the OmeXML injection into the completed tiff? And why can't the stub description be longer than 4 chars?<br>
Also, for my old project, I used the precompiled 32bit libtiff dll (I think I got it via GnuWin32). For 64bit, I cannot find them, and I am not familiar (and don't have the infractructure set up) for makefile processing. Might you have a libtiff for 64bit to send me or a link?<br>
<br>
Thanks, Heinrich<br>
<div><div><br>
><br>
> > I am currently developing a microscope that is controlled by a LabView<br>
> > program and generates a massive amount of data output. As I like<br>
> > ome-tiff, I'd like to save my images in that format.<br>
><br>
> Your major options are:<br>
><br>
> 1) Wait for the native Bio-Formats C++ implementation [1], slated for OME<br>
> version 5.1 (and subject to change until 5.2).<br>
>  - Pro: No more need for Java on the acquisition machine!<br>
>  - Con: Non-trivial to build and deploy due to required dependencies.<br>
>  - Con: Not actually ready yet. ;-)<br>
><br>
> 2) Use the Bio-Formats C++ bindings [2], available now.<br>
>  - Pro: Provides access to the entire Bio-Formats API.<br>
>  - Con: Non-trivial to build and deploy due to required dependencies.<br>
><br>
> 3) Use an interprocess solution such as:<br>
>  - Subimager [3] -- used by CellProfiler<br>
>  - A pipes-based bridge [4] -- used by ITK<br>
>  - Pro: As fast as in-process solutions, with fewer dependencies.<br>
>  - Con: Requires some coding to conform to your project's requirements.<br>
><br>
> 4) Write TIFF using libtiff, injecting your own OME-XML at the end. General<br>
> approach:<br>
><br>
> - Write a stub ImageDescription comment (four chars or less; e.g., "xx")<br>
> using libtiff.<br>
><br>
> - Generate your own OME-XML, maybe using a C++ XML library of your<br>
> choice.<br>
><br>
> - Inject the XML string by appending it to the TIFF (fast), then seeking to the<br>
> ImageDescription offset and length fields of the TIFF and updating them<br>
> accordingly (also fast).<br>
><br>
> - This approach avoids needing to rewrite the entire TIFF file just to add<br>
> OME-XML later. This is how we do it in WiscScan, although we do use the<br>
> Bio-Formats C++ bindings (see option 2 above) for actually building the<br>
> OME-XML string itself using the Bio-Formats MetadataStore API.<br>
><br>
> Further reading:<br>
> <a href="http://loci.wisc.edu/software/interfacing-non-java-code" target="_blank">http://loci.wisc.edu/software/interfacing-non-java-code</a><br>
><br>
> Regards,<br>
> Curtis<br>
><br>
> [1] <a href="http://openmicroscopy.org/site/support/bio-" target="_blank">http://openmicroscopy.org/site/support/bio-</a><br>
> formats5.1/developers/cpp.html<br>
> [2] <a href="http://openmicroscopy.org/site/support/bio-formats5.0/developers/c-" target="_blank">http://openmicroscopy.org/site/support/bio-formats5.0/developers/c-</a><br>
> bindings.html<br>
> [3] <a href="https://github.com/CellProfiler/subimager" target="_blank">https://github.com/CellProfiler/subimager</a><br>
> [4] <a href="https://github.com/scifio/scifio-itk-bridge" target="_blank">https://github.com/scifio/scifio-itk-bridge</a><br>
</div></div></blockquote></div><br></div>
</div></div></div><br></div>