Please support this Forum and Neven's Blog

Author Topic: Creating Animated GIFs  (Read 5662 times)

Jim Hunt

  • ASIF Governor
  • Posts: 2978
    • View Profile
    • The Arctic sea ice Great White Con
Creating Animated GIFs
« on: May 16, 2015, 09:05:10 PM »
Following a request from jdallen, here's a place to discuss how best to go about creating GIF animations (and who knows, maybe some other sorts also).

As mentioned in the original thread, I currently use ImageMagick, but there are other possibilities. See for example this existing (if short) thread on ImageJ.

If I recall correctly A-Team is also quite fond of GIMP. [PS - Here's Laurent's video]



The next question is "which operating system?". Wipneus will no doubt suggest Raspberry Pi flavoured Linux, but that isn't necessarily everybody's cup of tea!

Finally, for the moment at least, which sequence of images should we use for the initial tutorial?
« Last Edit: May 16, 2015, 09:59:13 PM by Jim Hunt »
Reality is merely an illusion, albeit a very persistent one - Albert Einstein

Laurent

  • ASIF Governor
  • Posts: 2515
    • View Profile
Re: Creating Animated GIFs
« Reply #1 on: May 16, 2015, 09:24:09 PM »
That video for Gimp a free software available here : http://www.gimp.org/
How to Create an Animated GIF With GIMP
https://www.youtube.com/watch?feature=player_embedded&v=Qn7ubD-aeeU

Jim Hunt

  • ASIF Governor
  • Posts: 2978
    • View Profile
    • The Arctic sea ice Great White Con
Re: Creating Animated GIFs
« Reply #2 on: May 17, 2015, 02:02:22 PM »
Personally I am not a Windoze fan. Hence is these circumstances I often use Cygwin to make Windows N work more like *IX.
Reality is merely an illusion, albeit a very persistent one - Albert Einstein

Neven

  • Administrator
  • ASIF Governor
  • *****
  • Posts: 3284
    • View Profile
    • Arctic Sea Ice Blog
Re: Creating Animated GIFs
« Reply #3 on: May 17, 2015, 03:12:34 PM »
Unfortunately I am tied to Windows (for the software I use for work), so a few years ago I decided to purchase this software to make animated GIFs: Easy GIF Animator. Fulfils my needs very well, as I like my animations to keep a small size so people with lower bandwidth don't have to wait ages to see it appear in a blog post.  But I'm sure there's more and better stuff out there.
Il faut cultiver notre jardin

sidd

  • ASIF Upper Class
  • Posts: 1001
    • View Profile
Re: Creating Animated GIFs
« Reply #4 on: May 17, 2015, 06:41:21 PM »
Has anyone suggested ImageMagick yet ?

http://www.imagemagick.org/Usage/anim_basics/#gif_anim

excellent tutorial, many examples. ImageMagick is open source, and can do many more things than animation. All from the command line ...

sidd

Jim Hunt

  • ASIF Governor
  • Posts: 2978
    • View Profile
    • The Arctic sea ice Great White Con
Re: Creating Animated GIFs
« Reply #5 on: May 17, 2015, 06:56:35 PM »
Has anyone suggested ImageMagick yet ?

Yup. See post #1!

I'm happy on the command line, plus scripts for automation, but maybe others here are not?
Reality is merely an illusion, albeit a very persistent one - Albert Einstein

jdallen

  • ASIF Upper Class
  • Posts: 2334
    • View Profile
Re: Creating Animated GIFs
« Reply #6 on: May 20, 2015, 05:31:10 PM »
Thank you gentlemen.  I shall have to apply some of this directly.  I'm currently browsing through prices for a replacement machine - my primary laptop is six years old and falling behind current software.

Gimp questions will follow.
This space for Rent.

Jim Hunt

  • ASIF Governor
  • Posts: 2978
    • View Profile
    • The Arctic sea ice Great White Con
Re: Creating Animated GIFs
« Reply #7 on: May 23, 2015, 07:04:07 PM »
Espen asked how to install ImageMagick on Windows. To the best of my recollection I just followed the instructions here:

http://www.imagemagick.org/script/binary-releases.php

Download the correct .EXE file, depending on whether your Windows installation is 64 bit or not, then run it.
« Last Edit: May 23, 2015, 07:12:35 PM by Jim Hunt »
Reality is merely an illusion, albeit a very persistent one - Albert Einstein

Espen

  • ASIF Governor
  • Posts: 2850
    • View Profile
Re: Creating Animated GIFs
« Reply #8 on: May 23, 2015, 07:39:13 PM »
Havent got a clue my PC is a HP 8760w I7-processor and 16 GB-ram?
Have a ice day!

Jim Hunt

  • ASIF Governor
  • Posts: 2978
    • View Profile
    • The Arctic sea ice Great White Con
Re: Creating Animated GIFs
« Reply #9 on: May 23, 2015, 07:59:46 PM »
I'm making some assumptions here, but if you go to "Control Panel", then "System", it should tell you whether you're running a 32 bit or 64 bit OS.

The 32 bit version of ImageMagick should run on either, but 64 bit's better if your OS supports it.
Reality is merely an illusion, albeit a very persistent one - Albert Einstein

ChadGreene

  • ASIF Lurker
  • Posts: 8
    • View Profile
    • chadagreene.com
Re: Creating Animated GIFs
« Reply #10 on: September 15, 2015, 10:35:33 PM »
GIFs are pretty easy to make in Matlab.  Here's one I made using the seaice function in Matlab:


A-Team

  • ASIF Upper Class
  • Posts: 1656
    • View Profile
Re: Creating Animated GIFs
« Reply #11 on: January 18, 2016, 09:50:46 AM »
Here is a javascript alternative to animated gifs that gives the end-viewer quite a bit more control. The problems with gifs are that (1) there's no speed controller or freeze-frame tool it may be set to play too fast or too slow (necessitating download and fixing locally say in gimp), (2) gifs are stuck in 8-bit indexed color (256 per frame) whereas many cryosphere products (such as ice sheet velocity) need a full 24-bit gamut of colors supported by png and jpg, and (3) satellite photos such as Landsat are in 16-bit depth tif which is essential to contrast optimization.

N Holschuh, a grad student at PSU, developed this new interface which is designed to display co-registered layers in any sequence or rate that the end-viewer wants. He provides examples for NEGIS, Jakobshavn, Pine Island, Thwaites and four other glaciers, apparently as part of a glacier atlas project. Each glacier has layers for surface elevation, bed elevation, ice thickness, velocity (both linear and log scales, and a Landsat. Details such as color keys and dual coordinate systems (mercator and lat,lon) are nicely done.

Note this is a layer-viewer rather than a full GIS engine that allows basic math operations to act on pairs of layers. For that, transparency overlays and conventional gif animations, load into gimp or ImageJ. Note an individual layers themselves could each be animations, say a time series of calving front position.

http://nholschuh.com/glaciers.html try an example or two before reading on.

The javascript is basically an alternative to a standard html click-map which goes to a new url depending on where you click on the base image. Here all the layers are cached temporarily on your computer. Upon mouse-over of the controller, the appropriate new layer loads instantly. The effect is seamless. (The controller won't work on the image below because  forum software does not support embedded html so visit the link above to see it in action.)

I've made quite a few changes to simplify the code and enlarge the display and controller to our maximal width of 700 pixels. It turns out to be easier to generate a controller an arbitrary number of layers with text names using a spreadsheet (rather than html tables)., second image below shows the set-up for 7 layers.

If you copy out the text attached below and save as html, it will correctly load Holschuh's layers for Zachariae/79N in northern Greenland in any web browser (provided you are online). To make your own display, replace the links to paths to your own images (which can be urls to forum images or anything on the web).

I've colored the text below to distinguish the overall html container (blue) from the javascript (purple), controller, and image urls that have to be changed.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<link href="../general.css" rel="stylesheet" type="text/css" />
<script type="text/javascript">
function MM_preloadImages() { //v3.0
  var d=document; if(d.images){ if(!d.MM_p) d.MM_p=new Array();
    var i,j=d.MM_p.length,a=MM_preloadImages.arguments; for(i=0; i<a.length; i  )
    if (a.indexOf("#")!=0){ d.MM_p[j]=new Image; d.MM_p[j  ].src=a;}}
}
function MM_findObj(n, d) { //v4.01
  var p,i,x;  if(!d) d=document; if((p=n.indexOf("?"))>0&&parent.frames.length) {
    d=parent.frames[n.substring(p 1)].document; n=n.substring(0,p);}
  if(!(x=d[n])&&d.all) x=d.all[n]; for (i=0;!x&&i<d.forms.length;i  ) x=d.forms[n];
  for(i=0;!x&&d.layers&&i<d.layers.length;i  ) x=MM_findObj(n,d.layers.document);
  if(!x && d.getElementById) x=d.getElementById(n); return x;
}
function MM_swapImage() { //v3.0
  var i,j=0,x,a=MM_swapImage.arguments; document.MM_sr=new Array; for(i=0;i<(a.length-2);i =3)
   if ((x=MM_findObj(a))!=null){document.MM_sr[j  ]=x; if(!x.oSrc) x.oSrc=x.src; x.src=a[i 2];}
}
function MM_swapImgRestore() { //v3.0
  var i,x,a=document.MM_sr; for(i=0;a&&i<a.length&&(x=a)&&x.oSrc;i  ) x.src=x.oSrc;
}
</script>

</head>
<body onload="MM_preloadImages('http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_3.png','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_4a.png','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_4b.png','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_5.png']http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_2.png','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_3.png','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_4a.png','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_4b.png','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_5.png'[/url]]http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_1.png','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_3.png','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_4a.png','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_4b.png','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_5.png']http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_2.png','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_3.png','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_4a.png','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_4b.png','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_5.png'[/url][/url])">
<img src="http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_1.png" ID="swapper" width="700" height="903" border="0" usemap="#Map">

<map name="Map" id="Map">
   <area shape="rect" coords="88,813,199,857" href="#1" onmouseover="MM_swapImage('swapper','','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_1.png',1)" />
   <area shape="rect" coords="197,813,310,857" href="#2"  onmouseover="MM_swapImage('swapper','','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_2.png',1)" />
   <area shape="rect" coords="309,814,415,858" href="#3" onmouseover="MM_swapImage('swapper','','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_3.png',1)" />
   <area shape="poly" coords="413,814,526,814,523,837,469,837,469,859,413,859,413,815" href="#4a" onmouseover="MM_swapImage('swapper','','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_4a.png',1)" />
   <area shape="rect" coords="470,837,524,859" href="#4b" onmouseover="MM_swapImage('swapper','','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_4b.png',1)" />
   <area shape="rect" coords="522,813,636,858" href="#5" onmouseover="MM_swapImage('swapper','','http://nholschuh.com/Ice_Stream_Images/NEGIS/NEGIS_5.png',1)"/>   
</map>

</body>
</html>
« Last Edit: January 19, 2016, 08:54:50 AM by A-Team »

A-Team

  • ASIF Upper Class
  • Posts: 1656
    • View Profile
Re: Creating Animated GIFs
« Reply #12 on: January 19, 2016, 09:09:16 AM »
I'm looking now at comparison of two images via a movable vertical slider. A common example of this is before/after satellite images of a glacier calving. The slider is more effective visually than side-by-side or flickering animation comparisons because the end-user can zero in on a specific region to compare.

Our problem has been getting sliders to display within forum software. Usually the slider is implemented in javascript but there are alternatives, CSS and html5, which may display correctly here. I've collected some links below which contain open source code that will do this; more testing in a bit.

http://lea.verou.me/2014/07/image-comparison-slider-with-pure-css/
http://thenewcode.com/819/A-Before-And-After-Image-Comparison-Slide-Control-in-HTML5
https://codyhouse.co/gem/css-jquery-image-comparison-slider/

http://earthobservatory.nasa.gov/IOTD/view.php?id=86436&eocn=home&eoci=iotd_readmore

A-Team

  • ASIF Upper Class
  • Posts: 1656
    • View Profile
Re: Creating Animated GIFs
« Reply #13 on: January 21, 2016, 01:33:16 PM »
Below, I look at the moderately massive computing requirements to process all the flight sub-segments (GPS waystations) of Operation Icebridge (as served by Cresis) so that all the cross-over intersections with other flights can be called up from a database with all their ancillary data such as bearing, bearing with respect to flow, elevation, ice thickness, bedrock profiles and relevant parts of the radargramss cropped out.

The purpose is to facilitate reconstruct all basal upheavals in Greenland in 3D from all their 2D cross-sections to characterize individual features and additionally determine the total region of affected ice-bedreck interface and overall displacement volumes.

The main product is an online portal that, when queried with a region of interest (point, line, or bounding box), returns all the intersecting (or nearby tracks). The algorithm is very similar to that of satellite image servers such as EarthExplorer, though here the objects are 1D flight lines rather than rectangular satellite scenes.

It’s necessary to work at the level of sub-segments since many flights had curved tracks — working with the whole flight segment means working with a chord shortcircuiting an arced track. The sub-segments do this too but their chords are a vastly closer fit to the curve.

An example suffices to illustrate the overall procedure. In reviewing flight line pdfs near Eqip Sermia, I noticed 19980714_01_017 contained a classical basal deformation some distance inland from the deformation highlighted in Bell 2014. To understand this feature, I needed to pull all other tracks from the Cresis archive that also cut through this deformation.

After a simple paste of the kml file into a grepping spreadsheet (which cleans away extraneous kml terms, rounds data to appropriate precision and creates clean columns), the last 9 way-points are shown below. Only the last 9 are used because they have delimit a basal disruption (based on inspection of the radargram 19980714_01_017), with only way-points 3-6 actually lying within the upheaval. The colums show latitude, longitude west, elevation in meters, flight segment name and order within the line.

This particular flight segment was represented by 41 GPS points nearly equally spaced along the 148 km track, dividing it into 40 segments of 3.7 km width.

70.068805   47.076781   1928   19980714_01_017   9
70.052159   47.15645    1865   19980714_01_017   8
70.033927   47.243766   1748   19980714_01_017   7
70.014753   47.335211   1864   19980714_01_017   6
69.995344   47.425215   1820   19980714_01_017   5
69.975694   47.513974   1694   19980714_01_017   4
69.955976   47.603585   1610   19980714_01_017   3
69.935927   47.696685   1595   19980714_01_017   2
69.91662    47.787071   1557   19980714_01_017   1


To find all other way-segments in the vast Cresis archive of all years in the vicinity of these nine sub-segments could be done ad hoc using visuals in Google Earth. However this becomes very ineffecient in studying hundreds of basal deformations.

It is actually quite easy to collect all the relevent way-points because Cresis provides a master kml file for each of the 21 years for which Greenland data was collected. A click loads that file into Google Earth and copy-paste into a text editor extracts the data. These are effortlessly counted by pasting in Word, replacing commas, and counting the replacements, then halving as three coordinates are separated by two commas. For example, year 2014 had 58 flights and a total of 143,764 way-points; earlier years such as 1998 far fewer, 11 flights and 3,528 way-points.

Overall, the master database of way-stations consists of 654,182 database records (rows) which is quite manageable in Excel though fairly slow for conducting operations:

2014   Greenland   P3/   143764   287528
2013   Greenland   P3/    30391    60782
2012   Greenland   P3/    64036   128072
2011   Greenland   P3/   118421   236842
2011   Greenland   TO/     9310    18620
2010   Greenland   DC8/   41396   82792
2010   Greenland   P3/    40705    81410
2009   Greenland   TO/    10406    20812
2008   Greenland   Grd/   410      820
2008   Greenland   TO/    16736    33472
2007   Greenland   P3/    19773    39546
2006   Greenland   TO/    16102    32204
2005   Greenland   TO/    32428    64856
2003   Greenland   P3/    89149   178298
2002   Greenland   P3/     2745     5490
2001   Greenland   P3/     1694     3388
1999   Greenland   P3/     4955     9910
1998   Greenland   P3/     1764     3528
1997   Greenland   P3/     3528     7056
1996   Greenland   P3/      744     1488
1995   Greenland   P3/     2642     5284
1993   Greenland   P3/     3083     6166
         654182   

However, just to pursue the restricted agenda of finding other flights intersecting the basal deformation (thus providing  different perspectives on its structure), it suffices to collate way-points of just four other kml files (see first image) and collect way-points that lie within a generously defined lat,lon bounding box of the upheaval.

This is easily done by first sorting the database by the latitude column, giving a score of 1 in a new column to appropriate new way-points, then sorting by longitude and doing the same, then summing the two new columns into a third, and doing a final sort for records scoring 2 (which amounts to a logical 'AND' operation).

Next, the qualifying way-points are merged into way-paths, which requires that both ‘feet’ lie within the generous bounding box and that the points be consecutive within their track. After building the respective kml units, these way-paths can be displayed in Google Earth and sorted for those that actually intersect the initial track having the deformation.

The radargrams are collected, contrast-enhanced, rescaled to a common vertical exaggeration, and given a background gridding in gimp according to the number of way-points the image contains. This allows cropping of the radargrams to the bounding box and for intersecting paths, mark-up of the cross-over points on the radargrams.

Overall, the idea is to free up the analyst from endless ad hoc manipulations. All the available data relevant to characterizing each basal deformation in Greenland is at the analyst’s fingertips. While this might not be enough to fully understand the feature, it is a big step forward in hypothesis testing, categorizing, and prioritizing suitable  deformations for additional radar overflights.

A-Team

  • ASIF Upper Class
  • Posts: 1656
    • View Profile
Re: Creating Animated GIFs
« Reply #14 on: January 23, 2016, 11:42:50 AM »
This post looks at slicing and dicing an image into parts and then reconstituting it seamlessly in forum view. The first image does this successfully from the 3 attached tile pieces below (click, hold and drag to see the pieces in the big image) without using an html table. Note the tiles could be separate small gif animations instead of stills.

I've also duplicated this effect within 1x1 and 1x3 forum tables (no longer shown); table controllers cellpadding="0" border="0" cellspacing="0" are not needed in default forum table interpretation.

The small pieces could be saved offsite but online (eg Photobucket) and simply referenced by their urls. This provides a workaround for the 4 image limit of forum software. It could be used for example to display many individual frames of a gif animation. This trick also allows images to be placed inline in association with relevant text rather than merely appended as attachments.

The glaciological idea here is to vertically slice radargrams containing basal deformations in part of the image (especially the ones from curved flight lines) into their GPS way stations and discard slices not relevant to the deformation, make a new Google Earth track from the retained way stations that delineate the overall boundaries of the feature (along the cross-section). It's equally useful for deformation extent mapping to show adjacent track segments that miss the deformation.

Gimp as it stands provides controls over slicing but these are extremely tedious at scale. However 'guides-grid' .scm at the plugin registry, placed in gimp's scripts folder, allows creation of an way station appropriate grid that converts into cutting guides for the guillotine command. That creates a new image for each slice that retains the overall layer structure but it is not so convenient to put the 40 separate files thus generated back into a single image with (40 way stations)*(number of layers per ways tation) total layers.

However once the cutting grids are made, Filters --> Web --> Slice... will systematically name and save all slices of the active layer (as gif, jpg, or png) in an orderly row and column manner into an html table (only the slice image files need to be retained). It is somewhat unfortunate that forum software does not have a storage area for files that only need url pointers but not display as solo attachments. I suspect that they periodically sweep and delete orphaned files (no longer attached to any post), invalidating the url they once had.  .

If the first of the slice files is opened in Gimp, the others can be added in appropriate sequence using File --> Open as Layers ... Slice only operates on the active layer but changing this to the others one layer at a time, then opening these products in that same gimp document, a stack can be built that amounts to a correctly implemented Guillotine command option (sliced with layer retention).

Here each radargram needs a second layer with vertical lines indicating the flight sub-segments between GPS way-stations. Fortunately, these are quite even spaced, presumably because the plane flew at constant speed with readings taken at equal times. This second layer is completely transparent other than one pixel wide vertical waystation lines, meaning the radargram is still easily viewed. These layers should not be flattened because it would wipe out data underneath the grid lines.

The main attribute of this second layer is text values for each way station of lat,lon found in kml files that define the way-station coordinates. Gimp does a poor job importing vector files (eg text) from  the host computer's clipboard -- incomprehensively, even its own internal clipboards don't talk to each other.

There's an undocumented trick that provides a workaround: if all the lat,lon data is copied to the host clipboard and the gimp text tool is clicked on the grid layer as if something were to be manually typed in, a contextual menu pops up that allows importation (paste) of text from an external text editor. If the grid is rotated 90º CW ahead of time and re-rotated 90º CCW after text is situated properly relative to grid lines, the text will read sideways as needed.

A third radargram layer shows the graph of the csv file Cresis provides separately for each radargram. These are apparently generated during the process of manual annotation of ice sheet surface and bottom reflections (colored lines in echo2 radargrams). The fields provided are Lat,Lon,UTC-time,Thick,Elevation,Frame,Surface,Bottom,Quality.

These come in excessive precision that greatly exceeds any conceivable experimental input -- for example, neither bottom nor surface of the ice is not measured to the posted 0.1 mm -- the error is more like 10 m per study of flight crossover points. Thus it is necessary to drop Cresis data into a rounding spreadsheet before working with it.

Of these, surface elevation, bedrock depth and ice thickness are already implicitly graphed in the echo_2 version of the radargram even when cropped laterally to a deformation. Here surface and depth graphs could be usefully deployed as masks (ie flattened onto the radargram itself) to either permanently suppress irrelevant parts of the radargram, constrain action of image enhancement filters to internal ice, or best of all, to provide automated cropping guides above and below (often two thirds of the radargram is wasted space).

Such cropping guided by deformation lat,lon is even more effective in reducing images. That's important because the deformation might later have to be enlarged in bringing it to a standard vertical exaggeration.

Needless to say, to do this on the whole Cresis radargram archive is a fairly massive pre-compute. However it is far more convenient to do this once and for all to allow researchers to get on with the glaciology. The same can be said for horizontal and vertical rescaling to a uniform vertical exaggeration (say 10:1) needed for 3D deformation reconstruction and major aspects of cropping and contrast optimization.



[Edit: quite a few text improvements made above since initially posted.]
« Last Edit: January 24, 2016, 01:34:06 PM by A-Team »

A-Team

  • ASIF Upper Class
  • Posts: 1656
    • View Profile
Re: Creating Animated GIFs
« Reply #15 on: January 24, 2016, 10:03:11 PM »
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.
« Last Edit: January 24, 2016, 10:15:06 PM by A-Team »

Watching_from_Canberra

  • ASIF Lurker
  • Posts: 56
    • View Profile
Re: Creating Animated GIFs
« Reply #16 on: September 10, 2016, 03:36:08 PM »
just testing an animated gif that doesn't seem to animate...
« Last Edit: September 10, 2016, 04:02:10 PM by Watching_from_Canberra »

Jim Hunt

  • ASIF Governor
  • Posts: 2978
    • View Profile
    • The Arctic sea ice Great White Con
Re: Creating Animated GIFs
« Reply #17 on: September 10, 2016, 03:54:11 PM »
just testing an animated gif that doesn't seem to animate...

It doesn't animate for me either. I seem to recall A-Team mentioning that you have to reduce the width to 700 px to keep SMF happy?
Reality is merely an illusion, albeit a very persistent one - Albert Einstein

Watching_from_Canberra

  • ASIF Lurker
  • Posts: 56
    • View Profile
Re: Creating Animated GIFs
« Reply #18 on: September 10, 2016, 04:02:51 PM »
Thanks for the pointer - that seems to be the issue.  I'll go and post it where I first posted it now...

Tigertown

  • ASIF Upper Class
  • Posts: 1143
    • View Profile
Re: Creating Animated GIFs
« Reply #19 on: December 20, 2016, 05:58:52 PM »
If you got something too big to work on here and you don't want to really change it, just make a youtube video out of it and post the link.

Example:
https://www.youtube.com/watch?v=gCgi5RjZ_hI