We know that in PNG,BMP,etc... the pixel value stored is not in the linear RGB space. But I found no document saying anything about the alpha channel. Is the alpha channel stored in image files in linear space or not?
$\begingroup$
$\endgroup$
Add a comment
|
3 Answers
$\begingroup$
$\endgroup$
We know that in PNG,BMP,etc... the pixel value stored is not in the linear RGB space.
This is not necessarily true. You can store whatever color space you want into an image, it doesn't even need to be colors (such as normal maps).
The alpha channel is generally linear. The alpha channel doesn't get displayed, but it is generally a non-color term used for transparency (or whatever else). Because they don't need to display on a monitor, there's no reason to store in in gamma space. If you did, you would unnecessarily lose precision at the lower end of the alpha values. Normals maps follow a similar line of reasoning, as explained very well by Julien Guertault.
$\begingroup$
$\endgroup$
Image file formats themselves do not regard the gamma but store pixel values unmodified as the authoring program (e.g. Photoshop) decides to store the values, so RGB and alpha channels have no distinction from image file format point of view (barring potential lossy compression strategies, but that's another topic).
However, when you author images in Photoshop, they are displayed on the screen in sRGB space including the alpha channel, so if you author alpha channel relying that the perceived brightness of pixels represents transparency, then you can say that alpha is also stored in the gamma space. BUT, if you author alpha by using layer transparency in Photoshop, then the alpha is stored linearly (e.g. 50% transparent layer is stored as alpha=128).
So in the end it depends how you author the data that in which space the data is stored and how you should interpret it. Also a thing to consider is if non-linear distribution of values gives you any precision benefits. Color values are stored in sRGB because human visual system responds logarithmically to light brightness, so it makes sense to have more details in darks than in brights to reduce perceived banding, but you could ask if such distribution would benefit say normal maps or roughness values stored in textures.
$\begingroup$
$\endgroup$
2
Keeping alpha linear makes it unbiased towards source and destination color. It should not be gamma corrected, because it should not have been subjected to sRGB-encoding.
A specialized application could of course ignore this, for example to get more control over the change in perceived brightness during a blending operation of a bright source color over a dark destination color (assuming alpha is stored in a byte with range 0-255 - which is how sRGB is commonly stored these days for the purpose of data compression - where you can only change the alpha in big steps).
I might add that 8 bit for linear alpha is actually very low resolution. Blending white over black with alpha 1/255 (the smallest non-zero alpha) yields sRGB values 13, 13, 13 when you do the math properly in linear RGB, possibly leading to all sorts of banding and aliasing artifacts. A lot of widespread image editing software is surprisingly inept at offering means for dealing with this.
What I mostly do now is to take whatever alpha my image editing software spits out and apply smooth-stepping like so:
f := float32(alpha) / 255
return (1-f)*f*f + f*(1-(1-f)*(1-f))
This essentially is a hack which balances:
- Banding artifacts in low-alpha dark-over-bright and bright-over-dark blending scenarios.
- Lossiness in white-over-black alpha-gradients.
- Staying close to the original curve.
If the result looks bad, I will usually do some over-correcting in the image instead of in the math. The math is a lost battle due to graphics software doing whatever.
Interpolation artifacts (which are often brought up as a reason for doing alpha pre-multiplication) can be remedied by giving color to pixels with zero alpha which neighbor pixels with non-zero alpha, which is a task best automated with software.
