6 ms·

I'm not an expert, but I've dealt with my share of this working in film. Color problems in image processing are everywhere. Pre-multiplication and Alpha chann

by pfranz 8y ago

I'm not an expert, but I've dealt with my share of this working in film. Color problems in image processing are everywhere. Pre-multiplication and Alpha channels are another huge one. A lot of professionals don't even understand it and will brute-force compensate for problems instead of understanding the problem. Here's a posting from this week [1] from professionals who care about getting this stuff right trying to convert a tiff to jpeg without surprise colors shifts. A summary is that you need to do almost all image modifications in a linear color space. So you first need to back out any color tweaks made (for aesthetic or technical reasons), modify the image, then re-apply any tweaks. Unfortunately, image files often aren't tagged with their color space and might use a specific color space out of convention--but they could use something else. Also, because it's way harder to do the right thing, a lot of software just does the modifications ignoring color space. Just think about how much slower and more memory a web page full of thumbnails would take to draw if you added in color space transformations? For awhile, a lot of browsers added support but left them off by default (imagine if you designed your web page to look right in a broken color space and it was suddenly much slower and now looked wrong). But a lot of software is slowly catching up. Unfortunately, legacy software (like Photoshop) and legacy file formats might never change. [1] http://lists.openimageio.org/pipermail/oiio-dev-openimageio.org/2019-January/001390.html http://lists.openimageio.org/pipermail/oiio-dev-openimageio....

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 ago
  I 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 ago
    sRGB 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 ago
      That's an interesting point. The GPU should do the resizing too if they're using it.
    - baybal2 8y ago
      The 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 ago
        Those 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 ago
  Going 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 ago
    Lookup tables are cache killers on modern CPUs. Arithmetic is often faster.
    - burfog 8y ago
      It'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 ago
        Oh, the lookup tables are cached just fine. It's just that they crowd out something else.
        burfog 8y ago
        That "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 ago
        You'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.
lstamour 8y ago
I first saw this post in 2009 or so, and it was eye-opening. I found it while googling for why colours shifted when I resized images, as back then there wasn't much awareness of this issue. But it's much less prevalent now. Related -- scaling algorithms: https://en.wikipedia.org/wiki/Image_scaling#Algorithms https://en.wikipedia.org/wiki/Image_scaling#Algorithms You don't often find browsers disagreeing in 2019 on how to render things, but image colour -- even on the same MacOS (retina) platform -- appear to be one of those things they disagree on still: https://content.screencast.com/users/LouisStAmour/folders/Snagit/media/5089fccd-17f6-4220-9922-91a022838115/2019-01-03_20-37-12.png https://content.screencast.com/users/LouisStAmour/folders/Sn... Safari on the left, Firefox in the middle and Chrome on the right. So you can try it for yourself, the test page is at http://www.ericbrasseur.org/gamma_dalai_lama.html http://www.ericbrasseur.org/gamma_dalai_lama.html If this isn't esoteric enough, I know of at least one major broadcast media company (Bell's crave.ca) that doesn't properly encode their HDTV 720p videos in MP4 to flag to the browser they're in Rec 709 colour space, and so the compression artifacts, designed to be invisible in Rec 709 are extremely visible on a wide gamut P3 display. Of course, these flags were only recently respected on all platforms. Chrome on Windows as of Oct 2016: https://bugs.chromium.org/p/chromium/issues/detail?id=655417#c18 https://bugs.chromium.org/p/chromium/issues/detail?id=655417... and Firefox (err, actually still not fixed, it depends on the codec...) https://bugzilla.mozilla.org/show_bug.cgi?id=1300170#c87 https://bugzilla.mozilla.org/show_bug.cgi?id=1300170#c87 But colour space is increasingly something you have to pay attention to, as displays improve beyond sRGB -- yet ironically, it's also getting easier to ignore as the latest stepping stone towards Rec 2020, the DCI-P3 colour space, is shared between PC and movie industries. https://en.wikipedia.org/wiki/DCI-P3#2015-2016 https://en.wikipedia.org/wiki/DCI-P3#2015-2016 (Personally I refuse to buy any display or device that plays back video if it doesn't have a P3 display, ideally OLED) FYI, you can test for colour gamut device support with CSS to serve wide-gamut colours -- but oddly enough, again, no Firefox support. :( https://developer.mozilla.org/en-US/docs/Web/CSS/@media/color-gamut https://developer.mozilla.org/en-US/docs/Web/CSS/@media/colo... FF bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1422237 https://bugzilla.mozilla.org/show_bug.cgi?id=1422237
- jacobolus 8y ago
  > back then [in 2009] there wasn't much awareness of this issue I haven’t noticed too much change in the general awareness of this problem between the 1990s and today. Experts have always known the right thing to do and people have been talking about these problems as long as there has been image processing, (e.g. Poynton’s Gamma FAQ dates from sometime before 1998 http://poynton.ca/notes/colour_and_gamma/GammaFAQ.html http://poynton.ca/notes/colour_and_gamma/GammaFAQ.html) but it’s new to everyone at some point, and newcomers perennially screw up. The annoying thing is that there are folks who continue to screw up (like Adobe Photoshop) who should really know better. Backwards compatibility shouldn’t be an excuse to continue with broken implementations for decades.
ZenPsycho 8y ago
FYI You can get gamma correct resizing (and other operations) in recent versions of photoshop by first switching the image to 32-bit colour depth mode.
- pfranz 8y ago
  I had a really long reply typed up with some specific workflow problems. But you can see people complain elsewhere in this thread about how Adobe handles stuff like this. The basic problem is that the color space for blending is an application setting (can't be specified in the file) and higher bit depths will double or triple your file size.

by pfranz 8y ago

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 ago
I 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 ago
  sRGB 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 ago
    That's an interesting point. The GPU should do the resizing too if they're using it.
  - baybal2 8y ago
    The 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 ago
      Those 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 ago
Going 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 ago
  Lookup tables are cache killers on modern CPUs. Arithmetic is often faster.
  - burfog 8y ago
    It'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 ago
      Oh, the lookup tables are cached just fine. It's just that they crowd out something else.
      - burfog 8y ago
        That "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 ago
        You'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.

lstamour 8y ago

I first saw this post in 2009 or so, and it was eye-opening. I found it while googling for why colours shifted when I resized images, as back then there wasn't much awareness of this issue. But it's much less prevalent now. Related -- scaling algorithms: https://en.wikipedia.org/wiki/Image_scaling#Algorithms https://en.wikipedia.org/wiki/Image_scaling#Algorithms You don't often find browsers disagreeing in 2019 on how to render things, but image colour -- even on the same MacOS (retina) platform -- appear to be one of those things they disagree on still: https://content.screencast.com/users/LouisStAmour/folders/Snagit/media/5089fccd-17f6-4220-9922-91a022838115/2019-01-03_20-37-12.png https://content.screencast.com/users/LouisStAmour/folders/Sn... Safari on the left, Firefox in the middle and Chrome on the right. So you can try it for yourself, the test page is at http://www.ericbrasseur.org/gamma_dalai_lama.html http://www.ericbrasseur.org/gamma_dalai_lama.html If this isn't esoteric enough, I know of at least one major broadcast media company (Bell's crave.ca) that doesn't properly encode their HDTV 720p videos in MP4 to flag to the browser they're in Rec 709 colour space, and so the compression artifacts, designed to be invisible in Rec 709 are extremely visible on a wide gamut P3 display. Of course, these flags were only recently respected on all platforms. Chrome on Windows as of Oct 2016: https://bugs.chromium.org/p/chromium/issues/detail?id=655417#c18 https://bugs.chromium.org/p/chromium/issues/detail?id=655417... and Firefox (err, actually still not fixed, it depends on the codec...) https://bugzilla.mozilla.org/show_bug.cgi?id=1300170#c87 https://bugzilla.mozilla.org/show_bug.cgi?id=1300170#c87 But colour space is increasingly something you have to pay attention to, as displays improve beyond sRGB -- yet ironically, it's also getting easier to ignore as the latest stepping stone towards Rec 2020, the DCI-P3 colour space, is shared between PC and movie industries. https://en.wikipedia.org/wiki/DCI-P3#2015-2016 https://en.wikipedia.org/wiki/DCI-P3#2015-2016 (Personally I refuse to buy any display or device that plays back video if it doesn't have a P3 display, ideally OLED) FYI, you can test for colour gamut device support with CSS to serve wide-gamut colours -- but oddly enough, again, no Firefox support. :( https://developer.mozilla.org/en-US/docs/Web/CSS/@media/color-gamut https://developer.mozilla.org/en-US/docs/Web/CSS/@media/colo... FF bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1422237 https://bugzilla.mozilla.org/show_bug.cgi?id=1422237

jacobolus 8y ago
> back then [in 2009] there wasn't much awareness of this issue I haven’t noticed too much change in the general awareness of this problem between the 1990s and today. Experts have always known the right thing to do and people have been talking about these problems as long as there has been image processing, (e.g. Poynton’s Gamma FAQ dates from sometime before 1998 http://poynton.ca/notes/colour_and_gamma/GammaFAQ.html http://poynton.ca/notes/colour_and_gamma/GammaFAQ.html) but it’s new to everyone at some point, and newcomers perennially screw up. The annoying thing is that there are folks who continue to screw up (like Adobe Photoshop) who should really know better. Backwards compatibility shouldn’t be an excuse to continue with broken implementations for decades.

ZenPsycho 8y ago

FYI You can get gamma correct resizing (and other operations) in recent versions of photoshop by first switching the image to 32-bit colour depth mode.

pfranz 8y ago
I had a really long reply typed up with some specific workflow problems. But you can see people complain elsewhere in this thread about how Adobe handles stuff like this. The basic problem is that the color space for blending is an application setting (can't be specified in the file) and higher bit depths will double or triple your file size.