Slashdot Mirror
Scaling Algorithm Bug In Gimp, Photoshop, Others
Wescotte writes "There is an important error in most photography scaling algorithms. All software tested has the problem: The Gimp, Adobe Photoshop, CinePaint, Nip2, ImageMagick, GQview, Eye of Gnome, Paint, and Krita. The problem exists across three different operating systems: Linux, Mac OS X, and Windows. (These exceptions have subsequently been reported — this software does not suffer from the problem: the Netpbm toolkit for graphic manipulations, the developing GEGL toolkit, 32-bit encoded images in Photoshop CS3, the latest version of Image Analyzer, the image exporters in Aperture 1.5.6, the latest version of Rendera, Adobe Lightroom 1.4.1, Pixelmator for Mac OS X, Paint Shop Pro X2, and the Preview app in Mac OS X starting from version 10.6.) Photographs scaled with the affected software are degraded, because of incorrect algorithmic accounting for monitor gamma. The degradation is often faint, but probably most pictures contain at least an array where the degradation is clearly visible. I believe this has happened since the first versions of these programs, maybe 20 years ago."
The responses that they post are also inaccurate it seems.
From
meanwhile, I see a grey rectangle in firefox, and I still don't get what that signifies.
Gamma is often poorly understood even by people doing scientific and engineering work using images.
Does your algorithm depend (explicitly or implicitly) on the light intensity -> pixel data mapping?
If NO: You're probably wrong. Go read about gamma. Just because the picture looks right to you, doesn't mean it looks right to your code.
If YES:
Do you have the luxury of taking the pictures yourself?
If NO: You're stuffed. Pretty much all images on the internet and most public research databases have unknown/unreliable gamma curves.
If YES:
1. Spend a lot of time calibrating your camera yourself. This is only cheap if your time is worthless
or
2. Buy a machine vision camera. A $600 machine vision camera will have the specs of a $50 consumer camera, but at least you will know the gamma curve.
or
3. Ignore the gamma issue, cross your fingers, hope it's not hurting your performance, and publish your results knowing that you're in good company and nobody will call you out.
If you're a *serious* amateur photographer, then you should already know about this and not be using those apps / using them in the color modes (to use Photoshop parlance, as I guess most serious amateur photographers will have a copy (legit or otherwise of that)).
I guess the argument would hinge on who is a serious amateur photographer and who is just a regular amateur photographer.
As for the actual examples - sure, you can see the difference.. especially since they're in before/after -style swappable pages. If I presented you a random image off of a random image gallery online, though, would you be able to tell the difference?
If I showed you an online photo album and pointed at an image's thumbnail, had you click the thumbnail, and open up the full size image.. would you notice that it was scaled to thumbnail incorrectly?
"Nobody really cares" may have been too broad a statement - but those who really care, already know.. or reasonably should know.
imho.
Note that I'm not excusing the software programs from handling this better - certainly not Photoshop - but it's 1. not a new revelation and 2. certainly not a "scaling algorithm bug".
My software has been calculating in linear space for over a decade now (this is the Nuke Compositor currenlty produced by The Foundry but at the time it was used by Digital Domain for Titanic). You can see some pages I wrote on the effect here: http://mysite.verizon.net/~spitzak/conversion/composite.html. See here for the overall paper: http://mysite.verizon.net/~spitzak/conversion/index.html and a Siggraph paper on the conversion of such images here: http://mysite.verizon.net/~spitzak/conversion/sketches_0265.pdf, in fact a lot more work went into figuring out how to get such linear images to show on the screen on hardware of that era than on the obvious need to do the math in linear. Initial work on this was done for Apollo 13 as the problems with gamma were quite obvious when scaling images of small bright objects against the black of space.
For typical photographs the effect is not very visible in scaling, as the gamma curve is very close to a straight line for two close points and thus the result is not very much different. Only widely separated points (ie very high contrast images with sharp edges) will show a visible difference. This probably means you are trying to scale line art, there are screenshots in the html pages showing the results of this. Far worse errors can be found in lighting calculations and in filtering operations such as blur. At the time even the most expensive professional 3D renderers were doing lighting completely wrong, but things have gotten better now that they can use floating point intermediate images.
One big annoyance is that you better do the math in floating point. Even 16 bits is insufficient for linear light levels as the black points will be too far apart and visible (the space is wasted on many many more white levels than you ever would need). A logarithmic system is needed, and on modern hardware you might as well use IEEE floating point, or the ILM "half" standard for 16-bit floating point.
Yes, it depends on the colourspace you use for the resize. If you resize in a non-linear colourspace, you will get (usually) tiny errors.
I'm the author of one of the programs listed as defective (nip2). If you care about this issue, all you need to do is work in a linear space, such as XYZ (Click Colour / Colourspace / XYZ).
Talk about changing the goalposts! This whole Slashdot story is about fidelity.
Woah there. First of all, as a neutral party, I dislike both Apple and Microsoft (I use Linux), and I have no agenda here. However, I do think that your viewpoint (as a self-admitted print publisher) is highly biased and useless to the majority of slashdot readers. This slashdot story is about image editing, but this thread is about on-screen font rendering. The two topics are different, and they need different goalposts.
The technical ins and outs of photo editing and display are all about fidelity; why would that not be the case with typeface rendering and display?
Viewing a photo is very very different from reading text. In fact, I find it completely preposterous that anyone would regard the two things as having anything in common.
When I am reading text, I care about text fidelity, not image fidelity. I want to know what the letters and words are. I want to be able to read and re-read the text with minimal eyestrain. Unless you work in advertising or marketing (two industries which I loathe), the purpose of displaying or printing text is to accurately convey which letter is which and which word is which. Anything else (such as font accuracy) is only a means to this end. Anyone (such as you) who thinks font accuracy is worthy as an end in itself is clearly living in a different world from someone (such as me) who reads scientific papers (the vast majority of them on-screen, simply because carrying around 1GB worth of printed papers is impossible) and writes code for a living.
I'm no great lover of Apple products, but as someone in print and publishing, this is one thing Apple does right and everyone else refuses to.
There is a huge difference between printed text and text on a computer screen. The physical differences between the two are so vast, they can never be made to display exactly the same. I understand that, for someone like you who works in the publishing industry, it is important for computer screens to maintain fidelity to printed paper, since the printed paper is your end result. However, just because your profession depends crucially on font fidelity, does not mean that the same holds for other people.
You need to understand that text on a computer screen is not always intended for publication on a printed page. Computer programming, in particular, involves writing large amounts of textual code, code which is almost never printed. Many slashdot readers are computer programmers, and couldn't give a flying f*ck about printing out their source code on paper. In such a situation, it is counterproductive to insist on image-level fidelity between text displayed on a computer monitor and text printed on a paper page. In fact, the optimal display strategy for computer programmers is almost completely the opposite of what you are saying, namely: render the font on the computer monitor so that it is as readable as possible on a computer screen, with absolutely zero regard for fidelity to printed output.
Scenes intentionally filmed with judder that people go to great lengths to smooth out; proper calibration that is blown away by dynamic settings; sound mix and dynamic range that is hopelessly trampled by bass-loading equalizer fiends; photos being displayed in some other color space are all the same issue.
Ironically, text rendering is the one issue that is different from all of the above. Text is a discrete medium: a letter is either an a, b, or c, or so on. Photos, sound, and video are analog media, perceived along a continuum by the human brain. Text fidelity means only one thing: being able to tell letters apart.
If you were to print out Microsoft's rendered fonts in a novel, people would demand a reprint by the publisher. The objective reference is the superior reference.