[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20010906: McIDAS AXFORM units question

>From: Scott Gennari <address@hidden>
>Organization: University of Hawaii
>Keywords: 200109070136.f871aZ103355 McIDAS-X AXFORM


>In reference to this my previous inquiry:
> 3.html
>I am uncertain about what's being dumped via AXFORM's unit option RAW
>We're looking for the sensor counts (uncalibrated)
>for each pixel (0-1023 for IR* etc.)

You should be able to get this _if_ the raw values are getting put into
the AREA you are creating from your HDF files.

>AXFORM's documentation describes the unit "RAW" as being
>"number of bytes/element from area directory"

The help for AXFORM is telling us how many bytes will be used in the
output file by default for various UNIT= specifications:

   Defaults for the FORMAT keyword (assume FTYPE=BIN or BOTH):
     if: UNIT=BRIT   then: FORMAT=I1 (1 byte integer)
              TEMP                I2 (2 byte integer)
              RAD/RADN            I4 (4 byte integer)
              ALB                 I2 (2 byte integer)
              REF/RERA            I2 (2 byte integer)
              CNTS                I2 (2 byte integer)
              RAW                  #bytes/element from sarea directory
              other               I1 (1 byte integer)

This says that the number of bytes per pixel in the output file will
match the number of bytes/element of the input file.  If your input
image stores data in two bytes, then the output file of RAW values will
also have RAW values stored using two byte integers.

>Can you help clarify what the unit RAW is in relation
>to sensor counts?

They should be the same.

>Here's the two line sequence being used
>  imgcopy G10/IR5 MYDATA/IMAGES.5 LATLON=19 156 SIZ=512 512

If we take a look at the G10/IR5 image, we would be able to tell if
it has RAW counts or not.

Here is a code sequence that demonstrates what I am driving at:


Image file directory listing for:BLIZZARD/G7-IR-4K
 Pos Satellite/         Date       Time      Center      Res (km)   Image_Size
     sensor                                 Lat  Lon    Lat   Lon
 --- -------------  ------------  --------  ---- ----  ----- ----- ------------
   3  GOES-7 IR     13 MAR 93072  18:01:00    26   87
    Band: 8  11.2 um Night cloud detection, sfc temp    4.34  3.62  1337 x 1604
     proj:    0 created: 1993208 192750  memo: AAA-MSI TO IR16-S   VIA ARCHIVE
     type:AAA      cal type:RAW
     offsets:  data=    1280 navigation=  256 calibration=  768 auxillary=    0
     doc length: 512   cal length: 116   lev length:   4 PREFIX= 636
     valcod: 1104213119 zcor:  1 avg-smp: N
     pdl: 87 87  3  0  0  0 8A 8A  0  0  0  0  0  0  0  0
           0  0  0  0  0  0 10  0  0 73  6 33 59  1 20 2C
     start yyddd: 1993072  start time:180105  start scan:   56
     lcor: 1123  ecor:  7606  bytes per pixel: 2  ss: 33
     Resolution Factors (base=1):   Line=    4.0   Element=    4.0

You can see a couple of things from the listing above:

o the calibration type of the image is RAW
o the data is represented by two bytes; this means that it contains values
  whose range is greater that the 0-255 that a single byte could hold

Now, load and interrogate the image:


IMGPROBE         (selected a point at random)

     Image Name           Day      Nominal Time   Scan Time    Band
  ----------------      -------    ------------   ---------    ----
  BLIZZARD/G7-IR-4K.3 13 Mar 93072   18:01:00      18:02:34      8

                        File     Nominal  Image     RAW     RAD     TEMP    BRIT
       Lat/Lon      Line/Element  Line/Element               *      K
 50:26:19 / 98:54:31   130/  290    1643/ 8766     11200    74.082 271.10    118
 *   milliwatts/meter**2/steradian/(cm-1)

We get back data value interpretations that represent everything that
the image has to offer:  RAW (you can see that the raw value is a
count); RADiance, TEMPerature (the image is represents an IR channel),
and BRITness (brightness is a 1-byte value representation of the RAW

Knowing that my input image is 2-byte tells me that the output data
file for RAW values should also be two byte.  I verified this by
creating a smaller image and then using AXFORM to create the output:


%ls -alt IR1234.001
    113173 -rw-rw-r--   1 ustaff    614400 Sep  7 11:06 IR1234.001

The shape of the image AXFORM is run on is 480x640.  The output file
size is 614400 bytes which is 2 * 480*640, so everything seems

On another topic, you may have gotten some email from Darren Gallant of
UCAR/JOSS regarding conversion of TeraScan-produced HDF imagery to
McIDAS AREA format.  We (JOSS and Unidata) are very interested in being
able to convert TeraScan HDF imagery files into McIDAS AREAs and/or to
serve them directly using ADDE.  The stumbling block for this effort
has been understanding what data values the HDF and associated ASCII
files are providing, and how those values relate to a correct
navigation for various types of imagery.  I have recently had occasion
to download GMS imagery converted from HDF to AREA from the Marshall
Space Flight Center (MSFC) FTP site.  I found that the GMS imagery do
not contain valid navigation: they are using the navigation model from
GOES-7, and the registration of the navigation to the image is

Are you or have you been involved in the development of the software
that converts the HDF images into AREAs?  If so, would it be possible
to get the code from you so I can take a look?  If yes, is there any
documentation on what the TeraScan "navigation" parameters mean?

If you were not involved in the development of the software, can you
point me to the appropriate person to talk to?  I know that the JOSS
folks have already been in touch with Anthony Guillory (I know Anthony)
and have gotten some code from him, but do not have any documentation
on what the TeraScan HDF and ancillary ASCII file values mean.

Any light you can shed on the above would be _most_ appreciated.



>From address@hidden Wed Sep 26 15:38:35 2001
>Subject: Re: 20010921: McIDAS AXFORM units question (cont.)

Hi Tom,

> I much prefer FTP.  I can either FTP it from you, or you can upload it
> to our passworded McIDAS FTP account as follows:
> machine: ftp.unidata.ucar.edu
> user: xxxxx
> pass: xxxxx
> directory: incoming/source

Sorry for the delay.

I've uploaded a tarball to incoming/src/gvar.tar.Z

The code as it stands now uses an older HDF library
(3.3r3) but should be easily upgradable to 4.x and
has been compiled using Sun compilers, gcc should be

You'll need to edit targets.h to point to where the
raw gvar data files are located. It currently expects
to process files with the name format YYMMDDhhmm (i.e. 0109262132)
If you want, I can send a small gvar chunk (~20MB) to that ftp directory
to get you started.

I'll be glad to answer questions as they crop up as you dig into
this further.


Scott Gennari - HI Institute of |voice (808) 956 5392
Geophysics and Planetology      |pager (808) 288 6918
University of Hawaii            |fax   (808) 956 9399
POST 619E, 2525 Correa Road     |
Honolulu, HI 96822 USA          |email address@hidden

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.