Hacker News new | ask | show | jobs
by leni536 3426 days ago
My acid test for image scaling software:

http://i.imgur.com/X9vKa2s.png

https://i.scaley.io/png-256x128/i.imgur.com/X9vKa2s.png

This means that you don't use a linear color space for blending colors.

Sorry about the language, the image is not made by me [1].

[1] https://web.archive.org/web/20120904060524/http://www.4p8.co...

edit:

I see that your backend relies on libvips to do the resizing. I have no experience with it, but I could make libvips-tools' vipsthumbnail program work correctly:

  $ vipsthumbnail --linear -f tn_%s.png -s 256x128 gamma-1.0-or-2.2.png
Note the "--linear" option, without it produces the same wrong image.
5 comments

I didn't think this would come up so quickly! This can actually be fixed with an undocumented option 'gamma'[1]

I didn't include it in the website, admittedly because I didn't fully understand it, and I wanted to keep the service as simple as possible.

Would it make sense for this to be the default?

[1] https://i.scaley.io/png-gamma-256x128/i.imgur.com/X9vKa2s.pn...

Nice! I think it should be the default. Some software might treats as a compromise between correctness and cost (doing the rescaling in linear space is usually more costly). In my view it should be correctness first.

The ImageWorsener's website as an excellent reading material on image resizing and other transformations. ImageWorsener is a "correctness first" image resizing software.

http://entropymine.com/imageworsener/

"Correctness" is not very useful in image processing, it's all about perception and performance.
Well "correct" in the case of linear vs non-linear luminance is pretty much exactly about perception (or at the very least, working to prevent perception differences further down the pipeline), even if it is a somewhat minor effect.

"The Importance of Being Linear"[1] which just came up on HN a few days ago, discusses some issues with non-linearity, specifically in the context of 3D rendering.

[1] - http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html

There are lots of specific examples where incorrectness leads to perceptually significant problems. I'd agree that you don't normally notice it in the wild, which is why so much software has gotten away with it for so long.

It is possible to optimize the linearization steps so that they don't detract too much from the performance, especially if you're using one of the better (i.e. slower) interpolation methods.

This page[1] documents some effects of gamma-incorrect resizing. Specifically, check out Figure 12.

[1] http://blog.johnnovak.net/2016/09/21/what-every-coder-should...

Thanks for your detailed feedback on this, I appreciate it!
Averaging two RGB numbers isn't at all similar to how the human eye averages two colours.

The colour experts have a variety of ways to do much better, almost any of them will give you much better results. Pick one and be done. Your undocumented -gamma- option is fine.

If you want the best option you should be prepared to invest a lot of time and attention, in return for which you'll get a result that's perhaps a little better than your -gamma- and a lot better than plain RGB averaging.

Can you elaborate on how colors should be blended?

Is it about the choice of interpolation algorithm? nearest neighborhood vs linear vs cubic, etc

I've written image processing code in the past, though color accuracy wasn't important to it, and I'm curious to understand this better.

I also currently use ImageOptim and would be curious to know if it handles this.

Disclaimer: I'm not an expert in this field.

I define "color" as a visual perception of a spacially homogenous electromagnetic spectra. Notation: c=p(s), meaning color is a perception of a given spectra. It turns out, that these percieved colors form a three dimensional vector space, this vector space is the representation of the infinite dimension vector space of electromagnetic spectras (c_i=p(s_i), p(a * c)=a * p(c), p(c1+c2)=p(c1)+p(c2) ).

We can parametrize this vector space with three numbers. If these numbers are coefficients of a linear system in these space, then we call this parametrization a "linear colorspace". Then physical blending of different spectra results in the same blending in coefficients.

Often we don't use this kind of parametrization (most often sRGB on the web), because perceptual distance is not linear in a linear colorspace, so we can get away with 8 bits per color channel to not introduce obvious banding in the darker regions.

Blending problems occur if someone doesn't know if the three numbers representing a color accually is a member of an actual vector space or not. Nobody would attemt to use the same algorithm in HSV tö blend.

This image is awesome. Thank you for linking it. I'll have to keep it around to test whenever I write resizing code.
Karen handles this PNG reasonably well! https://dl.kraken.io/web/b1c01b1fa0a9b938bea45d8accd0db48/X9...

At the same time shaved off 46% of the size (from 4.02 KB to 2.16 KB)

Wow, TIL. I had never realized that luminosity doesn't scale linearly. Awesome post.
Unfortunately we have evolved for wildlife survival, not mathematical simplicity ;) We're very nonlinear in the hearing department too!