Greetings fellow Nim adventurers! Below you will find 16 handy Nim tips & tricks I came across while developing a medium-sized GUI program this year, Gridmonger (and related libraries). Some of them are about less known or undocumented Nim features or standard library functions, a few are workarounds for some rough edges of the language, and there’s also a handful of useful techniques I read about in forums or have invented on my own.
Looks like you missed all the other artifacts I gave examples for, which are all calibration independent (colour blending, compositing, rendering etc.)
The explanation of why there this kind of gamma mapping was introduced in the first place is inaccurate. An often cited explanation is the nonlinear sensual response of human vision; if you wanted to accurately model that you'd need a logarithmic mapping. The true reason for the need of gamma correction is the nonlinear behaviour of certain kinds of image sensors and display devices. CRT displays, be the very physics they are based on have an inherent nonlinearity that's approximated by a gamma=2.2. When LCDs got introduced they of course were made to approximate the behaviour of CRT displays, so that you could substitute them without further ado.
Another important aspect to consider is, that using just gamma is not the most efficient way to distribute the bits. You want a logarithmic mapping for that; which also has the nice side effect, that a power law gamma value ends up as a constant scaling factor to the logarithmic values.
Now, it's also important to understand that these days the bread-and-butter colorspace is sRGB and that complicates things. sRGB has the somewhat inconvenient property that for the lower range of values its actually _linear_ and only after a certain threshold it continues (differentiable) with a power law curve. That's kind of annoying, because with that you no longer can remap logarithmically. And of course converting from and to sRGB can be a bit annoying because of that threshold value; you certainly can no longer write it as a convenient one-liner in a GPU shader for example. That's why modern OpenGL profiles also have special sRGB framebuffer and image formats and reading from and writing to them will perform the right linearization-mapping.
However either way what the explanation for gamma is, the important takeaway is, that to properly do image processing the values have to be converted into a linear color space for things to work nicely. Ideally a linear contact color space.
Yes, we need greater precision, ideally floats, but maybe 16 bits would be enough (haven't tested this or thought much about it.) But for multiple passes of processing floats are definitely the way to go due to rounding errors. I don't think you'd get worse performance when using floats on current hardware.
I highly doubt you perceive light intensity radically differently to your fellow humans... :) Most likely your monitor is miscalibrated.
Try a few different gamma calibration images from other sources (Google Images -> "gamma calibration") and if they consistently indicate that your monitor is miscalibrated, then you have your answer.
I have the same problem as the GP, on four monitors. All four, bought at different times in different countries, are miscalibrated according to these calibration images. Is that plausible? If not, what might be going on?
And if it _is_ plausible that four random monitors are all miscalibrated in the same way, why should we optimize for well-calibrated monitors?
If you read the article carefully, you'll realise that this is not just an optimisation (check for example the sections on colour blending and rendering; those artifacts are gamma calibration independent.)
Thanks, I'm glad you enjoyed the article. The only way I could get Photoshop to resize correctly was to convert the image to 32-bit first, do the resizing, then convert back to 8/16-bit (there might other simpler ways, though, but this is guaranteed to work). The image description actually describes this process.
