[Insight-users] 32 bit (float) TIFFs ? HDF5 ?

[Robert.Atwood at diamond.ac.uk]

Hi, Matt, Kent:

To clarify: I am using itk4.0 (MASTER from git -- about 2 weeks ago) which does not read TIFF 32 bit images



I see indeed that there is an HDF5ImageIO.h, is there any greater documentation of this? I don't see what this does; as far as I know one must normally give some clue as to the layout of the hdf5 , or how does the IO decide which of what may be many possible datasets contained in the hdf5, to return as an image?
Or, is it expecting a certain layout? What is that layout? 

itkHDF5ImageIO.cxx:const std::string ImageGroup("/ITKImage");

Does it only read image in a group called "/ITKImage"?


If the reader could be passed 'SetImageGroupName("myImageName")' for example, and a couple of other parameters, overriding the defaults, then perhaps it could easily be used? or is it more suitable to have a whole new module ?
Thanks


________________________________________
From: Matt McCormick [matt.mccormick at kitware.com]
Sent: Sunday, January 15, 2012 11:23 PM
To: Atwood, Robert (DLSLtd,RAL,DIA)
Cc: insight-users at itk.org; Williams, Norman K
Subject: Re: [Insight-users] 32 bit (float) TIFFs ? HDF5 ?

Hi Robert,

On Sun, Jan 15, 2012 at 4:24 PM,  <Robert.Atwood at diamond.ac.uk> wrote:
> Dear All:
>
> I find that attempting to input 32-bit (floating point valued) TIFF images gives me a message indicating that the ITK import method doesn't handle this. Why is this, is it especially difficult or has there just not been demand?
>

There have been recent advances in the TIFF support, but there is
always more to do.  Make sure you are using ITKv4 for the best
results.

> Though, we are migrating to HDF5 via NeXus  http://www.nexusformat.org/   hoping to get away from the inherent problem of TIFFS (too many files for the poor little data storage system, much too small limits for stacked-tiffs...) but that may have its own problems , I personally can't get the C++ library to say 'hello world' even -- what stage is HDF5 in ITK at? Here, NeXuS is the preferred flavour of HDF5, and so far the performance benefits seem to be worth the convenience costs  (few applications read it) -- so if we really go that route I'd like to try to help ensure that ITK -- therefor hopefully all applications that make use of the library ...  can read this stuff. But I'm not the programmer , I can try to recommend that our programmers lend assistance if it helps increase usability of the data form that works best for the data acquisition side; so I'd like to clarify the current hdf5 situation.

Kent Williams did a nice job of putting together an HDF5-based
reader/writer for ITK images in ITKv4.  See Modules/IO/HDF5.  You
could do something similar for the NeXuS format by translating the
NeXuS fields to their ITK counterparts.  The hard part of the HDF5
backend support is already there.  The way of doing this would be to
create a new ITKv4 Module, then submit it to the Insight Journal.

Thanks,
Matt

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom