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

Mon Apr 6 23:33:07 BST 2015

Hi Heinrich,

> I see you have the exact same omexml metadata string for every IFD.

Nope, you only put the OME-XML string into the first IFD of each TIFF file.
Not subsequent IFDs.

> I was under the impression that you needed to specify the ZCT position
> for every plane separately.

You refer to the TiffData elements, right? If so, you do _not_ need a
separate TiffData element per plane. You only need to define the mapping
from IFD to ZCT coordinates in an unambiguous way. For full details, see:

http://openmicroscopy.org/site/support/ome-model/ome-tiff/specification.html#the-tiffdata-element

That said, you _would_ need to have one Plane element per plane if you want
to include plane-specific metadata such as timings or plane-specific stage
positions.

> However, as it is the same string for every plane, couldn’t you just
> write it once into the file and point at that position from every
> IFD’s ImageDescription?

Again, you do not need to populate the ImageDescription of any IFD other
than the first.

Hope that helps,
Curtis

On Wed, Mar 25, 2015 at 12:17 PM, Grabmayr, Heinrich <
Heinrich.Grabmayr at ph.tum.de> wrote:

>  Hi Curtis
>
>
>
> Thanks for this insight!
>
> I have one more question left regarding the WiscScan code. As I see you
> have the exact same omexml metadata string for every IFD. From my earlier
> work on this, I was under the impression that you needed to specify the ZCT
> position for every plane separately. But I just read that this is optional.
>
> However, as it is the same string for every plane, couldn’t you just write
> it once into the file and point at that position from every IFD’s
> ImageDescription?
>
>
>
> Cheers
>
>    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/20150406/3a4e288a/attachment.html>