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

[McIDAS #QQA-176689]: using IMGPROBE to retrieve cloud top temps from SATEPS composite



Hi Robert,

re:
>Through our access to the non-public SATEPS servers, I am using their 8km res
>northwstern hemisphere composite.  I am unable to use IMGPROBE to obtain cloud
>top temp info.  IMGPROBE just results in raw/brit/prod values. In the past I
>was making my own composites using topo files as a "template".  I had to do
>LWU POKE AREA1234 0 56 to enable me to retrieve an estimate of cloud top temps.
>However this does not work on this image.  I still can't retrieve temp info.
>Here is an output of LWU list for the image I copied to my server:
> 
>  0.          0           4 HEX:        0        4 ASCII:
>  2.         74      106075 HEX:       4A    19E5B ASCII: J    [
>  4.     150000        -300 HEX:    249F0 FFFFFED4 ASCII:  I
>  6.       8885           0 HEX:     22B5        0 ASCII:  "
>  8.       1688        2232 HEX:      698      8B8 ASCII:
> 10.          1           1 HEX:        1        1 ASCII:
> 12.          1           1 HEX:        1        1 ASCII:
> 14.          0           0 HEX:        0        0 ASCII:
> 16.     106075      154636 HEX:    19E5B    25C0C ASCII: [     \
> 18.          8           0 HEX:        8        0 ASCII:
> 20.          0           0 HEX:        0        0 ASCII:
> 22.          0           0 HEX:        0        0 ASCII:
> 24. 1193301074     5390678 HEX: 47205452   524156 ASCII: RT G VAR
> 26.          0           0 HEX:        0        0 ASCII:
> 28.          0           0 HEX:        0        0 ASCII:
> 30.          0           0 HEX:        0        0 ASCII:
> 32.          1        1280 HEX:        1      500 ASCII:
> 34.        256           0 HEX:      100        0 ASCII:
> 36.          0           0 HEX:        0        0 ASCII:
> 38.          0           0 HEX:        0        0 ASCII:
> 40.          0           0 HEX:        0        0 ASCII:
> 42.          0           0 HEX:        0        0 ASCII:
> 44.          0      106075 HEX:        0    19E5B ASCII:      [
> 48.          0           0 HEX:        0        0 ASCII:
> 50.          0   541348432 HEX:        0 20445250 ASCII:      PRD
> 52. 1414091330           2 HEX: 54495242        2 ASCII: BRIT
> 54.          0           0 HEX:        0        0 ASCII:
> 56.  541348432   538976288 HEX: 20445250 20202020 ASCII: PRD
> 58.          1           0 HEX:        1        0 ASCII:
> 60.          0           0 HEX:        0        0 ASCII:
> 62.        768          13 HEX:      300        D ASCII:
> 64.  538989392           1 HEX: 20205350        1 ASCII: PS
> 66.      10000      600000 HEX:     2710    927C0 ASCII:  '    '
> 68.       8000      450000 HEX:     1F40    6DDD0 ASCII: @
> 70.    6378388       81992 HEX:   615394    14048 ASCII:  Sa  H@
> 72.          0           0 HEX:        0        0 ASCII:
> 74.     900000           0 HEX:    DBBA0        0 ASCII:
> 76.          0           0 HEX:        0        0 ASCII:
> 78.          0           0 HEX:        0        0 ASCII:
> 80.          0           0 HEX:        0        0 ASCII:
> 82.          0           0 HEX:        0        0 ASCII:
> 84.          0           0 HEX:        0        0 ASCII:
> 86.          0           0 HEX:        0        0 ASCII:
> 88.          0           0 HEX:        0        0 ASCII:
> 90.          0           0 HEX:        0        0 ASCII:

Note that the calibration type of this image is PRD:

> 50.          0   541348432 HEX:        0 20445250 ASCII:      PRD
> 52. 1414091330           2 HEX: 54495242        2 ASCII: BRIT
> 54.          0           0 HEX:        0        0 ASCII:
> 56.  541348432   538976288 HEX: 20445250 20202020 ASCII: PRD
> 58.          1           0 HEX:

At this point, it would be helpful to know what their PRD calibration block
looks like.  Here is the short comment about calibrations from the AREA
information file, area.doc:

     If necessary, the next block of bytes may contain a CAL entry. This
     entry is present if the data must be calibrated before it can be
     displayed.  Like the Area Directory and NAV blocks, each value in a CAL
     block is a 4-byte quantity.  If present, word 63 of the Area Directory
     entry is a byte offset to the CAL block's position within the file.  If
     word 63 is zero, the CAL block is not contained in the file.

Your listing shows that word 63 is 768 (the documentation references 1-based
words, LWU lists are 0-based), so you should do the following:

LWU LIST AREA1234 192 224

The listing should tell you how the image is calibrated.  It could be that
the image creators did not include a calibration that includes mapping
of brightness to temperature.

> and output of imglist:
> Image file directory listing for:MYDATA/IMAGES
> Pos Satellite/         Date       Time      Center      Res (km)   Image_Size
> sensor                                 Lat  Lon    Lat   Lon
> --- -------------  ------------  --------  ---- ----  ----- ----- ------------
> 1  G-10 IMG      16 MAR 06075  15:00:00    50   45
> Band: 4    No Information Available                  7.56  7.56  1688 x 2232
> proj:    0 created: 2006075 154636  memo: RT GVAR
> type:PRD      cal type:BRIT
> offsets:  data=    1280 navigation=  256 calibration=  768 auxiliary=    0
> doc length:   0   cal length:   0   lev length:   0 PREFIX=   0
> valcod:          0 zcor:  0 avg-smp: N
> start yyddd: 2006075  start time:150014  start scan:  316
> lcor: -300  ecor:  8885  bytes per pixel: 1  ss: 74
> Resolution Factors (base=1):   Line=    8.0   Element=    8.0
> imglist.k: done

This listing also tells us that the calibration block starts at byte 768.

> Any ideas?

Please take a look at the calibration block settings to see what the
creators of the product consider to be valid calibrations.
 

Cheers,

Tom
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: QQA-176689
Department: Support McIDAS
Priority: Normal
Status: Closed


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.