[MINC-development] large attributes in MINC2 and upgrading to HDF5 version 1.8

[Vladimir S. FONOV]

Yes, it is easier to compile hdf5 separately in this case and tell itk 
to use it


On 13-11-27 01:39 PM, Soren Christensen wrote:
> Thanks. I have previously run into problems with this, when MINC2 was
> compiled against a different HDF version from that of ITK. Is there a
> good way to deal with that then?  Libminc in it's current form cannot
> build with the HDF in ITK can it?
> I suppose one can try to build both ITK and libMINC against the same
> system HDF, but the less one can leave ITK to it's default set up the
> better I guess, less problems.
> Sorry for the many questions - just exited about that fix as it will
> save me a lot of headaches.
>
> Thanks
> Soren
>
>
> On Wed, Nov 27, 2013 at 10:19 AM, Vladimir S. FONOV
> <vladimir.fonov at gmail.com <mailto:vladimir.fonov at gmail.com>> wrote:
>
>     Hello,
>
>     you will have to compile latest version of libminc and then specify
>     ITK_USE_SYSTEM_MINC and LIBMINC_DIR when building ITK.
>
>     I can also try to include this version of libminc in next release of
>     ITK ,if nobody objects.
>
>
>     On 13-11-27 01:15 PM, Soren Christensen wrote:
>
>         Hi Vladimir,
>            That sounds great. I've had that problem too. What is the
>         easiest way
>         to propagate your changes to ITK?  Is it to somehow merge
>         locally with
>         the ITK release branch or is there a better way?
>
>         Thanks
>         Soren
>
>
>         On Wed, Nov 27, 2013 at 10:07 AM, Vladimir S. FONOV
>         <vladimir.fonov at gmail.com <mailto:vladimir.fonov at gmail.com>
>         <mailto:vladimir.fonov at gmail.__com
>         <mailto:vladimir.fonov at gmail.com>>> wrote:
>
>              Hello Everybody,
>
>              I came across a problem in MINC2 , that total size of
>         attributes for
>              group was limited to 64k , which was creating problems in
>         storing
>              some dicom tags, for example dicom_0x0029:el_0x1020 is
>         sometimes
>              quite big, so together with other tags it would overfill
>         64k limit
>              and cause problems.
>
>              The problem didn't happen with MINC1 which didn't seem to
>         have this
>              limitation.
>
>              The solution for this problem is explained in
>         http://www.hdfgroup.org/HDF5/____doc/UG/13_Attributes.html
>         <http://www.hdfgroup.org/HDF5/__doc/UG/13_Attributes.html>
>
>              <http://www.hdfgroup.org/HDF5/__doc/UG/13_Attributes.html
>         <http://www.hdfgroup.org/HDF5/doc/UG/13_Attributes.html>> , see
>              "Large Attributes Stored in Dense Attribute Storage ".
>         Unfortunately
>              it creates a minc file which requires one to use HDF5
>         version 1.8 ,
>              so potentially files with such large attributes will not be
>         readable
>              by minc compiled with HDF5 version 1.6 ( minc 2.0, I suppose).
>
>              I made changes and also created a couple of new test cases in
>              HDF5_large_attribute  branch of libminc:
>         https://github.com/BIC-MNI/____libminc/tree/HDF5_large_____attribute
>         <https://github.com/BIC-MNI/__libminc/tree/HDF5_large___attribute>
>
>
>         <https://github.com/BIC-MNI/__libminc/tree/HDF5_large___attribute <https://github.com/BIC-MNI/libminc/tree/HDF5_large_attribute>>
>
>
>              Unless there are some objections, I will merge it into the
>         develop
>              branch of libminc (which is supposed to become libminc release
>              2.3.00 sometime soon).
>


-- 
Best regards,

  Vladimir S. FONOV ~ vladimir.fonov <at> gmail.com