home *** CD-ROM | disk | FTP | other *** search
/ Photo CD Demo 1 / Demo.bin / hdf / newsltr / nwslttr1 next >
Text File  |  1980-02-06  |  16KB  |  384 lines
  1.  
  2.                          NCSA HDF Newsletter #1
  3.                            December 12, 1989    
  4.  
  5. Contents:
  6.     The HDF Newsletter
  7.     The Current State of HDF
  8.     HDF Release 3.0
  9.     The HDF Vgroup: A More General HDF Structure
  10.     HDF File Conversion 
  11.     The NCSA HDF Staff
  12.  
  13.  
  14.       --------------------------- ** ---------------------------
  15.  
  16.                           The HDF Newsletter
  17.  
  18. As HDF has begun to spread beyond NCSA many of you have requested 
  19. some form of regular communication among all HDF users.  The HDF 
  20. Newsletter is an occasional newsletter designed to provide that 
  21. communication.  It is meant to serve as a clearinghouse of 
  22. information about HDF.
  23.  
  24. The contents of this issue reflect the kinds of things I expect to 
  25. include in the Newsletter, but I am quite open to suggestions.  I 
  26. will print anything about HDF that seems as though it might be of 
  27. interest to the HDF community.
  28.  
  29. We will distribute the Newsletter via both surface mail and email.  
  30. If we have your email address, we will use email.  It is cheaper 
  31. and (we hope) easier to manage than surface mail.
  32.  
  33. Mike Folk
  34. NCSA
  35. University of Illinois
  36. 605 E. Springfield Ave.
  37. Champaign, IL 61820
  38. 217-244-0647
  39. mfolk@ncsa.uiuc.edu (internet)
  40. 12409@ncsavmsa
  41.  
  42.     --------------------------- ** ---------------------------
  43.  
  44.                     The current state of HDF
  45.  
  46. FUNCTIONALITY
  47. HDF Release 2.0, released last February and since then revised 
  48. only for bug fixes, is still the most up-to-date official version 
  49. of HDF.  It includes interfaces and file formats for handling 8-
  50. bit raster images (with or withoout palettes), and regular gridded 
  51. multidimensional floating point data sets.  It includes utilities 
  52. for listing the contents of an HDF file (hdfls), for converting 
  53. raw raster data to HDF (r8tohdf) and vice versa (hdftor8), and for 
  54. displaying images or sequences of images from HDF files (hdfseq 
  55. and hdfrseq).
  56.  
  57. NCSA WORKSTATION TOOLS
  58. Most of the workstation tools now support HDF files.  This 
  59. includes CompositeTool on the Sun, which previously did not 
  60. support HDF.  (By the end of the year ImageTool (also Sun) will 
  61. also support HDF files.)  The Mac tools are NCSA Image, NCSA 
  62. PalEdit, NCSA DataScope, and NCSA Layout.  NCSA CompositeTool is a 
  63. Sun version of Layout.  Our two X-Windows tools are NCSA X-Image, 
  64. and NCSA X-DataSlice.
  65.  
  66. OFFICIAL PLATFORMS
  67. Architectures that we have HDF running on: Cray-2 and Cray X-MP; 
  68. Alliant (Concentrix), SGI 4, Sun-3, and Sun Sparc machines, 
  69. Macintosh and IBM-PC.  And VMS, sort of (see below).
  70.  
  71. UNOFFICIAL PLATFORMS
  72. People outside of NCSA have ported HDF to: Convex, Stellar, 
  73. Connection Machine, Symbolics Machine, and Amiga.  (Do you know of 
  74. any others?)  I think most of these people would be happy to give 
  75. you advice on any special thing you need to do if you want to port 
  76. HDF to one of these machines, but I probably shouldn't publish 
  77. their names without their permission.  Let me know if you are 
  78. interested in any particular port, and I will give your name to 
  79. the relevant person.
  80.  
  81. SEMI-OFFICIAL PLATFORMS -- VMS & CTSS
  82. VMS. A lot of you have asked for HDF support on VMS systems, so we 
  83. made a quick attempt to port HDF to VMS last spring.  It was 
  84. problematic from the beginning because we don't have any real VMS 
  85. expertise here.  It actually went reasonably well in most 
  86. respects, except for one major problem, which we're still 
  87. struggling with: VMS-C writes files "stream-LF" format, which does 
  88. not transfer well via ftp and some other transfer programs.  There 
  89. is a VMS utility called FIXATR that we supply with VMS HDF, which 
  90. converts stream-LF files to "fixed-512" files, which seems to be 
  91. more amenable to transfer outside of the VMS environment.  This is 
  92. not a great solution, since it involves an extra step whenever 
  93. files go to or from VMS, but it may at least make it possible.  
  94. Any suggestions for better solutions are certainly welcome.
  95.  
  96. CTSS. CTSS is a different story.  Not only don't we have CTSS/HDF 
  97. expertise at NCSA; we also don't have access to CTSS any more.  If 
  98. you are having problems getting HDF to work on CTSS, we will be 
  99. happy to try to help you, but frankly we haven't been very 
  100. successful diagnosing such problems recently.  If we can't help 
  101. you, we may be able to put you in touch with someone who has 
  102. successfully implemented HDF on CTSS.
  103.  
  104.  
  105.      --------------------------- ** ---------------------------
  106.  
  107.  
  108.                           HDF Release 3.0
  109.  
  110. After many delays, HDF 3.0 seems now to be ready for release. All 
  111. of the features of HDF 2.0 are present in HDF 3.0, plus several 
  112. new features.  
  113.  
  114. HDF 3.0 has been in available as a beta release for about 5 
  115. months, and it seems pretty bug free.  But certain parts of it 
  116. have hardly been used by anyone, so please let us know if 
  117. something doesn't seem to work the way you think it should.
  118.  
  119. New features of HDF 3.0 include the following:
  120.  
  121. An interface for basic i/o of 24-bit raster images, which includes 
  122. the following routines:
  123.  
  124.   DF24setil:   sets the interlace to be used when writing out the 
  125.                RIS24 for the image.
  126.  
  127.   DF24addimage:appends a 24-bit raster image set to the file.
  128.  
  129.   DF24getdims: retrieves the dimensions and interlace of the
  130.                image.
  131.  
  132.   DF24getimage: retrieves the image and stores it in an array.
  133.  
  134.   DF24reqil:   specifies an interlace to be used in place of the
  135.                interlace indicated in the file when the next 
  136.                raster image is read.
  137.  
  138.  
  139. An interface for annotating HDF data objects and files, which 
  140. includes the following routines:
  141.  
  142.   DFANgetlablen: gets length of label of a tag/ref
  143.   
  144.   DFANgetlabel:  gets label of tag/ref
  145.  
  146.   DFANgetdesclen: gets length of description of tag/ref
  147.  
  148.   DFANgetdesc:   gets description of tag/ref
  149.  
  150.   DFANputlabel:  puts label of tag/ref
  151.  
  152.   DFANputdesc:   puts description of tag/ref
  153.  
  154.   DFANlastref:   returns ref of last annotation read or written
  155.  
  156.   DFANlablist:   gets list of labels for a particular tag
  157.  
  158.  
  159. An interface for input and output of 8-bit palettes, including the 
  160. following routines:
  161.  
  162.   DFPaddpal:    appends a palette to a file.
  163.  
  164.   DFPgetpal:    reads in the next palette in the file.
  165.  
  166.   DFPputpal:    writes a palette to a file.
  167.  
  168.   DFPnpals:     indicates number of palettes in a file.
  169.  
  170.   DFPwriteref:  sets the reference number of the next palette to
  171.                 be written.
  172.  
  173.   DFPreadref:   gets the reference number of the next palette to
  174.                 be retrieved.
  175.  
  176.   DFPrestart:   specifies that the next call to DFPgetpal reads
  177.                 first palette in the file, rather than the next.
  178.  
  179.   DFPlastref:   returns value of the reference number most
  180.                 recently read or written.
  181.  
  182.  
  183. Scientific data set routines for storing and retreiving subsets 
  184. (slices) of scientific data, and for choosing optional storage 
  185. formats and data types:
  186.  
  187.   DFSDstartslice: prepares to write part of dataset to file.
  188.  
  189.   DFSDputslice:   writes part of a dataset to a file.
  190.  
  191.   DFSDendslice:   indicates write completion for part of dataset.
  192.  
  193.   DFSDgetslice:   reads part of a dataset.
  194.  
  195.   DFSDsettype:    specifies data attributes: data type and 
  196.                   representation, system type, and array order.
  197.  
  198.  
  199. * new utilities, including the following:
  200.  
  201.   hdfed:    lets you browse in an HDF file and manipulate some of
  202.             the data
  203.  
  204.   fptohdf:  converts floating point data to HDF floating point 
  205.             data and/or 8-bit raster images
  206.  
  207.   r24tohdf: converts a raw RGB 24-bit image to an 8-bit RIS8 with 
  208.             a palette
  209.  
  210.   paltohdf: converts a raw palette to hdf format
  211.  
  212.   hdftopal: converts palette in an hdf file to raw format
  213.  
  214.     --------------------------- ** ---------------------------
  215.  
  216.  
  217.               HDF Vgroup--A More General Structure
  218.  
  219. HDF currently supports only two major types of scientific data: 
  220. raster data and regular gridded multidimensional arrays.  Recently 
  221. we have added an HDF structure that promises to expand 
  222. significantly the types of data that we can support.  This 
  223. structure, currently called Vgroup (the name may change), provides 
  224. two important new structures:
  225.  
  226.     1. a general grouping structure that lets the user form
  227.        groups out of any set of HDF objects, including other
  228.        Vgroups
  229.  
  230.     2. a general structure made up of a set of record-like
  231.        structures, each record being made up of a set of
  232.        fields.  Fields can be use-defined or predefined.
  233.  
  234. Vgroups look very promising for a number of important scientific 
  235. application areas not currently supported by HDF, including finite 
  236. element and non-rectilinear mesh data.  We have talked with a 
  237. number of scientists who work with this kind of data, and our 
  238. general impression is that there is a need for a standard in this 
  239. area and that Vgroups could well provide the standard.
  240.  
  241. The idea for Vgroup springs from a need to store 3-D polygonal 
  242. data, with vertices, polygons (connectivity lists), and various 
  243. associated values with each vertex or polygon. 
  244.  
  245. When Jason Ng took over the Vgroup project, he began talking to a 
  246. lot of potential users from many different disciplines about how 
  247. they might be able to use Vroups.  Their responses were so varied, 
  248. that Jason immediately began looking for ways to generalize the 
  249. concept so that it could handle many different kinds of data. The 
  250. result is a very general HDF structure that "groups" one or more 
  251. other HDF structures.  The structures in a Vgroup can be anything 
  252. you want them to be including other Vgroups.  
  253.  
  254. For example, a Raster Image Set could probably be stored as a 
  255. Vgroup.  The members of the Vgroup would be a palette, a dimension 
  256. record, and an image.  But with the Vgoup concept we could now go 
  257. a step further and group several Raster Image Sets, in an 
  258. animation, for example.
  259.  
  260. While the Vgroup idea provides a general structure for linking HDF 
  261. items together, we still need a structure for representing things 
  262. like sets of vertices and connectivity lists.  The structure that 
  263. we use for this is a very familiar one--a field and record 
  264. structure.  Store 3-D vertices, we define three fields per 
  265. element, corresponding to the x, y and z coordinates that define 
  266. each vertex.  A vertex set is a fixed number of vertex records.  A 
  267. polygon set is similarly defined.  If there are four vertices per 
  268. polygon, each record consists of four vertex numbers; these 
  269. numbers appear an order that describes the connectivity of the 
  270. polygon.
  271.  
  272. In keeping with our desire to standardize those items that are 
  273. likely to be accessed by different programs in different 
  274. environments, certain types of sets will be predefined.  A 3-D 
  275. vertex set will have exactly three fields per vertex, for 
  276. instance.  But those who have the need are free to define their 
  277. own dataset types.  For example, you might for some reason want to 
  278. store scalar values in the same dataset that you store your 
  279. vertices.  You are free to do this, but must recognize that you 
  280. are building a non-standard dataset.  (Unless, of course, enough 
  281. users ask us to make THAT one of the standard types.)
  282.  
  283. There are still some issues yet to be settled with respect to 
  284. Vgroups, but we think that we are pretty close to having the major 
  285. design of it pinned down.  The interface is now undergoing a major 
  286. overhaul.  We expect to release a Beta version of it in mid-
  287. January for any of you who would like to look at it and play with 
  288. it.
  289.  
  290. Of course we welcome all comments and questions you have about 
  291. Vgroups.  We don't want to freeze this structure too soon, because 
  292. we see it as an important building block to HDF in the future.  On 
  293. the other hand, we want to get it into use as soon as is 
  294. reasonably possible.  If don't want to wait for the Beta release, 
  295. contact us and we will send you the draft of the documentation.
  296.  
  297.      --------------------------- ** ---------------------------
  298.  
  299.  
  300.                         HDF File Conversions
  301.  
  302. A frequent question that arises is "How can I translate between 
  303. file format xxx and HDF?"  We want very much to support 
  304. translators between HDF and other formats, but have so far had 
  305. trouble finding the resources to write them.  Here is a list of 
  306. some of the translators that we would like to have.  If you have a 
  307. translator, know of one, are interested in working on one, etc., 
  308. please let us know.  
  309.  
  310.  
  311. FITS--Flexible Image Transport System
  312. FITS is the standard format used for astronomical images and other 
  313. digital arrays.  We have small collaborative project with the 
  314. Space TelescopeScience Institute to translate basic FITS to HDF.  
  315. We hope this will lead to a more elaborate project later.
  316.  
  317. CGM--Computer Graphics Metafile 
  318. CGM is a very widespread file format that is used primarily for 
  319. describing pictures.  Though CGM and HDF have different roles to 
  320. play in scientific visualization, it would be nice to be able to 
  321. look at CGM pictures using HDF-based tools, and vice versa.  Some 
  322. programs that might help us do this: a CGM cell array-to-HDF 
  323. converter, a rasterizer that converts CGM 2-D pictures to HDF 
  324. raster, and a converter  that converts CGM text to HDF.  (HDF 
  325. currently does not support text.)
  326.  
  327. (We have heard about a tool called CGM-Maker developed at Los 
  328. Alamos that converts between CGM and Pict files, among others.  
  329. Since NCSA Layout reads and writes both Pict and HDF files, CGM-
  330. Maker and Layout together provide a kind of primitive filter 
  331. between the two formats.)
  332.  
  333. netCDF
  334. The netCDF interface allows users to share scientific data in a 
  335. form that is self-describing and network transparent, and is very 
  336. much in the spirit of HDF.  It is a well-designed, flexible 
  337. interface, and one that would benefit HDF users enormously if it 
  338. could be incorporated into the HDF library.  We are very 
  339. interested in adapting HDF to support the netCDF interface, and 
  340. also in writing translators that convert between the HDF and 
  341. netCDF file formats.
  342.  
  343. TIFF--Tag Image File Format
  344. Several HDF users have requested translators to and from this 
  345. common image format and HDF.
  346.  
  347.      --------------------------- ** ---------------------------
  348.  
  349.                             The HDF Staff
  350.  
  351. In the last year and a half, the HDF project has expanded from one 
  352. programmer to six people.  We lost Swami Natarajan, who finished 
  353. his Ph.D last summer and took a job a Texas A & M.  We really miss 
  354. him and continue to appreciate the work he did for us. Fortunately 
  355. he is still in touch via email.
  356.  
  357. Mike Folk is the project manager for HDF.  Mike joined NCSA in 
  358. August, 1988, having last worked at Oklahoma State University as a 
  359. professor in the computer science department.
  360.  
  361. ChinChau Low has taken over Swami's responsibilities for 
  362. maintaining HDF.  ChinChau is a graduate student in Computer 
  363. Science at the University of Illinois.   ChinChau joined us in 
  364. Fall, 1988, and has worked on virtually all aspects of HDF. He is 
  365. crucial to maintaining HDF and also to all additions.
  366.  
  367. Jason Likkai Ng is a full-time staff member from Malaysia (via 
  368. Cornell, Milwaukee, and La Jolla) who joined us in May.  Jason's 
  369. main responsibility is the Vgroup project described earlier.
  370.  
  371. Peter Webb, Brian Calvert and Drew Hess joined the HDF group this 
  372. fall semester.  Peter last worked at Schlumberger; Brian joins us 
  373. from Motorola.  Peter and Brian are graduate students in Computer 
  374. Science; Drew is an undergraduate in Computer Science.  
  375.  
  376. Peter's current projects include (1) installation of a revision 
  377. control system to help manage HDF code development, and (2) 
  378. finding ways to speed up HDF's performance.  Brian's project is 
  379. Polyview, an SGI-based interactive tool for displaying polygonal 
  380. data stored in the Vgroup format described above.  Drew is 
  381. currently working on an HDF utility for taking slices out of 3-D 
  382. scientific datasets.
  383.  
  384.