4 ms·

IMO the worst offenders are image shrinking features in many applications. Open this in your favorite browser/image viewer then shrink it to 50%: http://www.4p

by leni536 11y ago

IMO the worst offenders are image shrinking features in many applications. Open this in your favorite browser/image viewer then shrink it to 50%: http://www.4p8.com/eric.brasseur/gamma-1.0-or-2.2.png http://www.4p8.com/eric.brasseur/gamma-1.0-or-2.2.png I tested it right now in chromium 46 and it still doesn't scale it correctly. Last time I checked Firefox doesn't do it better. An other good article about this problem: http://www.4p8.com/eric.brasseur/gamma.html http://www.4p8.com/eric.brasseur/gamma.html There are other areas where this becomes apparent, such as physical lighting models where it only makes sense to use a linear colorspace. Is there a type safe library to handle colors well (like having separate types for "compressed" and "linear" color values)? I think that could mitigate most of these problems caused by naive implementations.

jacobolus 11y ago
A tricky thing w/r/t browsers is that they are often really crappy at figuring out what color space a PNG image is supposed to be in. I think they often intentionally strip out the color space info from PNG images for the sake of helping PNG images blend smoothly into CSS / Flash / etc., for which they also don’t do correct color management. [The CSS spec says that colors should be interpreted as sRGB, but browsers don’t actually follow the spec.] As a result of this problem, it’s difficult to judge whether image resizing specifically is being done incorrectly, or whether the image is just being interpreted incorrectly at any size. You’ll notice if you open your first test image (http://www.4p8.com/eric.brasseur/gamma-1.0-or-2.2.png http://www.4p8.com/eric.brasseur/gamma-1.0-or-2.2.png) in Apple’s Preview app, you get the correct behavior, but this is different from the behavior in Safari, for example, which shows something incorrect at every size. Stranger still, the behavior in Safari is roughly “correct” while resizing a browser window, but as soon as you let go of the mouse, it reverts to being incorrect. There are multiple possible ways to embed color space info into PNG images, and the PNG spec is actually really terrible and confusing on this subject which results in lots of inconsistencies from one implementation to another. If I remember correctly some of them are treated better by browsers than others, but I’m not sure if there’s a way to encode images such that it will be handled properly everywhere (I mean, handled correctly even at 100% size, without any resizing). I’m not an expert on browser image rendering though. cf. e.g. https://hsivonen.fi/png-gamma/ https://hsivonen.fi/png-gamma/ or for a more general browser color rant cf. http://regex.info/blog/photo-tech/color-spaces-page1 http://regex.info/blog/photo-tech/color-spaces-page1 * * * One particularly annoying thing about gamma and image rendering is that all font and vector graphics rendering in pretty much all software (Illustrator, Inkscape, Cairo, Quartz, browsers, etc.) is implicitly done (incorrectly) in gamma-encoded space rather than linear space. This causes vector graphics with thin lines to change dramatically in appearance as you scale them up or down, but no implementation is able to fix their behavior and do the right thing because all content (e.g. small text rendering) in that renderer will suddenly look “wrong”.
- vanderZwan 11y ago
  Regarding your last point, that's another reason to hope hardware accelerated path rendering gets adopted ASAP: https://www.youtube.com/watch?v=yN6eyFYDMkg&t=11m4s https://www.youtube.com/watch?v=yN6eyFYDMkg&t=11m4s (I know this is not exactly the same visual bug, but generally speaking Mark Kilgard & Co. seem to have done their homework and really implemented the specs properly) The other reasons being that it's faster and more energy-efficient.
  - jacobolus 11y ago
    Have you seen this work? http://w3.impa.br/~diego/projects/GanEtAl14/ http://w3.impa.br/~diego/projects/GanEtAl14/
    - vanderZwan 11y ago
      Nope, thanks for the link!
MrBuddyCasino 11y ago
OSX, Chrome 46 - apparently their scaling "Rules", though I'm not sure if a 100%, the "Sucks" is still faintly visible.
sika_grr 11y ago
Can anyone explain the gradient merging example? If we sum an image in which luminosity is linearly rising from left to right with the image in which the luminosity is linearly rising from top to bottom, then the result should have constant luminosity across bottom left - top right diagonal. So we shouldn't see a circle effect in the top left corner, but rather a rotation of first gradient by +45 degrees. Or are the gradients not linear in luminosity? Or are you guys not seeing the circle effect? It does looks quite different on my other monitor, but I can still clearly see a circle instead of topleft-bottomright linear drop in luminosity on the left example.
- leni536 11y ago
  I see a circle effect in the "correct" merge and don't see one in the "incorrect" merge. My guess is that the gradient is linear in sRGB values, so if you merge in sRGB space (incorrectly) then you get a rotated, sRGB space linear gradient.
  - sika_grr 11y ago
    Yea, I guess that also explains why gradients don't look that smooth.
ashmud 11y ago
This was previously discussed here: https://news.ycombinator.com/item?id=8207271 https://news.ycombinator.com/item?id=8207271

by leni536 11y ago

jacobolus 11y ago

A tricky thing w/r/t browsers is that they are often really crappy at figuring out what color space a PNG image is supposed to be in. I think they often intentionally strip out the color space info from PNG images for the sake of helping PNG images blend smoothly into CSS / Flash / etc., for which they also don’t do correct color management. [The CSS spec says that colors should be interpreted as sRGB, but browsers don’t actually follow the spec.] As a result of this problem, it’s difficult to judge whether image resizing specifically is being done incorrectly, or whether the image is just being interpreted incorrectly at any size. You’ll notice if you open your first test image (http://www.4p8.com/eric.brasseur/gamma-1.0-or-2.2.png http://www.4p8.com/eric.brasseur/gamma-1.0-or-2.2.png) in Apple’s Preview app, you get the correct behavior, but this is different from the behavior in Safari, for example, which shows something incorrect at every size. Stranger still, the behavior in Safari is roughly “correct” while resizing a browser window, but as soon as you let go of the mouse, it reverts to being incorrect. There are multiple possible ways to embed color space info into PNG images, and the PNG spec is actually really terrible and confusing on this subject which results in lots of inconsistencies from one implementation to another. If I remember correctly some of them are treated better by browsers than others, but I’m not sure if there’s a way to encode images such that it will be handled properly everywhere (I mean, handled correctly even at 100% size, without any resizing). I’m not an expert on browser image rendering though. cf. e.g. https://hsivonen.fi/png-gamma/ https://hsivonen.fi/png-gamma/ or for a more general browser color rant cf. http://regex.info/blog/photo-tech/color-spaces-page1 http://regex.info/blog/photo-tech/color-spaces-page1 * * * One particularly annoying thing about gamma and image rendering is that all font and vector graphics rendering in pretty much all software (Illustrator, Inkscape, Cairo, Quartz, browsers, etc.) is implicitly done (incorrectly) in gamma-encoded space rather than linear space. This causes vector graphics with thin lines to change dramatically in appearance as you scale them up or down, but no implementation is able to fix their behavior and do the right thing because all content (e.g. small text rendering) in that renderer will suddenly look “wrong”.

vanderZwan 11y ago
Regarding your last point, that's another reason to hope hardware accelerated path rendering gets adopted ASAP: https://www.youtube.com/watch?v=yN6eyFYDMkg&t=11m4s https://www.youtube.com/watch?v=yN6eyFYDMkg&t=11m4s (I know this is not exactly the same visual bug, but generally speaking Mark Kilgard & Co. seem to have done their homework and really implemented the specs properly) The other reasons being that it's faster and more energy-efficient.
- jacobolus 11y ago
  Have you seen this work? http://w3.impa.br/~diego/projects/GanEtAl14/ http://w3.impa.br/~diego/projects/GanEtAl14/
  - vanderZwan 11y ago
    Nope, thanks for the link!

MrBuddyCasino 11y ago

OSX, Chrome 46 - apparently their scaling "Rules", though I'm not sure if a 100%, the "Sucks" is still faintly visible.

sika_grr 11y ago

Can anyone explain the gradient merging example? If we sum an image in which luminosity is linearly rising from left to right with the image in which the luminosity is linearly rising from top to bottom, then the result should have constant luminosity across bottom left - top right diagonal. So we shouldn't see a circle effect in the top left corner, but rather a rotation of first gradient by +45 degrees. Or are the gradients not linear in luminosity? Or are you guys not seeing the circle effect? It does looks quite different on my other monitor, but I can still clearly see a circle instead of topleft-bottomright linear drop in luminosity on the left example.

leni536 11y ago
I see a circle effect in the "correct" merge and don't see one in the "incorrect" merge. My guess is that the gradient is linear in sRGB values, so if you merge in sRGB space (incorrectly) then you get a rotated, sRGB space linear gradient.
- sika_grr 11y ago
  Yea, I guess that also explains why gradients don't look that smooth.

ashmud 11y ago

This was previously discussed here: https://news.ycombinator.com/item?id=8207271 https://news.ycombinator.com/item?id=8207271