One mistake most of us have done at some point is to perform an image blurring downsizing (or other linear pixel operation) on photographs without taking gamma or srgb encoding into account (two different things, but similar enough in practice). Photographs are encoded in srgb color space for best display quality, not in an energy-linear color space. Ideally, your image blurring algorithm should only blur the detail in it and preserve the image brightness intact. Or in other words, if we want the blur kernel to be energy conserving, it will have to operate in linear space rather than srgb or gamma space. So, when blurring a photograph, one should degamma the image pixels before accumulating them, and then probably apply gamma back to the result after averaging for display. This, of course, is something we not always do, because it's a pain and most of the times [retty slow if done by hand (thankfully most GPU hardware these days can do this for you if you choose the correct internal format for your textures).
This observation applies to box blurring, gaussian blurring, image downsampling, sobel filters, and basically anything that is a linear combination of pixel values, but it can probably be best illustrated with this simple box blur pseudocode below.
Here Gamma() and DeGamma() are the gamma correction function and its inverse. These can probably be just approximations, such as Gamma(x) = pow( x, 1.0/2.2 ) and DeGamma(x) = pow( x, 2.2 ), or even Gamma(x) = sqrt(x) and DeGamma(x) = x*x if you really want to save some cycles.
The image below shows on the left side the wrong (and most common) way to blur an image, and the right side shows the result of correct blurring. Note how the correct version does not get darker but retains the original overall intensity after blurring, unlike the one on the left. The effect is pretty obvious in the area where the bus is in the picture. The effect would be even more obvious if the correct and incorrect images were overlapping.
Left, gamma unaware blurring (too dark). Right, gamma correct blurring (correct brightness)
So, remember. If you are on the GPU, use sRGB for textures that contain photographics material and are ready to be displayed as they are. If you are on the CPU, remember to apply the inverse gamma correction. You probably want to do with a LUT with 256 entries that stores 16 bit integers with the fixed point representation of the de-gammaed value (mapping 8 bit to 8 bit would give you a loss of quality, for that point of storing images in gamma space is exactly to improve perceptual quantification quality).
You can find some reference live code here: https://www.shadertoy.com/view/XtsSzH
This observation applies to box blurring, gaussian blurring, image downsampling, sobel filters, and basically anything that is a linear combination of pixel values, but it can probably be best illustrated with this simple box blur pseudocode below.
Wrong way to do a box blur:
vec3 col = vec3(0.0);
for( int j=-w; j<=w; j++ )
for( int i=-w; i<=w; i++ )
{
col += src[x+i,y+j];
}
dst[x,y] = col / ((2*w+1)*(2*w+1));
Correct way to do a box blur:
vec3 col = vec3(0.0);
for( int j=-w; j<=w; j++ )
for( int i=-w; i<=w; i++ )
{
col += DeGamma( src[x+i,y+j] );
}
dst[x,y] = Gamma( col / ((2*w+1)*(2*w+1)) );
Here Gamma() and DeGamma() are the gamma correction function and its inverse. These can probably be just approximations, such as Gamma(x) = pow( x, 1.0/2.2 ) and DeGamma(x) = pow( x, 2.2 ), or even Gamma(x) = sqrt(x) and DeGamma(x) = x*x if you really want to save some cycles.
The image below shows on the left side the wrong (and most common) way to blur an image, and the right side shows the result of correct blurring. Note how the correct version does not get darker but retains the original overall intensity after blurring, unlike the one on the left. The effect is pretty obvious in the area where the bus is in the picture. The effect would be even more obvious if the correct and incorrect images were overlapping.
Left, gamma unaware blurring (too dark). Right, gamma correct blurring (correct brightness)
So, remember. If you are on the GPU, use sRGB for textures that contain photographics material and are ready to be displayed as they are. If you are on the CPU, remember to apply the inverse gamma correction. You probably want to do with a LUT with 256 entries that stores 16 bit integers with the fixed point representation of the de-gammaed value (mapping 8 bit to 8 bit would give you a loss of quality, for that point of storing images in gamma space is exactly to improve perceptual quantification quality).
You can find some reference live code here: https://www.shadertoy.com/view/XtsSzH