>From: Scott Gennari <address@hidden> >Organization: University of Hawaii >Keywords: 200109070136.f871aZ103355 McIDAS-X AXFORM Scott, >In reference to this my previous inquiry: > >http://www.unidata.ucar.edu/projects/coohl/mhonarc/MailArchives/mcidas/msg0328 > 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 > axform 5 IR5FILE NAV=YES UNIT=RAW 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: DATALOC ADD BLIZZARD adde.ucar.edu DSINFO I BLIZZARD IMGLIST BLIZZARD/G7-IR-4K FORM=EXP 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 IMGLIST: done 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: IMGDISP BLIZZARD/G7-IR-4K MAG=-2 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) IMGPROBE: Done 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 value). 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: IMGCOPY BLIZZARD/G7-IR-4K MYDATA/IMAGES.1234 LAT=32 82 SIZE=480 640 MAG=-2 IMGDISP MYDATA/IMAGES.1234 AXFORM 1234 IR1234 NAV=YES UNIT=RAW %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 consistent. 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 time-dependent. 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. Cheers... Tom >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 doable. 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. Thanks, Scott __________________________________________________________ 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.