This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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.