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:

(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:

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):

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

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

Now we’re talking!

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

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

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

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:

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…

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:

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:

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”‘”.

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:

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:

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:

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:

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

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: