[McIDAS #JGN-249914]: IMGMAKE

Hi Mike,

re: new code to test out 
> Thanks Tom, I'll check into this probably tomorrow.  But first...

OK.

re:
> I just did, may have found a bug.  I haven't done much testing, but if
> I display some IR bands with no stretch utility I see black specs on
> the image (at least bands 09 & 13).  If I move my cursor around the
> gui, it appears to me these specks occur where brightness temperature
> equals 242 kelvin.  Referencing the document from before, 242K is the
> break point is for the bi-linear stretch.

Yup, I saw that as well and saw that it was a small mistake which I
fixed.  I _think_ that the fixed code is running on lead.unidata.ucar.edu
as I just put up band 13 loops for FullDisk and CONUS, and I did not see
any of the black flecks.

re:
> I'm attaching a couple of sample images:
> NEWIR1.gif:  straight display with no SU
> NEWIR2.gif:  SU=IRTEMP
> 
> Beyond that, the images do seem brighter.  I'll be honest though, I'm
> beginning to think we'll use that SU table for most of the IR bands we
> plot.  TBD, but it does seem to yield cleaner-looking images, and
> makes the use of EU tables easier.

When investigating how to implement the square root mapping of brightness
to albedo for VIS images, I was confronted with the short coming of the
way that I was doing my calibration table and calibrating routine.  The
problem is that my assumption had been that all calibration would be
representable with linear mappings, but the need to do:

BRIT = NINT(SQRT(alb)*255)

(this is what SSEC implemented for the GRB-delivered GOES-R images)
invalidates the linear assumption.  Because of this, I will need to
write a new calibration module, modeled after/adapted from the SSEC
one for GRB images.  The job of writing a calibration module was
always on the list of things to do, but I had been figuring that
I could adapt the PRD2 module to do what needed to be done.  Oh well...

re:
> I've never had a chance to play with the data off the GRB, but full
> disk data from NOAAPort has always appeared very coarse.  It's
> described in the data as 6km resolution at nadir.  To look at the full
> disk is one thing, but once you start zooming in it appears pixelated
> in a hurry.

This has been my observation as well.  I assume that the decision was
made to minimize the bandwidth used to transmit the images in
NOAAPort, and because the other sectors (e.g., CONUS, PuertoRico,
Mesoscale-[12] and eventual Alaska and Hawaii) are more tailored to
the needs of WFOs.  I do take issue, however, with the decision to
remap the non-FullDisk sectors into conical projections.  I think that
this was likely done to have continuity during the transition from
the GINI images to netCDF4 images for the WFOs.

re: doing the square root mapping for VIS brightness
> Okay, good to know.  I ended up making a square root EU table and it
> seems to get pretty close.  So if nothing else, a sqrt EU table
> appears to be an option.

After I sent my note yesterday, I admitted to myself that I needed to
create a new calibration module, so that is my next job.

Stay tuned...

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: JGN-249914
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.