Emission Colors 3

Emission Colors

More lessons

"Colorimetrically correct" is overstating the result. The image is only as correct as the calibrations and assumptions used in deriving the channel-combining weighting matrix. I discovered that there are many factors that contribute to the gain for each recorded channel. The obvious ones are the filter transmissions and the silicon sensitivity, and I obtained data sets from Mike and SBIG that characterized his system.

In addition there are color factors due to viewing through air. The same effect that makes the sun look yellow in a sky of blue, reddening when it gets low, also affects our view of the stars. This atmospheric extinction must be included in the color balancing weights. I found the dataset used by astronomers (La Palma Technical Note 31) and evaluated it for my model.

But even when atmospheric extinction was included, there seemed to be other residual gain factors. I was unable to understand and model them entirely, so I did what one usually does- just measure them. One method is to calibrate the unknown gains on a known spectral class of star. I didn't have a calibration star, so I developed a method to balance the average color of the stars. This won't be right if the population of stars is biased toward a specific color, but on the other hand, the starfield represents the closest thing we have for a white reference in a scene like this.

I'm not particularly happy not knowing the sources of these residual gains, since they might influence the color weighting slightly differently than than as just lumped-gain factors, but they ended up being relatively small, so I accept them as part of the model that can be improved upon in the future.

Another important concept is the "zero level". If there are offsets in the image data, the result will be skewed. This is really critical in images like this where the nebula signal is only a tiny portion of the full dynamic range of the data. Most of the nebula pixel amplitudes are in the first 200 counts out of a 16-bit, 65,000 count range. The baseline level makes a huge impact on the color result.

Mike Cook's data was not truly raw. He had carefully removed the dark-frame and flat-fielded his files. The result was that the image data started somewhere above pixel code value zero, because the sky background is not absolutely black. The background level shows up as the position in the image histogram where the pixel counts suddenly climb.

The conventional placement of the baseline (what I call the "zero level") is at the beginning of this sudden jump in the histogram. This is probably ok for when the image is ready to be displayed, because you can't have negative intensity values, but for color processing it does not work very well.

Consider what the histogram would look like if the sky had no stars or other objects in it, but was otherwise the same. A picture of it would be a flat uniform field (in the absence of vignetting). But the histogram of that picture would not be a single bin with all the pixels in it. Because of various image noise sources, there would be a distribution around some central pixel value. The median of that distribution would be a good position to declare the baseline, half the noise would fall below, half above.

I didn't have a picture of the sky with nothing in it, but the picture I did have was "mostly" just sky. I could make an estimate of where the median might be, based on the left (negative) side of the distribution. The right side would be distorted by actual object pixels, but the negative side is relatively unchanged. This technique worked well at identifying the background level of the sky, and the baseline against which to do color calculations. Histograms are shown below that illustrate the location of the zero level.

Figure 7, The first 1000 bins (of 65536) of the histograms for wideband red, green, and blue frames.

Figure 8, Offsets are applied to each frame's data to set the background sky level to zero. This is important for the subsequent color processing.

previous | next

More lessons "Colorimetrically correct" is overstating the result. The image is only as correct as the calibrations and assumptions used in deriving the channel-combining weighting matrix. I discovered that there are many factors that contribute to the gain for each recorded channel. The obvious ones are the filter transmissions and the silicon sensitivity, and I obtained data sets from Mike and SBIG that characterized his system. In addition there are color factors due to viewing through air. The same effect that makes the sun look yellow in a sky of blue, reddening when it gets low, also affects our view of the stars. This atmospheric extinction must be included in the color balancing weights. I found the dataset used by astronomers (La Palma Technical Note 31) and evaluated it for my model. But even when atmospheric extinction was included, there seemed to be other residual gain factors. I was unable to understand and model them entirely, so I did what one usually does- just measure them. One method is to calibrate the unknown gains on a known spectral class of star. I didn't have a calibration star, so I developed a method to balance the average color of the stars. This won't be right if the population of stars is biased toward a specific color, but on the other hand, the starfield represents the closest thing we have for a white reference in a scene like this. I'm not particularly happy not knowing the sources of these residual gains, since they might influence the color weighting slightly differently than than as just lumped-gain factors, but they ended up being relatively small, so I accept them as part of the model that can be improved upon in the future.
Another important concept is the "zero level". If there are offsets in the image data, the result will be skewed. This is really critical in images like this where the nebula signal is only a tiny portion of the full dynamic range of the data. Most of the nebula pixel amplitudes are in the first 200 counts out of a 16-bit, 65,000 count range. The baseline level makes a huge impact on the color result. Mike Cook's data was not truly raw. He had carefully removed the dark-frame and flat-fielded his files. The result was that the image data started somewhere above pixel code value zero, because the sky background is not absolutely black. The background level shows up as the position in the image histogram where the pixel counts suddenly climb. The conventional placement of the baseline (what I call the "zero level") is at the beginning of this sudden jump in the histogram. This is probably ok for when the image is ready to be displayed, because you can't have negative intensity values, but for color processing it does not work very well.	Consider what the histogram would look like if the sky had no stars or other objects in it, but was otherwise the same. A picture of it would be a flat uniform field (in the absence of vignetting). But the histogram of that picture would not be a single bin with all the pixels in it. Because of various image noise sources, there would be a distribution around some central pixel value. The median of that distribution would be a good position to declare the baseline, half the noise would fall below, half above. I didn't have a picture of the sky with nothing in it, but the picture I did have was "mostly" just sky. I could make an estimate of where the median might be, based on the left (negative) side of the distribution. The right side would be distorted by actual object pixels, but the negative side is relatively unchanged. This technique worked well at identifying the background level of the sky, and the baseline against which to do color calculations. Histograms are shown below that illustrate the location of the zero level.
Figure 7, The first 1000 bins (of 65536) of the histograms for wideband red, green, and blue frames.
Figure 8, Offsets are applied to each frame's data to set the background sky level to zero. This is important for the subsequent color processing.