interstitial: Do you know how to automate gimp?
It's doable to a certain extent but I don't recommend going that route. I found the time spent automating greatly exceeded what it took to perform the task manually many times over, that I invariably wanted to do the task differently after a few days (or lost interest in it altogether), and that even minor version upgrades come with no assurance of backward compatibility to protect the investment. Gimp is thinly staffed by volunteers who are often pre-occupied for years with esoteric priorities whose mainstream utility escapes me.
ImageJ macros are a lot easier to work with. The plugin java structure has engaged a large number of individual contributors, mostly people like us with similar scientific agendas (only in cell biology). You may find a pre-existing macro does about what you want or just needs a few tweaks or additions to transparent script or an email to the originator. No knowledge of programming languages is needed if you can work off examples.
There are thousands (?) of plugins that don't come preinstalled with the download that may do what you want. Even if these are sub-perfect in some way, they don't do any real damage (unlike in a version upgrade elsewhere).
https://imagej.nih.gov/ij/plugins/index.htmlPanoply is a very nice closed gui alternative for netCDF command line. I've written the staff of one with feature requests but while helpful every time, improvement priorities arise from his host institution and important user groups. While you could do keystroke capture macros off your OS, it would make more sense to delve into netCDF libraries to see if you can alter something in in there to better pre-condition your input file to Panoply.
We've previously delved into things like automating Nullschool products but a bazillion practical issues come up like the server being late or down or just not responding, before even getting to the graphical slice'n'dice which takes quite a few steps to get done right.
My view is that AMSR2_UHH is by far the best product out there for visualizing ice concentration (etc) for purposes of the current melt or freeze season. It just does not pay to focus on poor resolution legacy satellites products unless your entire focus is on long term trend continuity. A lot of the latter don't even offer a netCDF much less put error maps within it.
AMSR2_UHH is slated for termination; its PI now works at AWI on an improved product, factoring in observational regimes of the Polarstern expressly designed for algorithmic interpretive improvements. Best of all, end user input is being considered; change is about impossible to bring about on older pipelines set in concrete.
AMSR2_AWI still has its share of weather-related artifacts in summer. These are almost invariably
white bias but sometimes a diffuse blue appears. That being the case, options exist to correct that bias using better weather on earlier days or by masking with cloud-cover sensors like the new NOAA-20 VIIRS.
The key here is that the speed of wind-driven ice is about 1% that of surface wind. In other words, bias-producing weather generally moves on faster than the ice can get out of positional register. So by stacking a few days in gimp and correcting presumptive white bias in the latest date by setting layers iteratively to gimp 'darken only' mode which, the way the palettes are constructed in both legacy AMSR2_UHH and AMSR2_AW, is tantamount to
blue over-ride.
That is, if the weather ever did clear over a particular area of ice during a time that the sensor was making its swath there, the algo gets a chance to process actual ice data and produce an accurate pixels, maybe still white but more likely bluer if a lower concentration was indeed warranted.
The attached example shows
blue over-ride on the 16 Aug 2020 AMSR2_AWI for purposes of a more accurate comparison to a large Sept 2012 AMSR2_UHH rescaled down by 68.38% to fit. The most interesting difference is 2020 low ice between the pole and Greenland to which the 2012 has no counterpart at all.
