20021017: BAR command and using a stretch on a remapped NEXRCOMP image (cont.)

>From: "Paul L. Sirvatka" <address@hidden>
>Organization: College of DuPage
>Keywords: 200210041733.g94HXZ106826 McIDAS NEXRCOMP BAR IMGREMAP IMGCHA

Paul,

I am back at this:

re: sequence to suppress low dBz values and label with BAR

>THis is still not right...I would like the bard to be divied up in 5 dBZ
>increments.

The sequence of commands I sent you did result in a display with
a BAR that was divided into 5 dBz increments:

http://www.unidata.ucar.edu/staff/tom/gifs/cod.gif

I have reviewed the process you are implementing, and I think I can
shed some light on why things are not working as anticipated.  See
below...

>This was the EU colors I chose
>
>mcidas@climate:~$ eu.k TABLE TESTBREF                  
> Brightness  Blue      Green      Red
>  min max   min max   min max   min max
>  --- ---   --- ---   --- ---   --- ---
>    0  15     0   0     0   0     0   0
>   16  31   100 100    60  60     0   0
>   32  47     0   0    50  50     0   0
>   48  63     0   0    90  90     0   0
>   64  79     0   0   130 130     0   0
>   80  95     0   0   170 170    10  10
>   96 111     0   0   210 210    50  50
>  112 127     0   0   255 255   100 100
>  128 143     0   0   255 255   255 255
>  144 159     0   0   155 155   155 155
>  160 175     0   0     0   0   255 255
>  176 191     0   0     0   0   130 130
>  192 207   255 255   255 255   255 255
>  208 223   255 255     0   0   255 255
>  224 241   150 150     0   0   150 150
>  242 254     0   0     0   0     0   0
>  255 255   255 255   255 255   255 255
>
>This was based on the fact that I did an IMGDISP with the SU keyword.

The process you are taking makes use of an IMGREMAP of a NEXRCOMP image
into a copy of a satellite image (like one of the images from the
Undata-Wisconsin broadcast (images in GOES projections) or a GINI image
from NOAAPORT (images in conic projections)).  The copy of the selected
image has its own set of calibrations, none of which do not match that
for any radar image EXCEPT brightness.

Remapping the composite NEXRAD image into the satellite image copy will
not change the available calibrations in the remapped copy of the
composite.  So, what you end up with is an image whose unit is
brightness.  Given this, the stretch table you want to use when
displaying the remapped copy does not have units that match:

>mcidas@climate:~$ su.k TABLE TESTBREF
>BREAKPOINTS STORED IN TABLE : TESTBREF.ST
>INPUT       OUTPUT
>-----       ------
> 5             0
> 75            255
>CALIBRATION TYPE  : NIDS
>CALIBRATION UNITS : ECHO
>BAND NUMBER       : -1
>INTERPOLATION TYPE: LIN

OK, so since the remapped copy of the composite radar image does not
have units of ECHO, you can not use this stretch to load the image.

>So if I am reading this right, I took the values of reflectivity from
>5 yo 75 and stretched them to be brightness values from 0 255...therefore the
>enhancement I created should work in plotting out things correctly.
>see examples at http://weather.cod.edu/mcradar/ especially the nrnil one
>which has the color bar.

This will work when plotting the original composite radar image since it
does supports units of ECHO.  Since the remapped copy no longer has
the information to support units of ECHO, you will be forced to work
with brightnesses (I tried changing parameters in the resultant image
file header, but I was unsuccessful in getting it to "think" that it
was a radar image with full calibration).

>It works and looks good. I just cannot get the imgremap one to work since
>it appears to have different units?

Exactly.

>Sorry that I am not getting this.

This is the tricky stuff that requires a lot of knowledge of how
applications really work.  It took me awhile to really understand what
you were wanting to do and what the ramification of are.

I think that the key point here is that when remapping into a copy of a
satellite image, the only units that will be available are the ones
associated with that image and that are common to the image you are
remapping.  The only one in common in this case is brightness.  Given
this, the only stretch tables you can use in loading the remapped image
are ones that use units that are available in the image - brightness.
This means that you would be limited to a stretch table that stretches
brightness only, and this is not what you want to do since  BAR will
use the stretch used during the image display to annotate the image
regardless of whether or not the user specifies the SU= keyword.

This brings me back to my original suggestion:  don't load the remapped
image with a stretch and use a stretch with BAR for annotation.  I
wrote the BAR application to be able to use any stretch table for
annotation as long as the image was not loaded with a stretch.  This
allowed me to correctly annotate satellite IR/topography composites
correctly.  It is useful for display purposes (web pages, etc.) but
not for interactive purposes.

Taking my original approach will unfortunately mean that you will need
to modify the enhancement you use in the display of the image since you
set values in it based on loading using a stretch.

>I have spent a lot of time trying!

I understand and apologize for things being harder than they first
appear.

Tom