Binary Dumper -- Unsupported

The binary dumper is a program that dumps HDF-EOS2 objects in binary format. The current version is 1.1.

Installing the Binary Dumper under Linux

Since this program does not provide configure script or Makefile, users need to build this program manually. Here is a simple Makefile.

Figure 1 Makefile for the binary dumper

CC=<HDF4_PATH>/bin/h4cc

HDFEOS2_DIR=<HDFEOS2_PATH>

CFLAGS=-I$(HDFEOS2_DIR)/include

LDFLAGS=-L$(HDFEOS2_DIR)/lib

LIBS=-lhdfeos -lGctp

bindmp: bindmp.c bindmp.h

$(CC) $(CFLAGS) $(LDFLAGS) $(LIBS) bindmp.c -o bindmp

Note h4cc, a utility that is used to compile an HDF4 external

C program and part of the HDF4 binary distribution, needs to be specified as CC because the HDF-EOS2 library calls the HDF4 library.

Dumping a data field in a swath object

This program can dump one field or multiple data fields in one swath object. To show the illustration, let's dump one data field 23.8H_Approx._Res.3_TB_(not-resampled) of a swath object called Low_Res_Swath in an HDF-EOS2 file AMSR_E_L2A_BrightnessTemperatures_V09_200206190029_D.hdf. The data field is 1997-by-243 array, and its type is 16-bit integer.

In the shell, one can issue the following command:

Figure 2 Dumping a data field in a swath object

$ ./bindmp \
 -f "23.8H_Approx._Res.3_TB_(not-resampled)" \
 Low_Res_Swath \
 AMSR_E_L2A_BrightnessTemperatures_V09_200206190029_D.hdf \
 output

The -f option specifies the field that this program dumps. If this is omitted, all fields are dumped. The first argument, 23.8H_Approx._Res.3_TB_(not-resampled) specifies the field name to be dumped in this swath; the second argument, Low_Res_Swath, specifies the name of the swath, and the third argument specifies the name of the HDF-EOS2 file. The last argument, output, specifies the name of the file that stores the binary output this program generates.

The output of this program consists of three parts: the rank, the dimension sizes and elements. First, take a look at the textual representation of part of what this program dumps.

Figure 3 A result of the binary dumper

00000000 | 02 00 00 00 cd 07 00 00 f3 00 00 00 00 80 00 80

00000016 | 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80

00000032 | 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80
 ...

00970512 | 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80

00970528 | 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80

00970544 | 00 80 00 80 00 80 00 80

For each line, the left-most digits show the offset of bytes in decimal from the beginning of the file, and the rest of the line shows 16 bytes of contents in hexadecimal.

The first 32-bit integer represents the rank of the data field as 02 00 00 00 shows. The next two 32-bit integers represent the number of elements for each dimension. There would be less or more integers according to the rank. The data field we use is 1997-by-243. 1997 and 243 correspond to cd 07 00 00 and f3 00 00 00. Note that the system we used is little-endian; so, the left-most byte is the least significant byte in our machine.

After three 32-bit integers, actual data follow. Since the data field 23.8H_Approx._Res.3_TB_(not-resampled) is of 16-bit integer, one element accounts for two bytes. The first element corresponds to 00 80, which is interpreted as -32768.

We noticed that the output of this program has only 485,270 elements. This number is not consistent with 485,271, the actual number of elements in the data field. The binary dumper seems to ignore the last n modulo 10 elements when there are n elements.

Last modified: 11/11/2020