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

Mon Jun 29 20:44:15 BST 2015

Hi Heinrich,

I momentarily skimmed your example file using libtiff's tiffdump tool, and
I see:

  $ tiffdump teststack4.ome.tif
  teststack4.ome.tif:
  Magic: 0x4d4d <big-endian> Version: 0x2b <BigTIFF>
  OffsetSize: 0x8 Unused: 0
  Directory 0: offset 880 (0x370) next 1144 (0x478)
  ImageWidth (256) LONG (4) 1<6>
  ImageLength (257) LONG (4) 1<5>
  BitsPerSample (258) SHORT (3) 1<16>
  Compression (259) SHORT (3) 1<1>
  Photometric (262) SHORT (3) 1<1>
  ImageDescription (270) ASCII (2) 1<\0>
  StripOffsets (273) LONG8 (16) 1<7216>
  RowsPerStrip (278) LONG (4) 1<5>
  StripByteCounts (279) LONG (4) 1<60>
  XResolution (282) RATIONAL (5) 1<0>
  YResolution (283) RATIONAL (5) 1<0>
  ResolutionUnit (296) SHORT (3) 1<3>

Your ImageDescription IFD entry above looks wrong; it should report the
total length of the OME-XML string, rather than only 2 with a \0. It seems
your OME-XML is not being injected properly according to the scheme I
described earlier.

By comparison, an OME-TIFF file saved from ImageJ using the Bio-Formats
Exporter reports:

  ImageDescription (270) ASCII (2) 1261<<?xml version="1.0" enco ...>

To make your life easier, is there any chance you could simply call libtiff
from LabView? A quick web search suggests that others have tried to do this
in the past, some with success.

Regards,
Curtis

On Wed, Jun 24, 2015 at 12:07 PM, Grabmayr, Heinrich <
Heinrich.Grabmayr at ph.tum.de> wrote:

>  Hi Curtis,
>
> It has been a while, but now I am coming back to the matter of creating
> OME TIFFs from within LabView. I am writing a very minimal ome-xml in the
> beginning of the file, and point the imagedescription of  each IFD to that
> position. What I get out is a BigTiff file, but the ome-part doesn’t work.
> The xmlvalidator tells me there is a premature end of file in any tiff I
> create (which I checked and it shouldn’t be the case), and importing the
> image via the BioFormats importer to Fiji shows the correct planes, but the
> dimensions CZT are collapsed into one third dimension. Also, the ome-xml
> that I get is not the one I write in the file.
>
> I am attaching a small sample image – it should have dimension sizes x=6,
> y=5, c=2, z=3, t=4.
>
> Would it be possible for you to have a look at it and see where my mistake
> is?
>
>
>
> Thanks
>
>    Heinrich
>
>
>
> *From:* ctrueden.wisc at gmail.com [mailto:ctrueden.wisc at gmail.com] *On
> Behalf Of *Curtis Rueden
> *Sent:* 6 April, 2015 6:33 PM
> *To:* Grabmayr, Heinrich
> *Cc:* OME-devel mailing list
> *Subject:* Re: [ome-devel] using LabView to write ome-tiff? with java4cpp?
>
>
>
> 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/20150629/efda7bec/attachment-0001.html>