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

[McIDAS #AIT-655217]: Ticket ID: FVC-112860

Hi Paul,

> OK. Let's take this a little at a time.
> Double checking my understanding.
> On DBZ, i am getting some range of DBZ values depending on the image file
> which would be mapped out to brightness levels by default.

Yes. The ADDE server for NEXRAD Level III data maps original image values
into at least three representations of those values:  RAW, BRIT, and at
least one "calibrated" unit like ECHO for reflectivity (reflectivity
products also have VIP levels).

> So I think that
> if the range of reflectivity is between -22 and 38 DBZ (for instance) the
> -22 DBZ would be 0 on the brightness level while 38 DBZ would map to 255.
> Am I correct?

Almost.  There are other values which must be accounted for and so mapped
to the range of britnesses (e.g., range folding for velocities, etc.).

> OK...I then  want to create an SU table that would map values of -30 to 90
> to plot out in brightness values from 0 - 255. So I should be able to create
> a value about 127 that would always be 30 dBZ...which I can assign a color 
> like yellow.

OK, but... it seems that you are intent on making the new "high resolution"
products look like the old "low resolution" products.  This may be OK
for reflectivities, but will not necessarily work for the newer digital
vertically integrated liquid water product (and others).  Quite frankly
I am scratching my head to understand why you want the old and new products
to look the same.

> So that no matter what comes in, the yellow is 30 dBZ. I am looking for the
> colors to ALWAYS be consistent with their corresponding DBZ value.

This will _not_ work for some of the new dual polarization products where
the range of values is very dynamic.  I considered doing the kind of thing
you are doing with stretch tables in the server, but I decided not to since
I would have had to choose sufficiently large data ranges to cover all
possible values.  For some products this would force all image values into
one display data level.  I chose not to do this given the intent behind
the dynamic data range was to be able to show small variations effectively.

> I would then run an IMGDISP command using SU in the command line and then
> run a BAR command. Am I correct?

Yes, or run the IMGDISP command and then label the image with BAR specifying
the stretch to use.



> I did have these SU line
> SU MAKE PAULBREF -30 -28 0 2
> SU MAKE PAULBREF -27.9 -.1 3 25
> SU MAKE PAULBREF 0 4.9 26 40
> SU MAKE PAULBREF 5 9.9 41 54
> SU MAKE PAULBREF 10 14.9 55 69
> SU MAKE PAULBREF 15 19.9 70 84
> SU MAKE PAULBREF 20 24.9 85 99
> SU MAKE PAULBREF 25 29.9 100 114
> SU MAKE PAULBREF 30 34.9 115 129
> SU MAKE PAULBREF 35 39.9 130 144
> SU MAKE PAULBREF 40 44.9 145 159
> SU MAKE PAULBREF 45 49.9 160 174
> SU MAKE PAULBREF 50 54.9 175 189
> SU MAKE PAULBREF 55 59.9 190 203
> SU MAKE PAULBREF 60 64.9 204 218
> SU MAKE PAULBREF 65 69.9 219 233
> SU MAKE PAULBREF 70 74.9 234 254
> SU MAKE PAULBREF 75 79.9 249 254
> SU MAKE PAULBREF 80 90 255 255
> So If I am correct, levels 115 129 should correspond to 30-34.9 DBZ.
> This command appears to work for me.

OK.  This approach may not be too bad for reflectivities.  It will
not do what you should want for other products.

> I tried to do the same basic thing with
> velocities creating a stretch table by this command
> SU MAKE PAULVEL -70 70  0 255
> When I run the command
> I get the error
> IMGDISP failed (RC=2)

Hmm... this looks like a bug somewhere.

> If I leave off the SU part the command works fine.

Even more evidence of a bug.

> BTW I also used the SU
> table given to us - RVEL and the command would not work.

OK.  Just so you know, I created the stretch tables for use with BAR.
This is not obvious, of course, but it is nonetheless the case.

> I assume the SU keyword should work with all IMGDISP. It is not working
> with the velocity products.

Again, this smacks of a bug.

> Does this seem like a reasonable request?

Sort of. Yes it is reasonable that things should work.  I don't
think that the remapping of display values to make the new "high
resolution" products look like the old, low resolution ones
is really what you want.

> Struggling in Chicago! :-)

I hear you.  I had numerous talks with Michael James (our GEMPAK
guy) about the implications of the dynamic range nature of a number
of the newer products.  I also talked with a couple of university
representatives about the situation when they stopped by to chat.
It seemed to me to leave the dynamic nature of the products until
I could get feedback from more folks (e.g., end-users and the developers
at SSEC).

Sorry for the strangeness of this, but I have been and continue to
struggle with it also.  I'll give you one good example that has
existed as long as Level III products have been supported by
applications made available by Unidata:

- the reflectivity range for a radar operating in storm or
  precipitation mode is very different than the reflectivities
  for ones operating in clear air mode

  If one tries to represent both ranges in a single range, the
  effect is to lessen the variability in one portion of the
  combined range (typically the portion with the lower reflectivities)
  thus losing information in that portion of the combined range.
  I don't think that this is the most useful approach, so I
  fell back to the data <-> color mapping not being fixed.
  Perhaps you never noticed this before?


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: AIT-655217
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.