4 ms·
You could do a rough approximation of gamma correction with squares and square roots, which wouldn't add to the processing time like a full sRGB conversion woul
by mark-r 8y ago
You could do a rough approximation of gamma correction with squares and square roots, which wouldn't add to the processing time like a full sRGB conversion would.
- mark-r 8y agoI had this idea a long time ago but never actually tested it. Now I have: http://marksblog.com/gamma-resize/ http://marksblog.com/gamma-resize/. The square/sqrt method gets at least 80% of the quality but should be quick to compute on a modern processor.
- jacobolus 8y agosRGB gamma encode/decode is a natively provided hardware feature on GPUs, and is plenty fast. There’s really no excuse in 2019.
- mark-r 8y agoThat's an interesting point. The GPU should do the resizing too if they're using it.
- baybal2 8y agoThe irony is that all accelerated hardware resizers available on ARM SoCs that I know are also not gamma aware. This is why downscaled videos feel to have more contrast, or solarised due to bruteforce compensation on most Android devices.
- AstralStorm 8y agoThose LUT or power or logarithm functions are not free... linear light scaling is about 2x slower in practice. Not that it matters until you get to 8K.
- burfog 8y agoGoing from 8-bit sRGB channels to 32-bit IEEE float channels is a simple lookup in a table with 256 values. Going the other way is only slightly harder. Scale to the range 0 ... 4095, properly round the float to an integer, verify the range or mask with 0xfff to protect against NaN and Inf, and then to a table lookup in a table with 4096 values. Tux Paint contains GPL code for it. It's been there for more than a decade. All you GIMP and Photoshop users having trouble with this should have been using Tux Paint. :-)
- mark-r 8y agoLookup tables are cache killers on modern CPUs. Arithmetic is often faster.
- burfog 8y agoIt's 5120 bytes for the both of them, the access is not at all random (due to color popularity), and the real cache killer is the image itself. You're dealing with a few megabytes for the image.
- mark-r 8y agoOh, the lookup tables are cached just fine. It's just that they crowd out something else.
- burfog 8y agoThat "something else" is already crowded out by running through a multi-megabyte image. At least the instruction cache is barely affected, which would not be the case for a math library function.
- AstralStorm 8y agoYou're not running a multi MB image but a small block thereof. Not that 5-6KiB LUT matters, but the extra conditional multiply ops or power or logarithm function evaluations do. Latter are need a few MACs for a good approximation (at least 12 bit precise, preferably 16 bit - like 5th order polynomial), former have masks, worse for SIMD.