Add colormapped IR geotiffs as a supported feature of G2G

[djhoese]

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

[jpnIII]

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]

From some feedback on a separate project that displays G2G imagery, these are from Tim Schmit:

[graemely]

@evas-ssec put quite a bit of effort into setting up color plots of GOES-R series IR bands for the CSPP Geo GRB and AITF package quicklooks, including determining what colormaps, limits and scales to use for each band. She consulted with the GOES-R Imagery team, and the code is in Python. That would be a good starting point.

[djhoese]

Sounds good. @evas-ssec if you can point me to that information that would be great.

[evas-ssec]

My notes are not in great shape, but here's where I kept the bulk of them:
https://gitlab.ssec.wisc.edu/cspp_geo/AIT_FW_Quicklooks/-/issues/10

You can also look through the stuff that's in the AIT_FW_Quicklooks code. The relevant stuff is framework_data.py, I think. It's been a while since I tampered with it.

[djhoese]

This is being discussed again as something that could/should be worked on for GeoSphere, at least as a future possibility. The first step for that is proving that colormaps for IR bands can be easily applied. This has been a priority for me since needing to add initial ABI L2 products (#412) which use colormaps (as Eva linked to above) and because of issues reported by Jim over email regarding colorbars being flipped or not flipped or not supporting flipped limits. This should all be fixed in my work in #412, but definitely needs to be documented.

Based on my own opinion and discussions with @graemely and @kathys in the past, I don't think G2G will default to colorized IR images for ABI L1b, but will either:

1. Document how it can be done.
2. Provide separate "composites" that are colormapped and let the user choose those if they'd like.

[jpnIII]

Very good, Dave – thank you! Sincerely, Jim From: David Hoese ***@***.***> Sent: Tuesday, March 8, 2022 12:15 PM To: ssec/polar2grid ***@***.***> Cc: James P. Nelson ***@***.***>; Mention ***@***.***> Subject: Re: [ssec/polar2grid] Add colormapped IR geotiffs as a supported feature of G2G (#286) This is being discussed again as something that could/should be worked on for GeoSphere, at least as a future possibility. The first step for that is proving that colormaps for IR bands can be easily applied. This has been a priority for me since needing to add initial ABI L2 products (#412<#412>) which use colormaps (as Eva linked to above) and because of issues reported by Jim over email regarding colorbars being flipped or not flipped or not supporting flipped limits. This should all be fixed in my work in #412<#412>, but definitely needs to be documented. Based on my own opinion and discussions with @graemely<https://github.com/graemely> and @kathys<https://github.com/kathys> in the past, I don't think G2G will default to colorized IR images for ABI L1b, but will either: 1. Document how it can be done. 2. Provide separate "composites" that are colormapped and let the user choose those if they'd like. — Reply to this email directly, view it on GitHub<#286 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AARELF4UK5HYIIPLB4L4EJDU66KJXANCNFSM4OZ4LSEQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[djhoese]

Unfortunately we didn't have time to fully discuss all of the options and effects documenting and adding these types of features will have on the overall user experience (mostly with reading the documentation and getting confused). We'll move this to G2G 1.2.