[ome-devel] Fwd: using LabView to write ome-tiff? with java4cpp?

[Curtis Rueden]

Hi Heinrich,

[Resending to the actual ome-devel list, since that address got mangled in
the reply chain before.]

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

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.

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

I pasted the C++ code we use in WiscScan to do this. Find it here:
   https://gist.github.com/ctrueden/6a91656fa9804d1a874a

(In general that project is closed-source, so I cannot link you to the
repository proper, unfortunately.)

We also have Java code in Bio-Formats that does this, which you could study:

https://github.com/openmicroscopy/bioformats/blob/v5.1.0-m4/components/formats-bsd/src/loci/formats/tiff/TiffSaver.java#L736-L866

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.

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.

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

Here is an SO question someone asked about that, with a self-answer using
Visual Studio 2008:

  http://stackoverflow.com/q/13496980

Maybe you could do something similar with a more recent version MSVS,
assuming you are using that tool chain?

Regards,
Curtis

[1] https://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf


On Thu, Mar 19, 2015 at 8:01 PM, Grabmayr, Heinrich <
Heinrich.Grabmayr at ph.tum.de> wrote:

> Hi Curtis,
>
> 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?
> 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?
>
> Thanks, Heinrich
>
> >
> > > I am currently developing a microscope that is controlled by a LabView
> > > program and generates a massive amount of data output. As I like
> > > ome-tiff, I'd like to save my images in that format.
> >
> > Your major options are:
> >
> > 1) Wait for the native Bio-Formats C++ implementation [1], slated for OME
> > version 5.1 (and subject to change until 5.2).
> >  - Pro: No more need for Java on the acquisition machine!
> >  - Con: Non-trivial to build and deploy due to required dependencies.
> >  - Con: Not actually ready yet. ;-)
> >
> > 2) Use the Bio-Formats C++ bindings [2], available now.
> >  - Pro: Provides access to the entire Bio-Formats API.
> >  - Con: Non-trivial to build and deploy due to required dependencies.
> >
> > 3) Use an interprocess solution such as:
> >  - Subimager [3] -- used by CellProfiler
> >  - A pipes-based bridge [4] -- used by ITK
> >  - Pro: As fast as in-process solutions, with fewer dependencies.
> >  - Con: Requires some coding to conform to your project's requirements.
> >
> > 4) Write TIFF using libtiff, injecting your own OME-XML at the end.
> General
> > approach:
> >
> > - Write a stub ImageDescription comment (four chars or less; e.g., "xx")
> > using libtiff.
> >
> > - Generate your own OME-XML, maybe using a C++ XML library of your
> > choice.
> >
> > - Inject the XML string by appending it to the TIFF (fast), then seeking
> to the
> > ImageDescription offset and length fields of the TIFF and updating them
> > accordingly (also fast).
> >
> > - This approach avoids needing to rewrite the entire TIFF file just to
> add
> > OME-XML later. This is how we do it in WiscScan, although we do use the
> > Bio-Formats C++ bindings (see option 2 above) for actually building the
> > OME-XML string itself using the Bio-Formats MetadataStore API.
> >
> > Further reading:
> > http://loci.wisc.edu/software/interfacing-non-java-code
> >
> > Regards,
> > Curtis
> >
> > [1] http://openmicroscopy.org/site/support/bio-
> > formats5.1/developers/cpp.html
> > [2] http://openmicroscopy.org/site/support/bio-formats5.0/developers/c-
> > bindings.html
> > [3] https://github.com/CellProfiler/subimager
> > [4] https://github.com/scifio/scifio-itk-bridge
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20150320/9f7f1540/attachment.html>