# Updating ITK's HDF5
**URL:** https://discourse.itk.org/t/updating-itks-hdf5/472
**Category:** Engineering
**Created:** [December 1, 2017, 12:18am UTC](https://discourse.itk.org/t/updating-itks-hdf5/472 "2017-12-01T00:18:35Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [August 7, 2018, 3:48pm UTC](https://discourse.itk.org/t/updating-itks-hdf5/472/21 "2018-08-07T15:48:57Z")
What are your errors? Can you do an experimental build? The dashboard is pretty clean at the moment.
---
### Author:  [@gdevenyi](https://discourse.itk.org/u/gdevenyi)
#### Post date: [August 7, 2018, 3:51pm UTC](https://discourse.itk.org/t/updating-itks-hdf5/472/22 "2018-08-07T15:51:01Z")
As I described above, it produces a broken MINC file on write, no errors.
The 1.8 -\> 1.10 change is likely the culprit. I’ll take a look at whether there’s any big HDF5 changes which may break libminc for this.
---
### Author:  [@gdevenyi](https://discourse.itk.org/u/gdevenyi)
#### Post date: [August 7, 2018, 3:53pm UTC](https://discourse.itk.org/t/updating-itks-hdf5/472/23 "2018-08-07T15:53:54Z")
First note here:
[https://support.hdfgroup.org/HDF5/docNewFeatures/](https://support.hdfgroup.org/HDF5/docNewFeatures/)
> File Format Changes
>
> This release includes changes in the HDF5 storage format. These changes come into play when one or more of the new features is used or when an application calls for use of the latest storage format (H5Pset\_libver\_bounds).
>
> Due to the requirements of some of the new features, the format of a 1.10.x HDF5 file is likely to be different from that of a 1.8.x HDF5 file. This means that tools and applications built to read 1.10.x files will be able to read a 1.8.x file, but tools built to read 1.8.x files may not be able to read a 1.10.x file.
>
> If an application built on HDF5 Release 1.10 avoids use of the new features and does not request use of the latest format, applications built on HDF5 Release 1.8.x will be able to read files the first application created. In addition, applications originally written for use with HDF5 Release 1.8.x can be linked against a suitably configured HDF5 Release 1.10.x library, thus taking advantage of performance improvements in 1.10.
I’m betting I’m getting bitten by this.
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [August 7, 2018, 8:13pm UTC](https://discourse.itk.org/t/updating-itks-hdf5/472/24 "2018-08-07T20:13:35Z")
That might not be the reason. The [function](https://support.hdfgroup.org/HDF5/doc/RM/RM_H5P.html#Property-SetLibverBounds) which deals with that is being called from MINC [here](https://github.com/InsightSoftwareConsortium/ITK/blob/c0f15f4b5e4be0afbcafea8b7f6c1a5c025eba5f/Modules/ThirdParty/MINC/src/libminc/libsrc/hdf_convenience.c#L2344) and [here](https://github.com/InsightSoftwareConsortium/ITK/blob/c0f15f4b5e4be0afbcafea8b7f6c1a5c025eba5f/Modules/ThirdParty/MINC/src/libminc/libsrc2/volume.c#L222) with parameter `H5F_LIBVER_18`. Perhaps it needs to be called in a few more places?
---
### Author:  [@gdevenyi](https://discourse.itk.org/u/gdevenyi)
#### Post date: [August 7, 2018, 8:24pm UTC](https://discourse.itk.org/t/updating-itks-hdf5/472/25 "2018-08-07T20:24:32Z")
Indeed, it looks like the only two instances of files being created are being versioned properly with the function, however I can’t h5dump the resulting files with an older HDF5 version.
---
### Author:  [@gdevenyi](https://discourse.itk.org/u/gdevenyi)
#### Post date: [August 7, 2018, 8:26pm UTC](https://discourse.itk.org/t/updating-itks-hdf5/472/26 "2018-08-07T20:26:46Z")
This looks problematic:
>
---
### Author:  [@imikejackson](https://discourse.itk.org/u/imikejackson)
#### Post date: [August 8, 2018, 1:30am UTC](https://discourse.itk.org/t/updating-itks-hdf5/472/27 "2018-08-08T01:30:06Z")
There were some examples on the HDF5 list on how to setup your codes to use HDF5 1.10.x but still write a 1.8.x compatible file. That bit of code is going to mess that up. If you search the HDF5 list archives you should be able to find the discussion.
---
### Author:  [@gdevenyi](https://discourse.itk.org/u/gdevenyi)
#### Post date: [August 8, 2018, 1:40pm UTC](https://discourse.itk.org/t/updating-itks-hdf5/472/28 "2018-08-08T13:40:31Z")
Thanks @imikejackson, your comment helped me google the right terms to find this:
> **[Why should I care about the HDF5 1.10.2 Release? - The HDF Group](https://www.hdfgroup.org/2018/04/why-should-i-care-about-the-hdf5-1-10-2-release/)**
>
> On March 30th, we announced the release of HDF5 version 1.10.2. With this release, we accomplished all the tasks planned for the major HDF5 1.10 series. It is time for applications to start migrating (or start their migration) from HDF5 1.8 to the...
Which describes how to get 1.10.x to generate 1.8.x compatible files.
I’m implementing that change upstream. Then we’ll need an external resync.
---
### Author:  [@gdevenyi](https://discourse.itk.org/u/gdevenyi)
#### Post date: [August 8, 2018, 5:11pm UTC](https://discourse.itk.org/t/updating-itks-hdf5/472/29 "2018-08-08T17:11:07Z")
Looks like I’ve fixed it. I have a PR open on libminc upstream here:
>
---
### Author:  [@gdevenyi](https://discourse.itk.org/u/gdevenyi)
#### Post date: [August 8, 2018, 5:14pm UTC](https://discourse.itk.org/t/updating-itks-hdf5/472/30 "2018-08-08T17:14:03Z")
Note that this on-disk format change will make .hdf5 files generated by ITKv5 non-backwards compatible with ITKv5 unless a similar change is made.
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [August 8, 2018, 5:49pm UTC](https://discourse.itk.org/t/updating-itks-hdf5/472/31 "2018-08-08T17:49:32Z")
You said you planned to update ITK’s version of MINC library after the upstream fixes it? Will that solve the problem?
For pure HDF5, here is a [patch](http://review.source.kitware.com/#/c/23633/) which should enable the backwards compatible format.
---
### Author:  [@gdevenyi](https://discourse.itk.org/u/gdevenyi)
#### Post date: [August 8, 2018, 6:33pm UTC](https://discourse.itk.org/t/updating-itks-hdf5/472/32 "2018-08-08T18:33:54Z")
@dzenanz While I have fixed it upstream, it looks like the actual writing of the file is done in such a way that the ITK takes over the write call
If I limit the HDF API to 1.8 using the cmake option, the MINC files are okay, but otherwise, still having an issue.
I’m digging into the MINC-ITK CXX glue layer now…
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [August 8, 2018, 6:45pm UTC](https://discourse.itk.org/t/updating-itks-hdf5/472/33 "2018-08-08T18:45:01Z")
Awesome! Are you on the HDF5 transform too?
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [August 8, 2018, 7:02pm UTC](https://discourse.itk.org/t/updating-itks-hdf5/472/34 "2018-08-08T19:02:27Z")
Not yet. And I am happy to let you do that one, if you so desire 😃
---
### Author:  [@gdevenyi](https://discourse.itk.org/u/gdevenyi)
#### Post date: [August 8, 2018, 8:27pm UTC](https://discourse.itk.org/t/updating-itks-hdf5/472/35 "2018-08-08T20:27:30Z")
@dzenanz
It looks like I’m being bitten now by the itk header def mangling that is done HDF5. Particularly right here:
>
How are we supposed to handle the mangled headers?
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [August 9, 2018, 1:31pm UTC](https://discourse.itk.org/t/updating-itks-hdf5/472/36 "2018-08-09T13:31:23Z")
> [@gdevenyi](#):
>
> H5F\_LIBVER\_18
The constant’s name is `H5F_LIBVER_V18`. I just took a [look](https://github.com/InsightSoftwareConsortium/ITK/blob/c0f15f4b5e4be0afbcafea8b7f6c1a5c025eba5f/Modules/ThirdParty/HDF5/src/itkhdf5/src/itk_hdf5_mangle.h), it is not being mangled (as it is not a public symbol, I suppose). It is defined in `H5Fpublic.h`, which you need to include.
---
### Author:  [@gdevenyi](https://discourse.itk.org/u/gdevenyi)
#### Post date: [August 9, 2018, 1:59pm UTC](https://discourse.itk.org/t/updating-itks-hdf5/472/37 "2018-08-09T13:59:33Z")
k, so I’m a bit confused.
That snippet of code I wrote to handle building against HDF5 1.8.x.
H5F\_LIBVER\_18 doesn’t exist in some earlier versions of 1.8, so I want it to correspond to LATEST in that case.
If I remove this code, MINCIO produces a proper file, however with it left in as-is it looks like somehow this snippit is redefining it.
---
### Author:  [@gdevenyi](https://discourse.itk.org/u/gdevenyi)
#### Post date: [August 9, 2018, 2:06pm UTC](https://discourse.itk.org/t/updating-itks-hdf5/472/38 "2018-08-09T14:06:44Z")
Oops, I see I linked the wrong version of the code, this is what I’m working with right now:
>
My comment above applies to this version of the code.
---
### Author:  [@gdevenyi](https://discourse.itk.org/u/gdevenyi)
#### Post date: [August 9, 2018, 2:19pm UTC](https://discourse.itk.org/t/updating-itks-hdf5/472/39 "2018-08-09T14:19:59Z")
Okay, my problem is H5F\_LIBVER\_V18 and related are actually typedef enumn, not define:
snip from H5public.h:
```auto
/* Library's format versions */
typedef enum H5F_libver_t {
H5F_LIBVER_ERROR = -1,
H5F_LIBVER_EARLIEST = 0, /* Use the earliest possible format for storing objects */
H5F_LIBVER_V18 = 1, /* Use the latest v18 format for storing objects */
H5F_LIBVER_V110 = 2, /* Use the latest v10 format for storing objects */
H5F_LIBVER_NBOUNDS
} H5F_libver_t;
```
So my ifndef always defines latest version.
I need to adjust the check to use something else.
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [August 9, 2018, 2:22pm UTC](https://discourse.itk.org/t/updating-itks-hdf5/472/40 "2018-08-09T14:22:12Z")
Compare `H5F_LIBVER_NBOUNDS` to `H5F_LIBVER_V18`? It should be equal for 1.8 and greater for 1.10.
[Previous page](https://discourse.itk.org/t/updating-itks-hdf5/472.md?page=1)
[Next page](https://discourse.itk.org/t/updating-itks-hdf5/472.md?page=3)