[
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
- Subject: [McIDAS #QQA-176689]: using IMGPROBE to retrieve cloud top temps from SATEPS composite
- Date: Thu, 16 Mar 2006 13:35:39 -0700
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
