Animated gifs for long time series presented at data-level resolution suffer file size bloat. One workaround masks out regions that aren't important (which could vary from frame to frame). Masking replaces everything within ots boundary of unimportance with a fixed color -- that compress to almost nothing.
If an alpha transparency channel is used instead, the background gray in forum software will show through. That's usually ok and definitely better practice than the gif-maker's preference color because the end-viewer upon image download gets control over background transparency.
In the case of radargrams, the actual grayscale images is flanked horizontally by very generous white space and scales. The fix there is cropping, though it won't get rid of scale ticks flattened onto the data. Those can be gotten rid of however by opening the pdf compilation in ImageJ (File -->Import -->Extract Images from PDF...).
In the case of 19980714_01 pdf, the images are at resolution 903 x 888 whereas the same image in the archive is 1165 x 919 (its framing container) (eg see https://data.cresis.ku.edu/data/rds/1998_Greenland_P3/images/19980714_01/
Something is really wrong here because the pdf's aspect is 1.02 whereas that of the archival image is 1.27. So one or the other (or likely both) is peculiarly rescaled (irrational different vertical and horizontal multipliers). And how was that rescaling done: nearest neighbor, bilinear, bicubic, or sinc?!? It matters.
Meanwhile wtf is the actual resolution of the data
, is it stored openly or only buried in matlab, and is either of the provided resolutions actually at data resolution
? This is a huge issue for mapping basal deformations and their sub-structures.
Apparently Cresis not only assumes visitors have purchased expensive proprietary command-line software (matlab) and gone through its year-long learning curve but also store the data in its completely unreadable file format (.mat) which opens as total gibberish in text editors.
I find this completely unacceptable in publicly funded science. While .mat may be a wonderfully powerful and flexible container, 99 times out of a 100 nothing but ordinary row and column numbers are being stored (as here). Data should never be stored in anything more complicated than is necessary, here plain old cvs. Let the matlab users import cvs.
The airplane's raw 'trace' files (the 1 pixel wide vertical lines that tile up to make a radargram numerical array) are being processed via various matlab command settings to produce the radargram, its unwanted overlapping edges, text overlays, and badly done scales.
It is on this raw numerical array that 'contrast' tools will optimally operate. Here it is critical to understand the perfect 1:1 correspondence between working on a numerical array and working on its bitmap display via Photoshop-type tools.
Many people fail to realize that gimp, PS, ImageJ, ImageMagick etc are not inherently graphical software, they are just Excel running in the background that produces an imagery front end. Matlab processing an array of numbers is just the poor man's Photoshop. It is imperative to use a graphical front end to exploit synergies with the superb pattern recognition ability of human vision.
Cresis, which is to say matlab, is strictly outputting 8-bit grayscale images. In some software, they open as RGB but in fact there is no color. That's easily proven: ImageJ reads the header and always opens files at their full bit depth. Make a duplicate image, drop it to 8-bit grayscale, form a stack with the original, subtract the layers and observe from the histogram that it is entirely zeroes (pure black). That means no color, not even subtle color.
Where is this grayscale color coming from? I would think matlab normalizes the raw numerical array of radar return power (traces) by dividing by the biggest number to bring everything into [0,1] and then rescales and rounds to integers in the range [0,255]. That opens directly in ImageJ as a BMP or x,y image which is then losslessly converted to more familiar tif or png.
I have huge concerns about the sub-optimality
of this. The data, or at least certain depth ranges of it (ie the basal layers), may actually be of much higher bit depth say 12- or 16-bit. Running with 8-bit would be as crazy as dumbing down a hundred million dollar feature of Landsat-8 to make another Landsat-7.
I will also bet the contrast compression was linear. Huge mistake, it should at a bare minimum set a gamma and optimally be adaptive (as in ImageJ Clahe). Very few users are actually interested in the physical meaning of the absolute radar return strength; this class of users suffers from its retention.
Ice penetrating radar was initially tasked solely with determining depth to bedrock. (Surface elevation is better measured with laser, inSar and optical stereo pairs which are 2D rather than sparse 1D tracks; ice thickness = surface - bedrock.) The goal posts have since moved to internal layer isochrons and basal conditions but archive processing has not moved with it. Bedrock topography was terribly important in older stick-or-slip models but with temperate ice, deformable basal sediment and looser lower ice rheology, that becomes less important to predicting future behavior.
Ultimately, even a greatly improved image of a basal deformation may prove just as mysterious as our current blurry images. The real advantage will come from greatly enhanced ability to map the geographical distribution of anomalous basal conditions (ie get past the dramatic ones to the faint but still critical to sliding and deformation).
I am looking now at Wolfram's Mathematica -- it can open this crappy .mat format and export into plain text cvs. Affordable to anyone (cost: a cup of coffee per month), it is world's apart in mathematical and graphical sophistication from conventional scientific software. It may be worthwhile to dump the whole Cresis archive out of .mat into .cvs as a pre-computed cloud, but it remains to be seen if Wolfram offers a convenient method for bulk processing the whole Cresis archive.http://www.wolframalpha.com/pro/?source=nav
In terms of gif reduction, the images below asks whether the ice surface and bedrock cvs files can serve to define masks. The answer is yes but something is lost even having 409 points per curve per radargram -- they're still chord collections. While the fit might be improved with splines, it is still not quite as good as the original graphic. However a big benefit comes from dropping back a couple of pixels to define crop boundaries, especially in basal deformations of limited extent.