jpnIII
commented
4 years ago Hi Dave et al. -- I will try to share my thoughts on this matter. I personally am most familiar with colormaps (or McIDAS enhancement curves) that have color throughout the entire range of temperatures (e.g., see the ten(10) infrared (IR) bands at: http://cimss.ssec.wisc.edu/goes-r/abi-/static_and_timediff_imagery.html) -- OR -- colormaps that have colors defined for the typical range of the parameter in question (e.g., Total Precipitable Water (TPW) from 0.0 mm <-> 80.0 mm), plus grayscales where it is assumed there are clouds.
I viewed the U-Tube link Dave provided. It is clear after viewing the talk that I am woefully lacking in knowledge concerning the science of color presentation. I did not understand everything presented. But it seemed the focus was on presenting a new, scientifically sound general colormap that can be used to replace the "Jet" colormap that has been the defacto standard for some time now.
In the meteorological world, the most hard and fast "rule" that I know of for depicting satellite imagery is to show colder brightness temperatures (that are typically clouds, but could be snowcover in the winter (a classically confusing situation!)) in increasingly whiter grayshades -- with (255,255,255) (white) being the coldest temperature depicted, and (0,0,0) (black) being the warmest temperature depicted. Imagery can of course be depicted in the opposite sense, but this has been the accepted norm for many years. The one constant here is that any given grayshade (or color) is always associated with some corresponding radiance brightness temperature, which is what the satellite instrument is actually sensing. And perhaps the most typical method used in meteorology to assign grayshades to brightness temperatures for IR satellite imagery are the classic 163K <-> 330K bilinear brightness temperature <--> (8-bit) brightness equations:
If B > 176, T = 418 - B; or
if B <= 176, T = 330 - (B/2)G2G of course already has these two equations incorporated within.
When showing satellite imagery not as grayshades, but instead as various colors, things become much more complex, at least in my mind. Again historically, the tendency has been to show/enhance warmer imagery brightness temperatures in shades of red/orange, and cooler imagery pixels in shades of yellow/green, progressing to blue for very cold brightness temperatures. Oftentimes, even when colors are used throughout an image, the very coldest brightness temperatures will once again revert to being depicted in nearly or totally white grayshades. For some good examples of colormaps used at NOAA, see: https://www.ospo.noaa.gov/Organization/FAQ/enhancements.html
In terms of what to do with G2G moving forward, one could certainly provide G2G with a default colormap that could be applied to any IR satellite image. But IMHO what is needed is some methodology whereby the user could somehow assign ranges of (8-bit or higher) brightnesses to corresponding imagery radiance brightness temperatures. And maybe corresponding colors could also be incorporated into this model. Of course I am hardly an unbiased commenter, considering my earlier #278 issue. :) But for the #278 issue submission, I was just piggybacking on what smarter folks than I have already implemented within the McIDAS-X package (e.g., see: https://www.ssec.wisc.edu/mcidas/software/x/info/mcstretch_info/#details) . I would also strongly suggest talking with the McIDAS-V developers within SSEC, as they have also dealt previously with this topic of dynamical enhancement curve/colortable generation.
Thank you, Dave!
Sincerely,
Jim
djhoese
graemely
evas-ssec
It is fairly common to have IR bands have a combined colormap that is B/W for warmer temperatures and rainbow colormap'd for the colder clouds. Or is it the reverse? Right now for a user to do this themselves requires making their own colormap, generating the geotiffs with G2G, running add_colormap.sh to add the colormap to the geotiff.
It would be nice if this was easier. Considering Satpy should now support configuring an enhancement with a colormap directly the last 2 steps could be combined. If we provide the colormap with G2G that's another thing the user doesn't have to do. Whether or not this is the new default is another question.
The one part of this I'm against is that a rainbow colormap is a terrible colormap. It is not perceptually uniform. See https://youtu.be/xAoljeRJ3lU for more information. That said, it may be too big a task for the G2G project to change the preferences of meteorologists/forecasters/etc.
This has been requested by @scottlindstrom and @jpnIII so if you guys have other ideas, comment below.
CC @graemely