[SCIFIO] Your visit and Bioformats

Tue Jul 21 16:08:10 CDT 2015

Hi Teddy & Christian,

Teddy Voinson wrote:
> I am currently working on interfacing Amira with SCIFIO using the ITK4
> bridge that you mentioned

Very glad to hear it is useful!

I mentioned the ITK bridge as an example of how to interface Bio-Formats
and/or SCIFIO with native C++ code. But I did not intend to imply that it
would meet your use case "out of the box." It uses pipes and is
surprisingly fast, and the code is not too complex, so it serves as a nice
example of how to integrate Java with non-Java using pipes.

You have a few different options here for how to improve the code to suit
your needs:

1) Fork scifio-itk-bridge and scifio-imageio, then hack them to match your
use case.

2) Generalize scifio-itk-bridge so that the C++ side has more control over
the "info" command [1]. This could be as simple as adding a new command
e.g. "info-verbose" that includes more metadata fields. It would do no harm
to add this to the Java side, even if ITK doesn't use it, if it makes the
Java library usable for you without further modifications.

If you opt for option 2, you are warmly welcome to submit a PR on GitHub
[2] containing the changes you need. And if you require technical
assistance with any details, we are happy to help.

Christian Wietholt wrote:
> We were wondering if you know of any trick that could give us access
> to all the header information through the ITK bridge, e.g. a pointer
> to the headers of all TIFF files in a data set. Do you think that the
> ITK bridge is capable of this, or do you have a different suggestion?

Adding support for delivering that information across the pipe would be
very easy on the Java side, since Bio-Formats certainly knows which TIFF
files belong to the dataset.

However, the next issue then becomes how you are consuming that information
the C++ side. It sounds like your software is actually using ITK. Simplest
then might be to simply add more key/value pairs to the dictionary which is
passed across the pipe and stored in the ITK image [3]. If we do that, then
you would require zero changes on the C++ side—only additions on the Java
side as discussed above. And then your own C++ code would extract the
values of interest from the ITK object's dictionary.

But if you are only using ITK because that's what scifio-imageio provides,
you may want to consider crafting your own C++ "client" which communicates
with the scifio-itk-bridge "server" in its own way, for maximum flexibility.

I have CCed the SCIFIO mailing list, which includes Mark Hiner, the primary
author and maintainer of the SCIFIO ITK bridge components. Perhaps he will
have additional thoughts and suggestions that I missed.

Regards,
Curtis

[1]
https://github.com/scifio/scifio-itk-bridge/blob/3d47613686be450d4a672992fb499793cf4d480e/src/main/java/io/scif/itk/SCIFIOITKBridge.java#L250-L379

[2] http://imagej.net/GitHub

[3]
https://github.com/scifio/scifio-imageio/blob/9346dbbf30b64645ebd9546fbf82f5438dc88a48/src/itkSCIFIOImageIO.cxx.in#L752-L754

On Tue, Jul 21, 2015 at 2:59 PM, Wietholt, Christian <
Christian.Wietholt at fei.com> wrote:

> The main problem right now is the header information of OME TIFF files
> that is stored in:
>
>
>
> <OME:TiffData IFD="0" FirstZ="0" FirstT="0" FirstC="0" />
>
>
>
> This information does not seem to be transmitted through the bridge using
> the ‘ReadImageInformation’ function, and we are relying solely on the file
> names to sort the order of slices, channels and time steps. I think this is
> okay at the moment for the z information, but can certainly cause issues
> when using 4D or 5D images and a none standard file naming scheme. Thus, we
> would prefer access to the above header information. In addition, we
> typically try to import all relevant header information into Amira and try
> to add as much information to the data object in Amira as possible. We
> typically do this in form of parameter bundles that are stored in the
> header of the Amira Mesh file. This will give access to all information
> about the file to Amira users.
>
>
>
> Teddy and Nicolas mentioned to me that the 8 or 9 functions in the ITK
> bridge only provide access to the information that Teddy listed in his
> email. We were wondering if you know of any trick that could give us access
> to all the header information through the ITK bridge, e.g. a pointer to the
> headers of all TIFF files in a data set. Do you think that the ITK bridge
> is capable of this, or do you have a different suggestion?
>
>
>
> I would greatly appreciate your input on this.
>
>
>
> Many Thanks,
>
>
>
> Christian
>
>
>
>
>
>
>
> *Christian Wietholt, Ph.D. *| Product Manager, Life Sciences
>
> *FEI **Visualization Sciences Group*
>
> 16700 Park Row Dr.      Houston, Texas 77084      USA
>
> *T* +1 630 687 0215 *fei.com <http://fei.com/>*
>
> *Explore. Discover. Resolve.*
>

On Mon, Jul 20, 2015 at 12:21 PM, Voinson, Teddy <Teddy.Voinson at fei.com>
wrote:

>  Hi,
>
>
>
> I am one of the developer of Amira and I am following Christian message to
> let you know that I am currently working on interfacing Amira with SCIFIO
> using the ITK4 bridge that you mentioned when you visited us.
>
> I am using the itk 4.7.2 bridge in order to read OME-TIFF file format and
> I am probably doing something wrong.
>
> You can probably help me.
>
>
>
> Currently, using the ITK bridge, I can get some file information with the
> SCIFIOImageIO::ReadImageInformation().
>
> I join an example image to this message.
>
> On the example image, I get only:
>
> Interleaved
>
> 0
>
> LittleEndian
>
> 1
>
> PixelType
>
> 3
>
> SizeX
>
> 1344
>
> SizeY
>
> 1024
>
> SizeZ
>
> 1
>
> SizeT
>
> 1
>
> SizeC
>
> 1
>
> RGBChannelCount
>
> 1
>
> PixelsPhysicalSizeX
>
> 1.027921E-4
>
> PixelsPhysicalSizeY
>
> 1.027921E-4
>
> PixelsPhysicalSizeZ
>
> 1.244898E-4
>
> PixelsPhysicalSizeT
>
> 1.0
>
> PixelsPhysicalSizeC
>
> 1.0
>
> UseLUT
>
> False
>
> Which is clearly not the complete header of the file (which is also
> attached to the email).
>
>
>
> Do you have any clue on how to get the other information of the header?
>
> Thanks in advance,
>
>
>
> Teddy
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://scif.io/pipermail/scifio/attachments/20150721/9e0c1088/attachment.html>