20030623: Inclusion of remap2.pgm and cloudp.c in Unidata McIDAS XRD

>From: "Craddock, Mary Ellen" <address@hidden>
>Organization: Northrop Grumman Information Technology, TASC
>Keywords: 200306121159.h5CBxXLd023117 TASC remap2

Mary Ellen and Dave,

>       We'd be happy to allow you to include the "TASC" version of
>remap2.pgm and cloudp.c in Unidata's next McIDAS XRD release. Obviously, we
>would want to remove all comments regarding TASC specific changes to
>remap2.pgm (originally provided by Dave Santek at UW), as well as comments
>addressed as "rja" or "mel/mec".

I guess I don't understand this, but it doesn't appear to be too much
work to rip out those comments from the code.

>I think it is also important to recognize
>the original author of remap2.pgm and cloudp.c, Dave Santek.

When a program is bundled with Unidata McIDAS in the XRD section, it is
usually provided "as is".  No attempt is made to create new/additional
materials that give appropriate credit to those involved in its
development.  This is in line with the change histories contained in
core McIDAS code.  After all, if we were to include kudos for a
program's author, folks might fatigued reading about all of the code
that Dave has developed for McIDAS over the years :-)

>TASC has made
>modifications to remap2.pgm and cloudp.c since receiving it in its modified
>form from Dave in 1999, however, we are not the original authors. You may
>want to confirm Dave's approval to include the code as well.

Since remap2.pgm has been contributed to the XRD/MDF, I naturally
assumed that derivatives of it would be OK to pass along to users.  I
am sure that Dave will correct me if I am mistaken in this assumption.

>       Finally, I have been meaning to point out to you the reason why you
>have problems looking at the remapped AREA files. In cloudp.c we multiply
>the radiance and brightness temperatures by 10. Therefore, to display the
>data you must define a SU table for the appropriate channels. (e.g., IMGDISP
>GE/REMAP.1 BAND=4 SU=IR4). I have included the tables and their values
>below. Let me know if this solves your display problems.

OK, this now makes sense.  Thanks for including the stretch tables.

Tom

>SU=ALB  ( to display channel 1)
>INPUT  OUTPUT
>1      0
>400    255
>500    255
>CALIBRATION TYPE:
>CALIBRATION UNITS: RAW
>BAND NUMBER: -1
>INTERPOLATION TYPE: LIN
>
>
>SU=IR4  ( to display channels 2, 4, and 5)
>INPUT  OUTPUT
>0      255
>1800   255
>2400   255
>3000   0
>CALIBRATION TYPE:
>CALIBRATION UNITS: RAW
>BAND NUMBER: -1
>INTERPOLATION TYPE: LIN
>
>SU=REF  (to display channel 3, reflectivity product during the "day")
>INPUT  OUTPUT
>0      0
>100    255
>CALIBRATION TYPE: GVAR
>CALIBRATION UNITS: RAW
>BAND NUMBER: -1
>INTERPOLATION TYPE: LIN
>
>SU=FOG  (to dispaly channel 3, fog product during the "night")
>INPUT  OUTPUT
>78     0
>178    255
>CALIBRATION TYPE: GVAR
>CALIBRATION UNITS: RAW
>BAND NUMBER: -1
>INTERPOLATION TYPE: LIN
>
>Thanks,
>Mary Ellen

Tom

>From address@hidden Tue Jun 24 11:39:44 2003

No problem...except I don't know if I want the recognition!

dave

>From address@hidden Tue Jun 24 11:50:04 2003

re:

>After all, if we were to include kudos for a
>program's author, folks might fatigued reading about all of the code
>that Dave has developed for McIDAS over the years :-)

I figured you through this in just to see if I'm bothering to read these 
emails....

dave

>From address@hidden Tue Jun 24 20:20:00 2003

My goodness, the emails about this are a tad over the top! Sorry for
the particulars Tom, but I didn't feel it correct to claim credit nor
the ability to solely approve the use of this code without Dave's
consent. My reason for removing comments from remap2.pgm was to clean
it up, not to hide Randy's or my initials. Do as you wish.

Regards,
Mary Ellen