not paths but filenames, it is given by a Python specification that required here the escaping (backslash) of the single quote characters. Lazy programmer that could not imagine someone was going to actually read this stuff, if you ask me.
Thx for backslash explanation. sftp opens ok after getting re-routed from web browsers to Fetch 5.7.5 freeware, except that gcom-w1.jaxa.jp requires a username/password other than 'guest' or 'anonymous' so registration.
sftp://gcom-w1.jaxa.jp/AMSR2/2016/2016.07/L1/L1R/2/GW1AM2_201607220009_183D_L1SGRTBR_2210210.h5.gz
It uses Polar Stereographic standard for sea ice concentration data
The netCDF file at AMSR2 3k, as opened in Panoply, only shows the land mask as georeferenced (Geo2D). The polar stereographic standard at WorldView, NSIDC etc is EPSG 3413. Its two free parameters are latitude of exact scale (70º but elsewhere 75º) and featured longitude ('Greenland down' but elsewhere Greenwich meridian, 45º off). Rotations other than multiples of 90º degrade images.
The option for PS projection in Panoply do not include their EPSG number so it becomes necessary to import EPSG 3413 to be sure. The sea ice concentration does come with lat/lon layers. However upon plotting, it gives a very distorted x,y image with plate carree or mercator-like rectangular grid lines. Looking at the polar hole, that appears as elliptical. By manual rescaling the x coordinate to make the hole into a circle, Panoply was able to produce the PS-like image shown above.
Lazy programmer that could not imagine someone was going to actually use Panoply, if you ask me.
We are now 14 years into Panoply code development at Nasa/Goddard with scarcely a word of explanation of how to use it (no manual, no example). A couple of offsite .edu attempted tutorials 6-7 years ago but these have become obsolete because the sample files are no longer offered at Panoply. However the version history and list of bug fixes is excellent.
http://www.giss.nasa.gov/tools/panoply/versions.htmlhttp://www.giss.nasa.gov/tools/panoply/Meanwhile, I took a closer look at resolution and palette colors in UH AMSR2 3k maps of sea ice concentration.
First note that two images for each date are provided. The LARGE version is 2x the size of the normal png. By rescaling with interpolation shut off, followed by pixel differencing in gimp, it emerges that the two versions are identical except in coastal detail and rendering of the annoying lat/lon overlay (which should have been provided separately as a transparent overlay or as pole plus crosses at lat/lon intersections).
In other words, it's worth using the larger format -- 4x the file size adds up -- if making animations of the Northwest Passage because the waterways are better distinguished from land.
Both versions are clean. This is highly unusual elsewhere in climate science imagery. Clean means if you additively color-pick each of the 100 palette bars at radius 0, the entire palette and all the sea ice (and nothing else) are selected. This is the easiest way to mask and replace the orange land, inland lakes, and lat/lon gray grid.
The first image below needs to be viewed and saved at full size if you plan to use its masking. Note how its edges merge right into forum boundary gray. That's because png has an option for saving transparency. If you open the image and delete this alpha channel, the gray will be replaced by whatever is set as background color.
The palette itself looks clean but is not entirely. It is not dithered or show lossy compression that uncouples it from map colors, like 99% of what we see. The black and gray-dithered boundary has various inconsequential mistakes that come from not using photoshop-like preparatory software. The color bars have variable widths, a peculiar design error but not harmful.
The 100 RGB values, as a numerical table listable in ImageJ or described individually in gimp, all have 100% saturation. However there is a peculiar jump midway in blue hue with significant consequences to determining day to day change in time series.
The best way to investigate palettes (which often come without any documentation) is to first expand the initial size, here 774 x 52 pixels, to a 774 x 774 square, making sure to exclude there's been no interpolation (ie still have the same 100 colors). While that's too big to display properly on the forum, the size can be halved to 387 x 387 -- despite the irregular widths -- without any change in palette colors.
Next, the square is duplicated to a second layer and rotated 90º, allowing various interactions of the palette with itself (such as differencing) to be characterized. As shown below, this quickly reveals the peculiarities of the AMSR2 3k palette relative to a constructed palette with a pure hue overtint of regularly spaced grayscales.
Gifs are restricted to 255 colors so only selected 24-bit pngs could be shown, the most common operations we use on these forums. Animations have to dither horribly on color gradients. The AMSR2 palette, be it bug or feature, gives very complex displays in day to day comparisons.
Palette RGBs are best designed in a spreadsheet where values are under strict control because many software menu algorithms don't work as you might expect. They can be displayed in BMP image format and then interchanged.