| Re: HDF data types on UNIX and windows [message #22200] |
Wed, 25 October 2000 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
H C Pumphrey (hcp@newsread.ed.ac.uk) writes:
> It may or may not, but will RSI [implement HDF5, that is] ?
I'm not privy to RSI's plans, but I do feel comfortable
stating that any company that cares about imaging had
better be staying abreast of what their customer's are
using in the HDF world. The folks using HDF are RSI's
bread and butter constituency. I'm sure RSI is paying
attention. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: HDF data types on UNIX and windows [message #22201 is a reply to message #22200] |
Wed, 25 October 2000 00:00  |
hcp
Messages: 41
Registered: August 1995
|
Member |
|
|
In article <MPG.1460aa00306af952989c60@news.frii.com>, davidf@dfanning.com (David Fanning) writes:
|> H C Pumphrey (hcp@newsread.ed.ac.uk) writes:
|> > I have tried a few HDF viewers and readers and found that most are flaky.
|> > They tend to support the subset of HDF files that the writer uses them on,
|> > and fail on others.
|>
|> I offer an alternative hypothesis: the HDF documentation
|> as it comes with the HDF libraries is atrocious.
It certainly is! The documentation they provide for the structure of a
HDF file is for version 3.2 while the library itself is up to 4.1r3,
which is quite different.
I have the following news direct from NCSA:
<quote>
The 3.2 version is all that we provide right now. However, I am in
the process of releasing HDF 4.1r4. We have a fairly complete, draft
version of the new specification manual that will be available with
HDF 4.1r4.
The 4.1r4 release should be completed at the end of this week (if all
goes well).
</quote>
.... so the situation is likely to change soon. Whether it changes for the
_better_ is anyone's guess.
|> Readers are good for data the writer uses because the
|> writer has spent hour upon hour figuring out what works
|> empirically, not with what works according to the lousy
|> documentation.
Again, agreed. I don't think you have presented an alternative hypothesis,
you have presented an (IMHO entirely correct!) hypothesis to explain
my statement.
[I continued]
|> > HDF is too big and
|> > complex. I get the impression that HDF5 is intended to cut exactly
|> > this Gordian[1] knot.
[and DF replied]
|> Heaven help us. :-(
It may or may not, but will RSI [implement HDF5, that is] ?
Hugh
--
============================================================ ==============
Hugh C. Pumphrey | Telephone 0131-650-6026
Department of Meteorology | FAX 0131-650-5780
The University of Edinburgh | Replace 0131 with +44-131 if outside U.K.
EDINBURGH EH9 3JZ, Scotland | Email hcp@met.ed.ac.uk
OBDisclaimer: The views expressed herein are mine, not those of UofE.
============================================================ ==============
|
|
|
|
| Re: HDF data types on UNIX and windows [message #22203 is a reply to message #22200] |
Wed, 25 October 2000 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
H C Pumphrey (hcp@newsread.ed.ac.uk) writes:
> And that therefore tallies with the message you got from IDL. Maybe
> only a small fraction of HDF files have this data type in and support for
> it is therefore unreliable in many packages.
>
> I have tried a few HDF viewers and readers and found that most are flaky.
> They tend to support the subset of HDF files that the writer uses them on,
> and fail on others. (I had assumed that IDL's HDF support was better than
> this, maybe I was not quite right in that assumtion.)
I offer an alternative hypothesis: the HDF documentation
as it comes with the HDF libraries is atrocious.
Readers are good for data the writer uses because the
writer has spent hour upon hour figuring out what works
empirically, not with what works according to the lousy
documentation. And when you find a discrepancy, what do
you do? Implement a work-around? Assume the documentation
is wrong? Suggest it is the library writer's fault?
Packages like IDL have to be just slightly behind the
leading edge simply to have enough people testing the
implementation to make *some* kind of implementation
possible. The surprise to me is that HDF readers are
as good as they are!
> This in turn suggests to me that HDF is too big and
> complex. I get the impression that HDF5 is intended to cut exactly
> this Gordian[1] knot.
Heaven help us. :-(
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: HDF data types on UNIX and windows [message #22204 is a reply to message #22200] |
Wed, 25 October 2000 00:00 |
hcp
Messages: 41
Registered: August 1995
|
Member |
|
|
Hmmm. It's HDF day in this group, clearly......
In article <8t6s4p$13n$1@naxos.belnet.be>, "Henk" <deckard_007@deja.com> writes:
|> I have this HDF file with vgroups and vdata. I can open and view the
|> contents via scispy (although it crashes a lot!), but not via IDL. I first
|> used my own program (didn't work) and afterwards the HDF_BROWSER. They both
|> complain about 'Unsupported or unknown HDF data type (16389)'. I'm using
|> IDL5.3 on HP-UX 10.20 .
The HDF User manual says
HDF Data Type | HDF Data type flag and value | Description
float32 | DFNT_LFLOAT32 (16389) | 32-bit little-endian float
So it is not unknown, it is unsupported.
|> Also the java hdf-viewer from ncsa does not work.
|> Has anyone encountered this kind of problem ? Any tips ? Scispy says the
|> datatype is 'Little Endian 32-bit floating point type'.
And that therefore tallies with the message you got from IDL. Maybe
only a small fraction of HDF files have this data type in and support for
it is therefore unreliable in many packages.
I have tried a few HDF viewers and readers and found that most are flaky.
They tend to support the subset of HDF files that the writer uses them on,
and fail on others. (I had assumed that IDL's HDF support was better than
this, maybe I was not quite right in that assumtion.)
This in turn suggests to me that HDF is too big and
complex. I get the impression that HDF5 is intended to cut exactly
this Gordian[1] knot.
Hugh
[1] I have proably spelt that wrong, but you know what I mean.
Alexander the Great, blah, blah
--
============================================================ ==============
Hugh C. Pumphrey | Telephone 0131-650-6026
Department of Meteorology | FAX 0131-650-5780
The University of Edinburgh | Replace 0131 with +44-131 if outside U.K.
EDINBURGH EH9 3JZ, Scotland | Email hcp@met.ed.ac.uk
OBDisclaimer: The views expressed herein are mine, not those of UofE.
============================================================ ==============
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
