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

20030625: Inclusion of remap2.pgm and cloudp.c in Unidata McI DAS XRD

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

Hi Mary Ellen,

>       After rereading your email my requests regarding the status of the
>code may have been misinterpreted. My request to remove TASC specific
>references/comments was only to clean up the code. And the reference to the
>original author, Dave S, was to acknowledge is right to weigh in on the
>decision to incoporate the code in Unidata XRD, not to include an epistle on
>the author at the start of the program.

OK.  I was concerned that associations with TASC had to be deleted for
some reason (security?).  You never know these days...

>I am not as familiar with how code
>is shared between UW and UCAR so I just wanted to point that out to you both
>in my original email. I hope I didn't ruffle anyone's feathers.

No feathers ruffled here, and it doesn't sound like Dave was much
concerned either.  My email responces to your email were not very
explanatory because I am so swamped with work.

>       Let me know if you would like any interpretations of
>remap2.pgm...what changes were made to suit our problem and why.

This would be something useful to put in the comment card section at
the beginning of the program.  The reason I thought that the program
might be useful in a broader context was the approach you took in
calling a customized C routine to replace one of the bands.  The idea
could be useful for others who have similar interests.

>The most
>obvious is that remap2.pgm keeps the full 10-bit stream of data. The use of
>cloudp.c was to replace the 6.7um water vapor channel with either the fog or
>reflectivity product depending on the time of day since the water vapor
>channel is not used in cloud detection. 

Right, exactly.

The whole idea of keeping 10-bit data during a remap is a very useful
one.  At some point it seems like IMGREMAP needs a facelift that would
allow the user to keep the higher resolution of the input data.  One
would have to remember, of course, that the data does get changed
during the remap.  The comment card section at the end of the AREA file
would document this, so one could always go back and review what was
done to an original image to create the current one.

Cheers,

Tom