How the Simulations of Green Flashes Were Made

Introduction

The simulations are presented as gif animations, which requires making each frame as a separate gif image, and then combining them. The combining was originally done with a program called whirlgif, now (2012) superseded by gifsicle; but the hard work is in the first part.

The very first step in simulating a sunset is to choose a model atmosphere — which is to say, choose an atmospheric temperature profile. An obvious choice is the U. S. Standard Atmosphere; but that doesn't produce an appreciable green flash.

Taking a cue from Willard J. Fisher, C. Mostyn (1891), John Evershed (1923) and others, we choose instead a profile in which the sea surface is warmer than the air, which produces the ordinary inferior mirage. Unfortunately, the optical physicists who have studied mirages have tended to choose temperature profiles that were simple analytical functions, so they could produce closed-form solutions. Fortunately, the boundary-layer meteorologists have come up with a more realistic model of the surface layers, called “Monin-Obukhov similarity theory.” This is the basis of the temperature profile used here; I have taken the Obukhov length L to be −10 meters, which isn't far wrong. (See the AMS Glossary for further details.)

Given a temperature profile, you can calculate the refractivity profile. The next step in generating a simulation is to tabulate the astronomical refraction as a function of apparent altitude; the method of Auer and Standish (available for decades only as a preprint (1979), but now finally published) that is recommended in the Explanatory Supplement to the Astronomical Almanac, is used. The refraction table is converted to a transfer curve, which relates apparent and true altitudes in the sky.

The method of tracing the outline of the Sun, given a refraction table or transfer curve, is described by Wegener (1918). Each frame is drawn in PostScript, using a modified version of the awk script I use to draw composites of outline images, such as those in the Zenit article. The pbmplus package contains routines for converting the PS images to gifs and cropping them. It's slow, but it works.

A major problem was the choice of colors. The famous “Web-safe” set of 216 8-bit colors is very limiting; but an even worse problem was that the green in the solar images should be darker than the red Sun itself. Unfortunately, the pure red that I originally wanted to use is too dark, and I had to switch to orange for the overall color of the Sun. Even so, the yellow and green are about the same brightness as the orange, and the gradual darkening as the color runs through the spectrum cannot be properly represented. To make the dark colors more visible, I adopted a black background (which unfortunately makes it difficult to read the names of links already visited; so I tweaked the colors for unvisited and visited links to make them lighter).

I originally traced solar outlines for 5 wavelengths: 470, 510, 550, 580, and 650 nm. Each outline was filled with the appropriate solid color (dark blue, dark green, yellow-green, yellow, and orange, respectively). The shortest-wavelength colors (blue and green) were painted onto the PostScript page first, and then covered up by the longer-wavelength (and brighter) colors. This worked reasonably well for green flashes, but it made the depiction of the red rim and red flashes impossible.

Then I realized the red rim could be represented by painting red before the orange that represents the integrated sunlight. However, there is a slight catch: the real sunset has a gap around 600 nm because of ozone and water-vapor absorption. If I merely put in the correct effective wavelength (roughly 700 nm) for the red, the orange would be too close to it in wavelength, and the red rim would come out too narrow. This problem has been handled by using 750 nm for the red, and adjusting the "orange" wavelength to make the yellow zone narrow (580 nm seems to work well). The result is that everything between 460 and 470 is painted blue; from 470 to 500, blue-green; 500 to 530, green; 530 to 560, yellow-green; 580 to 750 nm, red; and the monochromatic disk for 580 nm (the last wavelength painted) is orange.

Though the result looks reasonable, it is actually slightly incorrect. In the real sunset, only the region of sky fully covered by both red and green light appears orange. Because of the displacement of those monochromatic images, this area of sky is slightly smaller than the monochromatic outline of the Sun that is filled with orange color in the simulations. As the error is only as wide as the sum of the red and blue rims, which is usually under a minute of arc, this is not ordinarily a discrepancy that is noticeable to the eye. But with some mirage-producing models, the discrepancy might be appreciable.

The main difference from the old outline-drawing routine was to fill each path rather than stroke it. This turned up a couple of minor bugs in the drawing script, but these were fairly easy to fix. The result is an accurate outline for each color, but only a small number of discrete colors. Still, the overall effect in most cases is fairly realistic in appearance, despite the lack of proper color blending and the lack of such important features as solar limb-darkening and the extinction gradient with altitude.

In exchange for ignoring these features, we have only solid colors, which the gif algorithm compresses very efficiently. For example, an 8-second animation of the end of a sunset that displays 25 frames per second contains 200 individual frames. This frame rate is fast enough to give a smooth presentation with very little flicker. Yet the whole animation file is only about 50 kB long, which requires an acceptably short download time. However, the high frame-rate required to produce a smooth animation is too much for some browsers (mostly, versions of Internet Explorer). [You can check your browser to see whether it can handle my real-time animations on another page.]

Because whirlgif sets the colors from the first frame, it was necessary to put samples of all the colors used into the title frame. That produces a little blip at the bottom of the title that looks like a tiny bow tie; ignore it.

I had originally intended to have both the overall animation for a sunset and the detailed animation of its final seconds on the same Web page, but discovered that my own graphics subsystem was so slow that they interfered with one another, making the display halting and jerky. In deference to other users with slow graphics systems, I split each page so that only one animation occurs per page.

I'm slowly providing more realistic depictions, using a broader range of colors, and including the omitted effects mentioned above. The files and download times are longer, of course; and a different algorithm has to be used to paint the images. This was not at all practical with my original hardware (an AMD 486-DX4/100 system), which already took an hour to generate each animation. However, its successor (a 1400 MHz Athlon) was fast enough to make such things worth thinking about; and, as of 2012, I'm using an even faster machine … .

But I'm unable to make decent movies from realistic images; the sharp solar limb introduces too many compression artifacts when I try to convert the individual images to jpegs. (I can't use gif animations, because the gif limit of 256 colors is inadequate to display a whole sunset realistically.) The individual images are stored in PNG format, which uses an excellent compression algorithm.

In principle, one could stack these up using the relatively obscure MNG format. But browsers don't support it, and even the viewers that are supposed to don't support it very well. Maybe in a few years…? In the meantime, you can see more realistic colors in some new simulations here.


© 1999 – 2008, 2012 Andrew T. Young


Back to the GF animation introduction

Back to the GF home page