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

[McIDAS #JGN-249914]: IMGMAKE

Hi Mike,

re:
> > McIDAS image displays use brightness which varies between 0 and 255

re:  
> Oh... I think I might know what's going on.  Two things:  While the
> range of the data value is 0:4095 there are also scale_factor and
> add_offset variables that should be applied prior to plotting.  In
> other words, data = (raw_data * scale_factor) + add_offset.  This is
> true for all 16 ABI bands and netCDF utilities I've seen do this
> automatically.

I do this as well for the calibrated unit (e.g., ALBedo for bands 1-6
and TEMP for bands 7-16).  When I compare indicated brightness temperatures 
for the thermal IR band (10.35 um) of NOAAPort-delivered imagery with the
same band in the GRB, I get very good, if not identical, correspondence
(closer to identical for the FullDisk fixed grid images than the remapped
CONUS, Mesoscale-[12] or PuertoRico images.  My problem has been one of
correctly assigning brightnesses to the RAW values reported.  Your information
is a validation to what has been rolling around in the back of my brain
for the past week and a half.  The missing piece for me was documentation
that the temperatures should follow the traditional bi-linear mapping that
has been in use for years.

Aside: one of the things that helped throw of my thinking was in how the
GINI images were/are being calibrated.  All IR bands except for water
vapor used/uses the traditional bi-linear mapping, but the water vapor
images do not.  Go figure!?

re: > 
For bands 1-6 the end result after that math is data
> between 0 and 1, and it's linear so  (0:4095) -> (0:255) can work
> here.  But for bands 7-16 it's different...
> 
> The data for bands 7-16 is not given in reflectance, it's given in
> brightness temperature in degrees kelvin.  Take band 13 for example,
> the raw data is given between 0 to 4095.  However, after scale_factor
> (0.06145332f) and add_offset(89.62) are applied, that range is now
> 89.62 to 341.27ish degrees kelvin.  So if McIDAS is expecting
> brightness (0:255), it needs to be converted first.  In addition to
> that, the conversion is a bi-linear stretch, or a piecewise function,
> based on the input temperature value (details below).  If a simple
> linear stretch is being applied, I bet that would explain the dimness
> of the visualizations.
> 
> From http://www.goes-r.gov/products/ATBDs/baseline/Imagery_v2.0_no_color.pdf
> (pg. 25):
> "For example, if the BT is less then 242 K, then BV08 = 418 – T; while
> for value equal or greater than 242 K, then BV08 = 660 – (2 * T). The
> minimum value allowed is 0 and the maximum is 255."

This is evidently the missing piece, and this makes sense since the
bilinear mapping between brightness and temperature has been fixed
for as long as I have been playing with GOES imagery.  I had thought
that the conversion RAW -> TEMP -> BRIT might be necessary, but I
had not gotten to searching for documentation that indicates that
it is definitely needed.  Thanks for the URL, I'll read that document
this morning, and if things are as you say (and I have no doubt that
they are!), I'll implement the RAW -> CalibratedUnit -> BRIT mapping
in my code; this should be very easy given the way that my code is
structured.

re:
> Actually, glancing at 'SU TABLE IRTEMP' I bet that's what that is
> doing, and why it looked more appropriate when I applied it.

Yes, I created IRTEMP.ST so that BAR could show the correctly mapped
color bar for GOES GVAR imagery.

re:
> Also, if you haven't seen this I've found the following guide useful
> in helping me understand GOES-16 NOAAPort data:
> http://www.nws.noaa.gov/noaaport/document/GOES-R_NOAAPort_SBN_040416.pdf

Now, this document I actually have read.  It does not, however, given
enough information to know that one needs to map RAW -> CalibratedUnit -> BRIT.

re:
> FWIW, I've always treated those scale_factor and add_offset variables
> as dynamic when I do work with them manually.  At the very least they
> vary with each band, and I don't know if or how often they might
> change over time, I always grab their values from the netCDF metadata
> when I need to use them for something, so the values I gave above are
> merely examples.

Yup, my server makes no assumption about what the scale and offset
values should be (i.e., I do not rely on published tables).  It also
makes no assumption about what the high end of the RAW range should be.
Instead, I calculate the high end of the RAW value from the bit depth
of the image as reported in a global attribute.

re:
> I hope this all made sense.

It made/makes perfect sense, and I REALLY do appreciate you taking the time
to send me the information is a well=-written response!

I'll let you know as soon as I have updated my code and how to incorporte
the change into your v2017 pre-release version.

Aside: I heard a disturbing _rumor_ that the GOES-16 images currently being
sent in NOAAPort will be replaced with reworked images.  The rumor (and
I am treating it as such until I seen published evidence that it is
actually true) included comments that the images being sent in NOAAPort
do not/did not pass the operational testing phase.  We'll see!

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.