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

[McIDAS #KFB-284893]: Converting units in satellite data

Hi Carol,

re:
> First, where is the abincalb.inc file?

In the $MCSRC directory.  For v2019, this would be ~mcidas/mcidas2019/src.

re:
> Second, do the stretch tables always need to be defined from 0 to 255. 

No.  The idea behind a stretch is the user can define how the
displayed image looks by mapping ranges of brightness specific
ranges of data values.

re:
> I don't think I quite understood this until now. See this example of two
> stretch tables for meters versus feet.
> 
> [mcidas@typhoon ~]$ su.k TABLE L2-CTH
> BREAKPOINTS STORED IN TABLE : L2-CTH.ST
> INPUT       OUTPUT
> -----       ------
> 5000          3
> 20000         250
> CALIBRATION TYPE  : ABIN
> CALIBRATION UNITS : M
> BAND NUMBER       : -1
> INTERPOLATION TYPE: LIN

OK...

re:
> su.k: DONE
> [mcidas@typhoon ~]$ su.k INI L2-CTH-FT X FT
> su.k: DONE
> [mcidas@typhoon ~]$ su.k MAKE L2-CTH-FT 0 65000 0 255
> su.k: DONE
> [mcidas@typhoon ~]$ su.k TABLE L2-CTH-FT
> BREAKPOINTS STORED IN TABLE : L2-CTH-FT.ST
> INPUT       OUTPUT
> -----       ------
> 0             0
> 65000         255
> CALIBRATION TYPE  :
> CALIBRATION UNITS : FT
> BAND NUMBER       : -1
> INTERPOLATION TYPE: LIN
> su.k: DONE

This is the stretch that I sent as an example.  It was designed to
simply change M to FT for the full range of values.  I did this so
that the values returned by 'D' could be converted to FT
and then checked to make sure that the labels on the BAR would
show correct values.

re:
> I attached two example images. Where the blue starts isn't equal where
> ~14200 meters != ~39000 feet. I would assume the problem lies where I'm
> defining 5000 meters at the 3 brit level. I need to do the whole range 0 to
> 19812 for 0 to 255 brit levels, right?

I think that what you need to do is work backwards like I did.  I
used the full range of brightness values and used the entries in the
'abincalb.inc' file to see how those would map to the full range of
data values.  If you want a subset of the range, you will need to
adjust your brightness range to match your 'inlo' and 'inhi' values.

Here is the relevant portion of the HELP for SU:

HELP SU
SU -- Image data stretching utility
   SU INI name type unit <keywords>
   SU MAKE name inlo inhi britlo brithi
   SU LIST string
   SU TABLE name
Parameters:
 ...
   inlo | low value of the breakpoint for input values; specify in units
          input with the 'unit' parameter
   inhi | high value of the breakpoint for input values; specify in units
          input with the 'unit' parameter
 ...

You have remember that the stretch is changing how the display looks,
not how the data values are mapping to brightnesses (brightness is the
display unit).

re:
> What's an example where you wouldn't want to define all 0 to 255 brit
> values in the stretch table?

When you are working with the calibrated unit that is available
in the system, you can play around with how things will look in
the display.  The "classic" use for a stretch was for water vapor
imagery where the variation in data values was represented by
a small range in brightness values. Using the following stretch
would accentuate the look of the display created by IMGDISP so
that areas of rapidly changing temperatures (water vapor imagery
are IR images and the calibrated unit for IR images is TEMP).
The Unidata MCGUI was setup to use the H2O.ST stretch when displaying
water vapor images from GVAR satellites (e.g., GOES13, 14, and 15).
The stretch listing shows the mapping:

SU TABLE H2O
BREAKPOINTS STORED IN TABLE : H2O.ST
INPUT       OUTPUT
-----       ------
 140           0
 215           255
CALIBRATION TYPE  : GVAR
CALIBRATION UNITS : BRIT
BAND NUMBER       : -1
INTERPOLATION TYPE: LIN
SU: DONE

Here, the temperature range of 140 to 215 was stretched over
the full range of display "colors" represented by the brighness.
If one did not use a stretch, the full range of temperature
values would be mapped to the full range of brightnesses, and
the display would look washed out.

McIDAS-X does not have a built-in way of saying that one wants
to treat height values that are in M as FT.  The stretch example
that I provided was just used to show FT as the unit of cloud top
height instead of M.  The IDV and McIDAS-V, on the other hands,
have the capability to easily change the unit of the display
(assuming, of course, that it was of the same type, length[M]
to length[FT]; temp[K] to temp[C], etc.).

I am afraid that the above is not very clear, and, for this,
I apologize.  Perhaps reading the McIDAS Users Guide pages
on the SU command would help to make more sense of what a 
stretch is used/useful for.


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: KFB-284893
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.