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

Mon Jun 29 20:50:05 BST 2015

Hi Heinrich

Alternatively there is apparently a precompiled  bio-formats .dll in the pipeline, which is what we’ve been waiting  for to do this job.

Ian

On 29 Jun 2015, at 20:44, Curtis Rueden <ctrueden at wisc.edu<mailto:ctrueden at wisc.edu>> wrote:

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<mailto: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> [mailto: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<mailto: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<mailto: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

_______________________________________________
ome-devel mailing list
ome-devel at lists.openmicroscopy.org.uk<mailto:ome-devel at lists.openmicroscopy.org.uk>
http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20150629/6e7fa1cd/attachment-0001.html>