# A Graduate Level Course on DNB and NCC

Is there any post on this blog that doesn’t have to do with scaling the DNB or NCC?

I was going to title this post “Revisiting ‘Revisiting “Revisiting Scaling on the Solstice”‘”, but that would just be ridiculous. Besides the fact that we just passed an equinox (and are months away from a solstice), this post is more of a follow-up to our very first post.

If that was an introduction, this is a graduate level course. Well, maybe not. It won’t take a whole semester to read through this, unless you are a really slow reader. But, since Near Constant Contrast (NCC) imagery is coming to AWIPS in the very near future, now is a good time to prepare for what’s coming.

We start off with some good news: NCC imagery is coming to AWIPS! NCC imagery provides an alternative to ERF-Dynamic Scaling, CSPP Adaptive Scaling and whatever this is:

Example VIIRS DNB image displayed in AWIPS using the Histogram Equalization method. Courtesy Eric Stevens (UAF/GINA).

(I know that the above image uses the “Histogram Equalization” algorithm that was developed for CSPP originally. I was just being dramatic.) NCC imagery is an operational product, not some fly-by-night operation from CIRA or CIMSS (who both do great work, by the way).

Now the bad news: NCC imagery as viewed in AWIPS might not be the best thing since sliced bread. It may not solve all of our problems. To understand why, you have to know the inner workings of AWIPS (which I don’t) and the inner workings of the NCC EDR product (which I do).

Here’s a first look at the NCC product as displayed in AWIPS:

Example NCC image (12:39 UTC 19 August 2015) displayed in AWIPS II. Image courtesy John Paquette (NOAA).

Notice the bright area of clouds northwest of Alaska that suddenly become black. Also notice the background surface just looks black, except for the Greenland Ice Sheet. These are examples of two different (but related) issues: the first being that AWIPS is blacking out areas where the image is saturated (the maximum value on the scaling bounds is too low), the second being that, at the low end of the scale, the image detail is lost (either the minimum value on the scaling bounds is too high, or AWIPS uses too few shades of gray in the display, which means you lose sensitivity to small changes in value).

If you read the first post on this blog (that I linked to), or you read my previous posts about ERF-Dynamic Scaling, you know that the primary problem is this: the VIIRS Day/Night Band is sensitive to radiance values that span 8 orders-of-magnitude from full sunlight down to the levels of light observed during a new moon at night. Most image display software, of which AWIPS is an example, are capable of displaying only 256 colors (or 96 colors if you use N-AWIPS). How do you present an 8-order-of-magnitude range of values in 256 colors without losing information?

Near Constant Constrast imagery does this by modeling the sun and moon to convert the Day/Night Band radiance values into a “pseudo-albedo”. Albedo (aka reflectance) is simply the percentage of incoming solar (and lunar) radiation that is reflected back to the satellite, so you end up with a decimal number between 0 and 1. That’s easy enough to display, but we’re not done. What happens when there is no moonlight at night because the moon is below the horizon (or it’s a new moon)? What happens when there is a vivid aurora, or bright city lights, or gas flares or fires? These light sources can all be several orders of magnitude brighter than the moon, especially when there is no moonlight. There are lots of light sources at night that the DNB detects that aren’t reflecting light – they’re emitting it. That’s why the NCC doesn’t provide a true albedo value.

When VIIRS first launched into space, the NCC algorithm assumed that pseudo-albedo values over the range from 0 to 5 would be sufficient to cover all these light sources, but that turned out to be incorrect.  If you weren’t within a few days of a full moon, images contained fill values (no valid data) because these myriad light sources fell outside the allowed range of 0 to 5. It took a lot of work by the VIIRS Imagery Team to fix this and get the NCC algorithm to where it stands now. And where it stands now is that pseudo-albedo values are allowed to vary over the range from -10 to 1000. (The “-10” accounts for the occasional negative radiance in the DNB data and the “1000” allows for light sources up to three orders of magnitude brighter than the moon.) Now, the images don’t saturate or get blanked out by fill values at night away from a full moon. But, the range from -10 to 1000 still presents a challenge for those who want to display images properly.

To show this, here are the same three VIIRS NCC images linearly scaled between the full range of values (-10 to 1000), the original range of values (0 to 5) and the ideal range of values (which was subjectively determined for this scene):

Example VIIRS NCC image (08:55 UTC 5 August 2015) linearly scaled between -10 and 1000.

Can you see the one pixel that shows up in the above scaling? (There is one pixel with a value over 900.)

Example VIIRS NCC image (08:55 UTC 5 August 2015) scaled between 0 and 5.

Now you can start to see some cloud features and the city lights, but this image still looks too dark.

Example VIIRS NCC image (08:55 UTC 5 August 2015) scaled between 0 and 1.5.

Now we’re talking!

The above images were taken when there was moonlight available. What happens when there is no moonlight?

Example VIIRS NCC image (12:57 UTC 26 July 2015) scaled from -10 to 1000.

Scaling over the full range of values means you only see the city lights of Honolulu and the islands drawn on the map.

Example VIIRS NCC image (12:57 UTC 26 July 2014) scaled from 0 to 1.

Scaling from 0 to 1 is better, but I would argue that it’s still too dark. Let’s stretch it further.

Example VIIRS NCC image (12:57 UTC 26 July 2015) scaled between 0 and 0.5.

This is about as good as you can do without the image becoming too noisy.

And, of course, the presence of the aurora gives yet another result:

Example VIIRS NCC image (11:32 UTC 22 January 2015) scaled from -10 to 1000.

Can you see the aurora over northern Alaska? Maybe just barely. Once again, scaling over the full range of values doesn’t work (just like it wouldn’t for the DNB radiance values). What about using the scale of 0 to 1.5? It worked before…

Example VIIRS NCC image (11:32 UTC 22 January 2015) scaled from 0 to 1.5.

GAHH! I’m blinded! Although, you can see the clouds over the Gulf of Alaska pretty easily as well as ice leads in the Arctic Ocean. But, the aurora is too bright and you can’t see any details over most of Alaska.

It turns out, in order to prevent the aurora from saturating this scene, the image needs to be scaled over a range of 0 to 21:

Example VIIRS NCC image (11:32 UTC 22 January 2015) scaled from 0 to 21.

But, notice that you lose the detail of the cloud field over the Gulf of Alaska and the ice over the Arctic Ocean. This is a difficult case to scale correctly. More on that later.

So, we’ve seen that the optimum scaling bounds vary from scene to scene. The 0 to 1.5 scale seems to work for daytime and full moon scenes. New moon scenes require a scale more like 0 to 0.5 (or thereabouts) to be able to detect clouds, snow and ice. And the occasional scene requires a totally different scale altogether. Wouldn’t it be great if there were some way to automate this, so we wouldn’t have to keep fussing with the scaling on every image?

I’m here to say, “there might be.” And, it’s called “Auto Contrast.” The idea is to do what Photoshop and other image editing software do when they “automatically” improve the contrast in the image. The idea is to take the NCC image data, scaled over a range from 0 to 2, for example, bump up the maximum value bound of the scaling with the same kind of adjustment the ERF-Dynamic Scaling uses to prevent saturation in auroras, then apply something similar to Photoshop’s Auto Contrast algorithm to create the ideal scene contrast. Here’s what Auto Contrast does for the three cases above:

Example VIIRS NCC image (08:55 UTC 5 August 2015) scaled with Auto Contrast.

Example VIIRS NCC image (12:57 UTC 26 July 2015) scaled with Auto Contrast.

Example VIIRS NCC image (11:32 UTC 22 January 2015) scaled with Auto Contrast.

For the first two cases, Auto Contrast is very similar to the subjectively determined “ideal scaling”. For the aurora case, we can see that Auto Contrast is a compromise between “not allowing the aurora to saturate” and “allowing the aurora to saturate half of the image.” The aurora does saturate a portion of the scene, but you can still see ice on the Arctic Ocean and clouds over the Gulf of Alaska when you look closely.

Of course, there are a few caveats:

1) Auto Contrast has not been fully tested. These results are promising enough that I wanted to share it right away, but it might not produce ideal results in all cases. We are continuing to investigate this.

2) Sometimes, the image has poor contrast that Auto Contrast can’t fix. For example, a new moon case over land where there are lots of city lights or a vivid aurora. Non-city areas will be more like the Hawaii case, where clouds have pseudo-albedo value between 0 and 0.5, and the city lights or aurora will have pseudo-albedo values well over 100. If you stretch the scaling enough to see the clouds, you’ll be blinded by the city lights. If you scale it to the city lights, you won’t see the clouds or snow or ice.

3) Individual users may not care that the aurora saturated half the image in the third example because they can see the clouds and ice just fine. Auto Contrast makes the clouds and ice darker and harder to see. This is example of how “ideal contrast” not only varies scene to scene, but also from one user application to another. Pretty pictures are not always the same thing as usable images.

4) Demonstrating the utility of “Auto Contrast” is not the same thing as getting the algorithm up and running within AWIPS. (Or, sending files to AWIPS that have optimized contrast.) The JPSS Imagery Team is working with the developers of the AWIPS NCC product to improve how it is displayed, but it will likely take some time.

While it’s not clear how the NCC images are currently scaled in AWIPS, they almost certainly use a fixed scale. However, the examples shown here make it clear that the scaling needs to adjust from scene to scene – even if Auto Contrast is not the ultimate solution. So while we work to figure this out, if the NCC imagery looks sub-optimal in your AWIPS system, you know why.

One final thought: the Auto Contrast algorithm is designed to work with any image, not just NCC images. It’s possible that DNB images created with ERF-Dynamic Scaling may be improved with Auto Contrast as well. But, that’s a topic for another blog post about image scaling for the future. I may yet title a post “Revisiting ‘Revisiting “Revisiting Scaling on the Solstice”‘”.

# The nice (and dedicated) people of N-ICE

Imagine this scenario: you’re stuck on a boat in the Arctic Ocean in the middle of the night. The winds are howling, the air is frigid, and the boat you’re in is completely encased in ice. Step off the boat and your face is constantly sand-blasted by tiny ice particles. Blink at the wrong time and your eyes freeze shut. The ice may crack under your feet (or between you and the boat)  – without notice – leaving icy water between you and the only warm place for hundreds of kilometers. Have to swim for it? Look out for jellyfish. Decide to stay on your crumbling patch of ice? I hear polar bears can get pretty hungry. Death awaits every misstep and every wrong turn. Cowering in the boat? Internet access is limited, there are no re-runs of Friends to keep you entertained, and the shuffleboard court is outside. (Actually, it’s worse than that: there is no shuffleboard court!)

Now imagine this: you actually wanted to be there!

Most people would say, “That’s crazy! I would never do that!” But, for the scientists and crew aboard the research vessel (RV) Lance, it is a unique opportunity to further our understanding of the Arctic and its role in the Earth’s climate system.

You see, we are nearing the mid-point of the N-ICE 2015 field experiment, which is taking place from 1 January to 1 August 2015. The idea behind the experiment is to take a boat, freeze it in the Arctic ice sheet, and constantly monitor the environment around the boat for about six months. A group of scientists work in six-week shifts where they monitor everything from the weather to local biology. Of course, the primary objective is to see what happens with the ice itself.

One of our very own researchers at CIRA (and one of the world’s leading experts on snow) was on board during the first leg of the experiment.  So, what is a snow expert doing on a ship whose primary purpose is to study ice?

Here’s the lowdown. There are two types of ice that concern Arctic researchers: “young” and “multi-year”. As the name implies, multi-year ice is ice that survives the summer and lasts for more than one year. Young ice does not reach its first birthday – it melts over the summer. Arctic researchers have been finding out that, not only is the Arctic ice sheet shrinking, it’s lost most of its multi-year ice, which is being replaced by young ice.

Multi-year ice is thicker, more resilient and tends to be brighter (more reflective), while young ice is thinner, darker (less reflective of sunlight), and less resilient. The less sunlight that is reflected, the more sunlight is absorbed into the system and this leads to warming, which melts more ice (and is a positive feedback). The less ice there is, the more open ocean there is, and open water is a lot less reflective than ice, which leads to more absorption of sunlight, more warming, more melting, etc.

The thinner “young ice” breaks up more easily due to wind and waves. This creates more leads of open water. The water, being much warmer than the air above it, pumps heat and moisture into the atmosphere, creating more clouds and snow – just like lake-effect or sea-effect snow. And, while most people have a hard time believing it, snow is a good insulator. Snow on top of the ice will create a blanket that protects the ice from the really cold air above. This reduces the rate at which the ice thickens up, keeping the ice thinner, and we have another positive feedback.

That’s just one of the things being studied on the 2015 Norwegian Young Sea Ice Cruise. Of course, I wouldn’t be mentioning any of this unless VIIRS could provide information to help out with the mission.

Go back to the N-ICE 2015 website. Notice the sliding bar/calendar on the bottom of the map. You can use that to follow the progress of the ship. Or, you can use the VIIRS Day/Night Band.

At the time of this writing, the Lance is docked in Longyearbyen, the largest town on the island of Spitsbergen in Norway. (Spitsbergen is part of the Svalbard archipelago, which has a direct connection to VIIRS. Svalbard has a receiving station used by NOAA that collects and distributes data from nearly all of their polar-orbiting satellites.) Longyearbyen is where the RV Lance and Norwegian icebreaker KV Svalbard departed for the Arctic back in mid-January. KV Svalbard escorted the RV Lance into the ice sheet, then returned to Longyearbyen while the Lance froze itself into the ice. See if you can see that in this loop of VIIRS Day/Night Band images from 12 – 17 January 2015:

Animation of VIIRS Day/Night Band images from 12-17 January 2015. These images cover the area of the N-ICE field experiment, north of Svalbard.

Notice how the one bright light follows a lead in the ice until it stops. Then the light appears to split in two, with one light source heading back the way it came and the other stuck in the ice. That is the start of N-ICE 2015!  The KV Svalbard did its duty. If you look closely, there are also some other boats hanging out in the open water near the edge of the ice sheet during this time.

If you suspect there are jumps in the images you’re right. VIIRS passes over this area every day 6-8 times between 00 and 12 UTC, with no overpasses for the next 12 hours.

Toward the end of January you can see how the RV Lance drifted to the west along with the ice:

Animation of VIIRS Day/Night Band images from 23-30 January 2015. These images cover the area of the N-ICE field experiment, north of Svalbard.

This was all according to plan. But, then, in February, the winds shifted and helped the ice spit the boat back out towards the open water:

Animation of VIIRS Day/Night Band images from 8-15 February 2015. These images show the area of the N-ICE field experiment, north of Svalbard.

After this, the RV Lance needed help from the KV Svalbard to be repositioned in the ice sheet near where it started a month earlier. Otherwise, all the instruments they placed in the ice would no longer be in the ice – they’d be at the bottom of the ocean as the ice sheet broke up all around them.

If you want to know why the ship seems to disappear and reappear every day, you can thank the sun. You see, the first few weeks of the experiment took place during the long polar night. But, by mid-February, twilight began to encroach on the domain during the afternoons. This was enough light to drown out the light from the ship. (Sunrise occurred in early March.)

Another thing to notice with these last two animations: the cloud streets that form over the open water near Svalbard. The direction these cloud streets move gives a pretty good indicator of where the ice is going to go, since both the clouds and icebergs are being pushed and pulled by the same wind.

It’s fascinating to watch the movement of the ice over the first 6 weeks of the field experiment. To save on file size and downloading time, the animation below only uses one image per day (between 10 and 11 UTC). Here’s 6 weeks of images in 5 seconds:

Animation of VIIRS Day/Night Band images from 11 January to 28 February 2015. These images show the area of the N-ICE field experiment, north of Svalbard.

And you probably thought of sea ice as being relatively static.

Once again, we lose sight of the RV Lance because of afternoon twilight in mid-February, so we can’t see it or the KV Svalbard after that. And note that there’s a lot less open water near Svalbard by the end of the period.

What if we didn’t have the Day/Night Band? You wouldn’t be able to see the ships at all, that’s for sure! Plus, this area was under darkness (no direct sunlight) for this six week period, so none of the other visible wavelength channels will work.  That leaves us with the infrared (IR), which looks like this:

Animation of VIIRS IR (M-15) images from 11 January to 28 February 2015. These images cover the area of the N-ICE field experiment, north of Svalbard.

Note that clouds appear to have a greater impact on the detection of ice (and distinction between ice and clouds) in the IR. When it’s relatively cloud-free, there is enough of a temperature contrast between the open water and ice to see the icebergs but, pretty much any cloud will obscure the ice. So, why doesn’t the Day/Night Band have this problem?

That has to do with the optical properties of clouds at visible and IR wavelengths. Most of these clouds are optically thick in the IR and optically thin in the visible. The Day/Night Band can see through these clouds (most of them, anyway) while channels like M-15 (10.7 µm) shown here, can’t. We’ve seen more extreme examples of this before.

In the rapidly changing Arctic, it is nice to know that there are a few dedicated individuals who risk frostbite, hypothermia and polar bears to provide valuable information on how the ice impacts the environment both locally and globally. Me: I’ll just stick to analyzing satellite data from my nice, comfortable office, thank you.

By the way, the N-ICE field experiment has it’s own blog, and pictures and other snippets of information about the people and progress of the mission are regularly posted to Instagram, Facebook and Twitter.

# Revisiting “Revisiting Scaling on the Solstice”

Imagine that you are an operational forecaster. (Some of you reading this don’t need to imagine it, because you are operational forecasters.) You’ve been bouncing off the walls from excitement because of all the great information the VIIRS Day/Night Band (DNB) provides. “This is so great! Visible imagery at night! It helps in so many ways,” you say to yourself or to anyone within earshot. What’s more: you read this blog and, in particular, you’ve read this blog post and/or this paper. “All our problems have been solved! We can use the DNB for any combination of sunlight and moonlight! I am so happy!” Then you come across an image like this:

VIIRS DNB image created using “erf-dynamic scaling” (15:14 UTC 21 January 2015)

If you’re short tempered, you’re thinking, “@&*!@#&#!!!” If you have better control of your emotions, you’re thinking, “Me-oh-my! Whatever happened here?” Welcome to the third installment of the seemingly-never-ending series on how difficult it is to display the highly variable DNB radiance values in an automated way.

In the previous installment, which I will keep linking to until you click on it and re-read it, I outlined a great new way to scale the radiance values as a function of solar and lunar zenith angles that I call the “erf-dynamic scaling” (EDS) algorithm because it is based on the Gaussian error function (erf). This algorithm uses smooth, continuous functions to account for the 8 orders-of-magnitude variability in DNB data that occurs between day and night, and which was demonstrated to beat many previous attempts at image scaling. Unfortunately, that algorithm produced the image you see above.

So, is my algorithm a failure?

Well, if you’re going to jump right to “failure” based on this, you need to calm down and back off the hyperbole. Do you feel like a failure every time you make a mistake? Besides, mistakes are opportunities for learning.

My demonstration of the quality of the EDS method was based on images taken near the summer solstice. Now, we’re a month after winter solstice. And you know what happens in the winter that doesn’t happen in the summer? The aurora! (Actually, the aurora is present just as much in the summer, but you can’t see it because the sun is still shining.) Now that the nights are so long and dark, the aurora is easily visible.

My EDS method accounts for sunlight and moonlight. It doesn’t account for auroras and they can be several orders of magnitude brighter than the moonlight – especially near new moon when there is no moonlight. And guess when the image above was taken relative to the lunar cycle.

Now, I knew auroras would mess up my scaling algorithm (“Oh, sure you did!”), but I underestimated their occurrence. As a “Lower-48er,” I’ve seen the aurora once in my life. But, at high latitudes (*cough* Alaska *cough*) they happen almost every night in the winter. They’re not always visible due to clouds, but you can’t call them a “rare occurrence”.

From the perspective of DNB imagery, auroras can get in the way. Or, auroras can act as another illumination source to light up important surface features. Let’s look at the above image, with the data re-scaled by manually tweaking the settings in McIDAS-v:

VIIRS DNB image manually scaled (15:14 UTC 21 January 2015)

Of course, this image is rotated differently, but that’s not important. The important thing is that you can see now that it’s an aurora and you can see surface features underneath it. Cracks in the sea ice are visible! (And, remember, there is no moonlight here – just aurora and airglow.) Much better than the wall of white image, right? This proves that it’s a problem with my scaling and not with the DNB itself.

So, how do we get my scaling to work for this case? In theory, the answer is simple: bump up the max values until it’s no longer saturated. In practice, however, it’s not that simple. This was a broad, relatively diffuse aurora that was barely brighter than the max values. Some auroras are much more vivid (and much brighter than the max values), like this one:

VIIRS DNB image with modified “erf-dynamic scaling” (11:34 UTC 22 January 2015)

If you increase the max values until nothing is saturated, you’ll only be able to see the brightest pixels (which are usually city lights) and nothing else. And, don’t forget: we don’t want to increase the max values everywhere all the time, because the algorithm works as-is when the aurora isn’t present (or when the moonlight is brighter than the aurora).

Here’s the solution: calculate max and min values with the EDS method as before, but increase the max values by 10% at a time until only a certain percentage of the image is saturated. That’s what I’ve done in the last image above, where I’ve adjusted the max values until only 0.5% of the image is saturated. In case you’re wondering, here’s the same image without this additional correction:

VIIRS DNB image with unmodified “erf-dynamic scaling” (11:34 UTC 22 January 2015)

The correction makes it much better. What about for the first case I showed? Here’s the corrected version:

VIIRS DNB image with modified “erf-dynamic scaling” (15:14 UTC 21 January 2015)

Once again, much better than before. You can see the cracks in the sea ice now! (Maybe it’s not as good as the manual scaling but, because it’s automated, it takes less time to produce. )

Of course, this correction assumes that less than 0.5% of the image is city lights or wildfires or lightning. And, it might not work too good if the data spans all the way from bright sunlight to new-moon night beyond the aurora because it darkens the non-aurora parts of the scene (as can be seen in the images from 22 January 2015). But, the great thing is: if the scene is not saturated by the aurora (or some other large bright feature) no correction is applied, so you still get the same great EDS algorithm results you had before.

As a bonus to make up for the initial flaws in the EDS algorithm (and to get any short-tempered viewers to stop cursing), enjoy the images below of a week’s worth of auroras as seen by the DNB (with the newly modified scaling). Make sure you look for the “Full Resolution” link to the upper right of each image in the gallery to see the full resolution version:

# Revisiting Scaling on the Solstice

OK, so by this time, it’s about a month after the Summer Solstice in the Northern Hemisphere. If the title bothers you, just replace “solstice” with “summer”. Then replace “on the” with “now that it’s” to make the sentence grammatically correct.

If you read the very first post on this blog (you may want to go back and read it again, even if you already did) you would know that it’s difficult to display VIIRS Day/Night Band (DNB) imagery when the day/night terminator is present. The data varies by 6-8 orders of magnitude between day and night (depending on the moon and other factors), which is tough to represent when you only have 256 colors available to make an image. That’s why the Near Constant Contrast EDR exists.

But, what if you don’t have access to the Near Constant Contrast (NCC) data? Is there anything one can do to get useful information on both sides of the terminator in the same image?

The short answer is: yes. The long answer is: yesss. But, that’s not to say the results are always going to be perfect.

Over the years, I have acquired examples of things that various people or groups have tried that didn’t work. Like this one:

VIIRS DNB example from 11:57 UTC 1 May 2013. This image is scaled for “day”, “night” and “twilight” regions. Image courtesy GINA.

Or this one that you should have seen before (if you re-read the blog post I told you to read):

VIIRS DNB example from 12:48 UTC 13 August 2013. This image uses solar zenith angle-dependent scaling. Image courtesy of GINA.

This is not to single anyone out (especially because I don’t know the names of the people who produced these images) – I’ve tried a number of things that didn’t work out either. Knowing why they don’t work is the key to finding something that does work.

The first example tried to divide up the image into a “day” side, “night” side and “twilight” area in-between, then scale each region independently of the others. Of course, that leads to discontinuities at the boundaries of each region. (The brightest “twilight” pixels border the darkest “day” pixels, etc.)

The second example broke up the image into many different zones based on solar zenith angle, and then (I assume) applied some kind of smoothing to prevent discontinuities. But, you still end up with a wavy pattern of anomalously brighter and darker areas within each solar zenith angle zones. That’s distracting.

When I was developing software to produce Day/Night Band imagery from across the globe, I thought I had something when I scaled the imagery based on the median radiance values in the image. (If you want to know how it worked, it was along these lines: scale the image linearly between max and min values where max = [median*8 < maximum data value] and min = max/256) You didn’t need to know if it was day or night. Unlike before, this scaling didn’t highlight the day side or the night side when the terminator was in the scene. It highlighted the twilight zone (Ahhh! Run away!), like this:

VIIRS DNB image from 13:32 UTC 10 May 2014. This image uses “median-based” linear scaling, as described in the text.

Not perfect. But, in my defense, this scaling does work for most of the globe. The tropical group at CIRA uses it for their DNB images on “TC Realtime“. Also, it doesn’t work too bad near the solstice, when most of Alaska is on the “day” side of the terminator, even in the primary “nighttime” overpass:

VIIRS DNB image from 13:48 UTC 21 June 2014. This image uses “median-based” linear scaling, as described in the text.

It has the added benefit that you can associate each level of brightness with a specific radiance value.

Now, I was going to leave my DNB scaling as is because, “Hey, we can just use the Near Constant Contrast (NCC) in these situations. Why break my back trying to re-invent the wheel?” That is, after all,  the primary point of the NCC – to make it easy to display DNB across the terminator. Then CIRA temporarily lost access to NCC data. My hand was forced. I had to think of a solution.

How about this idea: instead of finding the median value of the whole domain, break up the domain into small zones according to solar zenith angle, and then apply the same “median-based” linear scaling? Here’s what you get if you break up the image into solar zenith angle bins of 0.01 degrees:

VIIRS DNB image from 13:48 UTC 21 June 2014. This image uses “median-based” linear scaling over zones grouped by solar zenith angle.

Not bad. You get a lot of contrast throughout the image (particularly on the “night” side), but it still has stripes in it. This is due to the fact that the presence or absence of clouds (or city lights or whatever) is constantly changing the distribution of radiances within each solar zenith angle bin. The stripes get larger if you use larger bins. Smaller bins means a smaller sample size and, therefore, “less stable” median values. What we need is more of an absolute scale rather than a relative scale.

At this point, it occurred to me that Steve Miller at CIRA (my boss, but that doesn’t mean I’m brown-nosing) already came up with a solution. He developed a “dynamic scaling” method where max and min are based solely on the solar and lunar zenith angles.

VIIRS DNB images from 1 June 2014 and 14 June 2014 spanning the terminator. These images use “dynamic scaling” as defined in the text.

As you can see, the dynamic scaling produces good contrast on both sides of the terminator, which is what users are typically looking for. It’s important to be able to identify clouds and surface features (like icebergs, for example) throughout the entire image – not just on one side or the other or just in the middle.

In my bungled attempt to apply his dynamic scaling within my software, I had another epiphany. If you plot the radiance values (on a log-scale) as a function of solar zenith angle across the terminator, you get something that looks like this:

Scatterplot of observed DNB radiance values as a function of solar zenith angle for the 13:53 UTC 12 July 2014 overpass. Gray curves represent the max and min bounds used for the scaling.

Doesn’t that look a lot like the error function turned sideways? This became the basis for a new form of “dynamic scaling”: find the error function that fits the maximum and minimum expected values of the data as a function of solar and lunar zenith angles.  In fact, those are the curves plotted on the graph. Steve Miller’s dynamic scaling is simply a piecewise linear approximation to my error function curves. (Or, more correctly, you could say my error function curves are a continuous approximation of his piecewise functions.)

A similar error-function-like distribution of radiance values occurs across the moon/no-moon terminator, except the range is only 2-3 orders of magnitude instead of 6-7. We simply multiply the lunar zenith angle-fitted error function and the solar zenith angle-fitted error function on the “night” side to account for the variation in radiance from full moon to new moon.  When you do that (and apply a square-root correction), you get this image from a night with a full moon:

VIIRS DNB image from 13:53 UTC 12 July 2014. This image uses “erf-dynamic scaling” as described in the text.

And this image from a few nights after last quarter moon:

VIIRS DNB image from 13:48 UTC 21 June 2014. This image uses “erf-dynamic scaling” as described in the text.

These compare pretty well with the Near Constant Contrast imagery from the same times:

VIIRS NCC image from 13:53 UTC 12 July 2014.

VIIRS NCC image from 13:48 UTC 21 June 2014.

Here’s what the piecewise linear dynamic scaling gives you:

VIIRS DNB image from 13:43 UTC 21 June 2014. This image uses “dynamic scaling” as described in the text.

VIIRS DNB image from 13:31 UTC 13 July 2014. This image uses “dynamic scaling” as described in the text.

And, if you’re curious, the “erf-dynamic scaling” works just as well during the day as it does at the terminator. Here is an example of the DNB with this scaling, followed by the associated NCC image:

VIIRS DNB image from 22:01 UTC 21 June 2014. This image uses “erf-dynamic scaling” as described in the text.

VIIRS NCC image from 21:58 UTC 21 June 2014.

Of course, the exact form of the error functions could be tweaked here or there to provide a better fit to the natural variability of the observed radiances. But, after one lunar cycle of testing, the results look promising. It is possible to scale the Day/Night Band across the terminator to provide useful information for “day” and “night” (and even across the scary twilight zone)!

UPDATE (27 January 2015): The “erf-dynamic scaling” algorithm has been implemented in CSPP. So users of that software product should be on the look-out for the latest version. (It was added in October or November 2014. I don’t know the actual date.) Thanks to the folks at CIMSS who develop CSPP for quickly adding this! We look forward to collaborating more with the CSPP developers on future products.  Also, you can read about a correction to the “erf-dynamic scaling” algorithm here.

# Funny River Isn’t Laughing

Imagine you’re getting ready for bed. You take one last look out of your bedroom window and you see this:

Photo of the Funny River Fire, taken near 1:00 AM local time (0900 UTC), 21 May 2014. Courtesy Bill Roth/Alaska Dispatch.

Good luck sleeping!

That is the light and smoke from the Funny River Fire, which started on 20 May 2014 and rapidly grew to over 44,000 acres in under 48 hours. Rapidly expanding fires like this one burn through a lot of fuel and can create a lot of smoke. Enough smoke to be seen by radar:

And certainly enough smoke to be seen from space:

VIIRS “True Color” RGB Composite of channels M-3, M-4 and M-5, taken 21:58 UTC 20 May 2014

Look for the grayish plume arcing from the Kenai Peninsula out over the Gulf of Alaska. That is one impressive smoke plume!

The image above is what we like to call a “True Color” image. It is a combination of the red, green and blue visible-wavelength channels of VIIRS (M-5, 0.67 µm; M-4, 0.55 µm; M-3, 0.48 µm, respectively), so named because it represents the “true” color of objects as the human eye would see them. It is the most commonly used “RGB composite”, which is why a number of people simply refer to it as the “RGB”. To add more confusion, other people call it “Natural Color” because it is only an approximation of the “true” color and has to be corrected for atmospheric effects (i.e. Rayleigh scattering) to look right. However, we want to distinguish this from the EUMETSAT definition of “Natural Color”, which looks like this:

VIIRS “Natural Color” composite of channels I-1, I-2 and I-3, taken 21:58 UTC 20 May 2014

Notice that the smoke plume isn’t as easy to see in the Natural Color image. This is because we are looking at longer wavelengths {1.61 µm (I-3, red component), 0.87 µm (I-2, green component) and 0.64 µm (I-1, blue component)} and smoke scatters less solar radiation back to the satellite as the wavelength increases. This is also why the smoke appears blue – the only channel of the three really able to see the smoke plume is I-1 (the blue component). The fact that we are able to see the smoke at all in the Natural Color image is a testament to just how much smoke there is!

Here’s another Natural Color image from a few orbits before, which happened to be right after sunrise:

VIIRS “Natural Color” composite, taken 13:48 UTC 20 May 2014

The smoke plume is as optically thick as a cloud, and is even casting shadows!

Now, the Funny River Fire is the perfect opportunity to introduce another RGB composite being developed at CIRA for use with VIIRS, which we call the “Fire Temperature RGB”. This RGB composite uses the near-IR and shortwave-IR channels to highlight fires. The blue component is M-10 (1.61 µm), the green component is M-11 (2.25 µm) and the red component is M-12 (3.70 µm). Here’s what the Fire Temperature RGB looks like for the 21:58 UTC overpass:

VIIRS “Fire Temperature” composite of channels M-10, M-11 and M-12, taken 21:58 UTC 20 May 2014

This is yet another example of just how large a fire this is!

The Fire Temperature RGB provides information on how hot (or how “active”) the fire is. This is due to the fact that fires generally show up best around 4 µm. At shorter wavelengths, the amount of background solar radiation increases, so fires need to be hotter to be visible. This means that relatively cool or small fires will only show up in M-12 and appear red. Hotter fires will show up in M-11 and M-12 and appear yellow. The hottest, most active fires will be detected in all three channels and show up white. Also, there’s very little sensitivity to smoke, as you can see, so the imagery provides useful information even with such a thick smoke plume. Due to radiative differences between liquid droplets and ice particles, ice clouds tend to appear dark green, while liquid clouds appear more blue.

At night, M-11 doesn’t produce valid data (although there is a push from several user groups to change that), but M-10 and M-12 still provide valuable information. In fact, the only thing you can see at night in M-10 are fires and gas flares. Even without M-11 at night, we can use the Fire Temperature RGB to monitor the fire around the clock (whenever VIIRS is overhead) and here’s an animation to prove it:

Animation of VIIRS Fire Temperature RGB images of the Funny River Fire (2014).

In the first frame, the fire is obscured by clouds (we still can’t see through those) but, after that, you can see the fire was pushed to the shores of Tustumena Lake. With nowhere else to go, the fire expanded east and west.  The fire slowly loses intensity until the last two frames, when activity picks up on the north side. (Although, clouds block the view of the east flank of the fire at that time, so we can’t say how active it is there.) Also notice on the second and third nights  (11:00 to 13:00 UTC) that the fire appears less intense. This is probably due to the combination of reduced fire activity at night and the presence of clouds that are not visible at night in this RGB composite.

Here’s what the Funny River Fire looked like in the high-resolution fire detection channel (I-4, 3.74 µm) for the same times:

VIIRS channel I-4 images of the Funny River Fire (2014)

For this image, cooler pixels appear light, while warmer pixels appear dark. Pixels with a brightness temperature above 340 K have been colored. This channel by itself shows the clouds over the fire at night, but it can be ambiguous during the day because liquid clouds are highly reflective at this wavelength, so they also look warm.

It has already been demonstrated that the Day/Night Band is capable of detecting fires at night (click here and here for examples). So, why not just use it here? I tell you why: the day/night terminator is already encroaching on the nighttime overpasses. This makes it difficult to see fires, since the light from the fire is competing with light from the sun. This was a particularly intense fire on the first night though, so the Day/Night Band was able to see it (as evidenced by this Near Constant Contrast [NCC] image):

VIIRS NCC image, taken 12:09 UTC 20 May 2014

As you can see, the NCC product shows both the fire and the smoke plume. Notice also that you can’t see any city lights, even though it’s still nighttime over the fire because there is enough twilight to drown out the signal. That makes fire detection with the Day/Night Band tricky when the terminator is so close. It’s only because the Funny River Fire was so intense that we are able to see it.  Of course, since it was so intense, we are able to see the smoke easily even if we can’t see the light from the fire.