[Nexus] Reading generic h5 files.

[Mark Koennecke]

Hi,

Peterson, Peter F. schrieb:
> Brian,
>
> Not to push one direction or the other, but I've done something similar
> with xml-based NeXus and java (don't ask why). In that case the code I
> generated mimicked a particular version of the NeXus api with a
> particular version of mxml, including the file attributes. Since the
> files are intended to be uninteresting as far as napi features go, this
> worked well. The key to it all was to go through my own abstraction
> layer of the file I/O which is on top of the normal java xml libraries.
> I confirmed it all worked by pushing the resulting files through some of
> the standard NeXus tools.
>
> P^2
>
> -----Original Message-----
> From: nexus-bounces at nexusformat.org
> [mailto:nexus-bounces at nexusformat.org] On Behalf Of tieman
> Sent: Wednesday, February 21, 2007 2:58 PM
> To: Ray Osborn
> Cc: nexus at nexusformat.org
> Subject: Re: [Nexus] Reading generic h5 files.
>
> Freddie, Ray,
>
> I figured the issue was something like this.  For HDF4, I do create a 
> "type"--if it's a group that is defined in Nexus, I try and use the NX* 
> type (we don't have many of these), for the rest, I make something up 
> that would make sense to someone who might read it.  When reading the 
> data back in, for the most part, I just pass the type along (the actual 
> value is quarried from the file) with the name and everyone seams to be 
> happy.
>
> For HDF5, the missing NX_class attribute signals errors which ultimately
>
> cause my code to fail.  I agree that modifying the NAPI to be more 
> forgiving may cause problems elsewhere and maybe we can fix this in the 
> Matlab code.  Is it really as simple as adding an "NX_class" attribute 
> to all groups?  I did an h5dump on a file written by NAPI and I do not 
> see a "NX_class" attribute in the top level group "/" but I do see it in
>
> all the other groups.  Do I need to have a "Nexus_version" attribute in 
> "/"?  Do any of the fields have special attributes that are needed?
>
> Matlab bindings may or may not be of use to us.  As you probably well 
> know, we only pretend to write Nexus files at the APS ;)  I've thought 
> many times about dropping the pretense and modifying my NAPI wrapper 
> code to call HDF directly to avoid this confusion, but I've got a lot of
>
> code that relies on NAPI to read/write HDF files.  Nexus as an API has 
> served me very well over the years!  If we can get Matlab to fake what 
> NAPI needs, we can continue to get by for now...at least until someone 
> with more clout than I snaps their fingers and declares the APS WILL use
>
> Nexus as a file format...
>
> Thanks!
>
> Brian
>
>
> Ray Osborn wrote:
>   
>> On 2007/02/21 11:53, "Akeroyd, FA (Freddie)" <F.A.Akeroyd at rl.ac.uk>
>>     
> wrote:
>   
>>   
>>     
>>> Brian,
>>>
>>> In HDF4 objects had the concept of a "class" and this could be used
>>>       
> by
>   
>>> the NeXus API to store the data type; a separate group attributes was
>>> not needed. In HDF5 I believe there was no such built in facility and
>>>       
> so
>   
>>> an "NX_class" group attribute had to be created and used instead.
>>>     
>>>       
>> Brian,
>> The original idea with the NeXus API was that it would only be used to
>>     
> read
>   
>> and write NeXus-standard-conforming files, which required that each
>>     
> group
>   
>> had a name and a class associated with it.  The class needed to have
>>     
> the
>   
>> prefix "NX", so NAPI was only set up to read such groups.  The rest
>>     
> would be
>   
>> ignored - they could be there, but the NAPI did not know how to handle
>>     
> them.
>   
>> HDF4 had a class automatically associated with each group, which was
>> simulated in HDF5 by adding an NX_class attribute.
>>
>> I guess the API could be rewritten to be a bit more forgiving when
>>     
Ray described the situation correctly: HDF-4 groups have a class by 
default, in HDF-5  we had to simulate this with the NX_class attribute.
But even HDF-4 complains on NXopengroup if the class does not match.  
One could  consider to make the API more lenient about this, for
instance by not checking the group in NXopengroup when the nxclass 
parameter is NULL. This would work for HDF-4 and HDF-5 but causes
a problem with XML as in the XML-format the class name is the node name.

On the other hand I think (no guarantees though) it suffices to add a 
NX_class attribute to all groups except / in those non standard HDF-5 
files. The
file attributes are only written by the API when a new file is opened 
but never checked after that.

Let me know what we shall do....

            Best Regards,

                Mark