Re:Gamma error in picture scaling (2007)
by kevin_thibedeau on Thursday August 21, 2014 @11:59AM
(#8207989)
This is not really a Gamma correction issue (although gamma shouldn't be ignored for other reasons). It is the result of attenutation of high frequency information close to the Nyquist rate (1 pixel wide details) when downsampling. The applied gamma is adding emphasis to these high frequency details so that they survive the anti-aliasing filter and downsampling process.
[ Parent
| on HN ]
No, the gamma compression distorts high-frequency components that have close frequencies f1 and f2 into products such as the low-frequency f1-f2. The reason you don't see this low frequency on your screen is that the inverse gamma curve on your display undoes this distortion exactly. But if you remove the high frequencies f1 and f2 by downsampling before displaying, the only remaining signal is f1-f2, and because of the lack of high frequencies it isn't removed by the inverse gamma curve. So you're left with a visible low frequency signal.
And f1 and f2 don't need to be close to Nyquist, as long as they're significantly attenuated by the downsampling filter.
Re:Gamma error in picture scaling (2007)
by phaedrus on Thursday August 21, 2014 @02:31PM
(#8208867)
You didn't understand the article. Read his cannonballs analogy. The problem is the formula used to average colors is wrong in most software. The problem is most software is averaging the numeral values of the RGB component when it it should be averaging the light output intensity, which is not linear to the RGB numeral values.
More specifically any addition of color values generates the problem, not just averaging. If you add two linear values and gamma-correct the result, you get a different answer than if you added the gamma-corrected values directly. Multiplication doesn't have the same problem. I.E. a^x+b^x != (a+b)^x, while a^xb^x == (ab)^x. P.S. it has nothing to do with Nyquist limits.
No, this is a gamma correction issue.
Software which work in full-float linear (Nuke, for example) don't have this issue, as the RGB values are already in luminance-adjusted values as they're linear.
The issue only affects software filtering images in lower-precision (and thus gamma-baked) pixel intensity values - i.e. 0-255 for uchar (8-bit) and 0- for ushort (16-bit), where the R,G and B channels are given equal weighting).
I just added the gamma conversion change to my resampling library. It made a definite improvement in accuracy, especially to astronomy images. Before most details shifted towards being darker, but now they appear to retain their luminosity better.