Scaling Algorithm Bug In Gimp, Photoshop, Others 368
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."
Oh calm down.. (Score:4, Insightful)
Photographs scaled with the affected software are degraded, because of incorrect algorithmic accounting for monitor gamma.
Seriously!
I have a theory on why this has gone unnoticed for so long, but I'll keep it to myself...
Re: (Score:2)
I think it's because of his atrocious grammatical errors!
On this sheet of paper, the black laser printer ink dots bleeded in all directions.
Re: (Score:2, Informative)
Yes because everyone in the world who posts to the internet is a native English speaker.
Having read that I am willing to be English isn't his first language
Re: (Score:3, Funny)
Having read that I am willing to be English isn't his first language
I am willing to be Mavis Beacon.
Re: (Score:2)
Re:Oh calm down.. (Score:5, Funny)
He seems to take it seriously.
Probably a gamma nazi...
Re:It's already been discussed on Slashdot (Score:4, Insightful)
They summary already names a fix for Gimp (GEGL), but the posters only seem interested in whining instead of RTFS. Sigh.
Monitor gamma? (Score:2, Insightful)
To display the pictures, it makes sense to use the monitor gamma. But to actually modify the data using that information which is probably flawed in 99.9999999% of cases? That's just wrong.
Re: (Score:3, Interesting)
In some cases at least it seems like the primary purpose of scaling is to display the images immediately, in which case it seems like the gamma should be accounted for. For example, when browsers rescale images, it's an unexpected result if they change the perceived brightness while doing so--- shouldn't the browser's scaling be done in the same brightness space as the one it intends to use to display the images?
Re: (Score:2)
Yes, excepting that this issue is talking about the bug in image editors.
Re: (Score:2)
Yes, excepting that this issue is talking about the bug in image editors.
Keep reading the article; this problem exists in web browsers as well.
Re:Monitor gamma? (Score:5, Funny)
Excellent point. Just to be safe though, I'm going to take another look through my porn crypt to see if that's true.
BRB.
Re:Monitor gamma? (Score:5, Funny)
Well?
Re:Monitor gamma? (Score:5, Funny)
Well?
Somehow I don't think you've given him enough time.
Re: (Score:3, Insightful)
Re:Monitor gamma? (Score:4, Interesting)
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.
Re: (Score:2)
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.
The first one I have a hard time seeing it, but I can.
For the others have to scale the page to max to see anything other than a gray rectangle (using chrome)
Re: (Score:3, Insightful)
Here:
http://img43.imageshack.us/img43/2586/scalerbug.png [imageshack.us]
Look at the third set of images. Had this bug not been present, they should have been nearly identical. As you can see, in my case, they are radically different.
As the text reads:
(dali picture)
All four images in this page are the same one but your browser was instructed to scale it. The one below is scaled 1:2. On Opera and some versions of Internet Explorer it will show a gray rectangle. KDE Konqueror, Firefox and SeaMonkey will display it either pink
Re: (Score:2, Insightful)
meanwhile, I see a grey rectangle in firefox, and I still don't get what that signifies.
It means the scaling algorithm in your web browser and other commercial softwares is disastrously broken. Duh, didn't you RTFA?
Re:Monitor gamma? (Score:4, Informative)
IMO, what it actually means is that the so-called image is deliberately designed to be as catastrophically horrible as possible when scaled down.
Yes, the image is designed to exploit the bug in way that makes it very obvious that the scaling is wrong, but no, the gray rectangle is not the correct solution. The problem is that the browser or the image application assumes that the brightness is stored on a linear scale, while in reality its stored exponential one. Thus when you scale things or apply other filters the brightness will be messed up. In real photos it will be less noticeable then here, but it will still happen.
The correct way would be to transform the image to a linear scale before applying the filter and then restoring it the exponential one for display. A simple example of how to do that in Gimp (using gausian blur instead of scale, but it is the same bug) would be this [seul.org]. The left image is the original from the article, the middle one is blur applied and the right one is applying a gamma of 0.5 to get it to a linear scale, then the blur and then a gamma 2 to restore it to its original scale. As you can easily see the right one looks like the left one, but blurred, while the middle one has no resemblance to the original, all the information got lost due to the bug. In practice you would need a higher bit depth to make this trick practical, as else you would end with banding artifacts.
Re:Monitor gamma? (Score:5, Informative)
meanwhile, I see a grey rectangle in firefox, and I still don't get what that signifies.
Right-click the image, then click view image. You'll see the image full-scale, like the first image. Scaling it down 50% shouldn't make it gray.
Re:Monitor gamma? (Score:5, Informative)
The data in the pictures is not linear data. It assumes that it will be displayed on a system that introduces a gamma of 2.2. (If your display system does not do that physically, it should correct for this.) That is, a gray 127 should not display as halfway between a white 255 and a black zero, in terms of light output. (It should *appear* halfway between them visually, because your eyes aren't linear — that's (part of) why gamma is in use in the first place.) So, a checkerboard pattern of white / black squares will have half the luminosity of the white squares. When scaling down, software will turn it into a bunch of gray pixels. But they should be gray pixels of value 186, not 127.
The page is not well written, but his example images make the issue very clear. It's not about your monitor gamma; it's about the "standard gamma" that all image files assume your monitor has.
Re: (Score:2)
Re:Monitor gamma? (Score:5, Informative)
Actually, any well-specified file format will specify the gamma. Not all allow you to set it per-file, but they do specify it. Normally this is a line in the spec that reads something like "color values use the sRGB color space" or similar — which specifies a gamma of 2.2 (roughly). And sRGB with it's nearly 2.2 gamma has become so standard that assuming anything else (in the absence of a clear spec) would be idiotic.
Re: (Score:3, Informative)
They did exactly that. It's called sRGB, and these days (nearly) all monitors claim to follow it. Some have better color than others, but they're all nominally sRGB. The ones that don't follow sRGB are well-specified as doing something else (and expensive), and purchased by people that know what to do with them. The (somewhat) arbitrary standard is a gamma of roughly 2.2. Monitors that don't produce that naturally fake it with software (in the monitor, not the computer).
The problem is that the computer
Re: (Score:3, Informative)
Re: (Score:2)
Linear data needs a lot more than 8 bits to work correctly. Most "raw" formats use 12 or more.
So I would think anything storing white as 255 is going to use a gamma curve and 127 is not 1/2 white but some darker value.
Re: (Score:2)
But the file formats don't specify this. The image from a camera will set gray 127 to pretty much half the number of photons hitting the sensor as white 255, won't it?
If I understood TFA correctly, the problem is that it won't.
Gamma and sRGB (Score:5, Insightful)
Most image files on your computer (BMP, JPG, PNG, etc.) are stored in the sRGB [wikipedia.org] color space. sRGB defines the use of a gamma curve, which is a nonlinear transformation applied to each of the components (R, G, and B). The issue here is that most scalers make the assumption that the components are linear, rather than try to process the gamma curve. While this does save processing time (undoing the gamma curve then redoing it), it does add some error, especially when the values being scaled are not near each other.
So does this matter? Well, in some pathological cases where there are repeated sharp boundaries (such as alternating black-white lines or fine checkerboard patterns), this would make a difference. This is because the linear average of the pixels (what most image scalers use) yields a different result than if the gamma value was taken into account. For most images (both photographic and computer generated), this shouldn't be a big problem. Most samples are close in value to other nearby samples, so the error resulting from the gamma curve is very small. Sparse light-dark transitions also wouldn't be noticeable as there would only be an error right on the boundary. Only when you exercise this case over a large area does it become obvious.
One final point: this gamma scaling effect would occur regardless of the actual scaling algorithm. Bilinear, bicubic, and sinc would all have the same issue. Nearest neighbor interpolation would be unaffected, but in these cases, the output would look far worse.
Re: (Score:3, Insightful)
makes us wonder how much we're missing. Little mistakes here and there...
Tux Paint has the code (Score:3, Informative)
The "magic" tools are done right. Scaling (for stamps) needs fixing.
It's GPL. Grab the code if you want it: rgblinear.c and rgblinear.h have what you need.
(and yes, the difference is very noticable for special-effect paint tools)
Re: (Score:2)
Re:Monitor gamma? (Score:5, Informative)
It seems crazy to me to embed a particular Gamma value into an image. ...In fact it seems so crazy I must be missing something. Am I?
The article actually touches on this point. The sensitivity of the human eye isn't linear. If you use a linear scale to store luminosity information for an image, you waste a lot of bit depth at high luminosities - the eye has difficulty distinguishing between very bright and very bright plus a little tiny bit. On the other hand, the eye is very good at telling the difference between very dark and black. You need a lot of finely-graduated steps at low luminosity or else your shadows get jaggy.
If you uniformly (linearly) space out luminosities on an 8-bit (256-shade) scale, you store a lot of uninteresting information at the high end, and lose out on visible detail at the low end. A scale with gamma of 2.2 (typical these days) fits a full twenty-eight grey values between 0 and 1 on our hypothetical linear scale. To maintain that kind of luminosity resolution (down where it matters), you'd have to store an extra five bits on your linear scale. An extra sixty percent costs.
Re: (Score:2, Informative)
Yes, you are missing something. Human perception isn't linear either. Twice the amount of light does not look twice as bright. Our eyes see differences between dark tones more clearly. The result is that we need many more dark tones than light tones for an "evenly" distributed tone curve (which is a tone curve where two neighboring light tones appear to be the same brightness difference as two neighboring dark colors). A physically linear gradient has the perceptual half tone shifted close to the black poin
Re: (Score:2)
What about Irfanview and Picasa? (Score:2)
Re: (Score:2)
I know this is /. and to say "RTFA" is kind of pointless, but, please, RTFA. There's a tweaked sample there for you to try. It will be obvious if you try their sample with whatever graphics program you want to use.
Re: (Score:3, Funny)
Re: (Score:2)
If you read the fine article, you'll see they give a sample image you can test against your applications. I tested Irfanview (4.25) and it appears to suffer from the problem. Haven't tried Picasa yet; don't have it installed.
Re:What about Irfanview and Picasa? (Score:4, Informative)
Re: (Score:3, Informative)
KDE's KolourPaint (MS Paint clone) gets it right! Yay KDE!
short version (Score:5, Informative)
Most scaling algorithms treat brightness as a linear space, so e.g. if you're doing downscaling to 1/2 the size in each dimension, collapse 4 pixels into 1 by setting the 1 pixel to the numerical average of the original 4 pixels. But, most images are displayed with an assumption that brightness is a nonlinear space, i.e. gamma > 1. Therefore, scaling changes the perceived brightness, an unexpected result.
Re: (Score:3, Informative)
Brightness by itself is not a function, so it can't be linear or nonlinear.
Displayed luminosity is a function of the data value in the image file, which is what the OP meant by brightness. And it most certainly can be linear or non-linear.
But then, I suppose you already knew that.
Re: (Score:3, Informative)
No, it's an algorithm that's just plain wrong. It's doing linear calculations on values that represent an exponential curve. It's a pretty big screw-up, made by almost everyone that designs resampling algorithms. Given that graphics people don't usually write software, it's not for them. People that try to blend colors 0 and 255 in software need to know that the result should be 186 and not 127.
This isn't really a bug (Score:4, Insightful)
This is only a bug depending on what you are doing with your final images. One of the things that annoys me is that many image manipulation programs do not actually explain the primitives they are using. The result can be a complete mess depending on what you are trying to accomplish. This article is an example of this effect.
If you want photo-realistic results, then you need to take Gamma into account. However, very few file formats specify the Gamma, the grey level, the white level, the black level or the colour space of the original image. The result is that the many imaging operations must be wrong, as they can never be accomplished the way intended. For the most part, no one cares. This person found an application where people care.
Re:This isn't really a bug (Score:5, Informative)
But most people who use images expect to look at them eventually. And most image files are meant to be viewed at gamma 2.2. (Printer drivers will at least approximately emulate a gamma of 2.2, and LCDs emulate it intentionally.) If you view the image at some other gamma, you don't see quite what was intended.
Another way of looking at it is that most standard image formats are stored with a nonlinear representation, and people who do math should realize that. For an untagged image, gamma=2.2 is a good bet. gamma=1.0 is a terrible bet.
Of course, if we really want our software to do a good job, then that software should be aware that specifying colors like #FF0000 isn't a good idea -- they look very different on different screens. What the user probably meant to do was specify a particular color, which means that the numbers need to be marked with a color space. (For a great demo, get an HP LP2475w or some other good wide-gamut display, don't install a profile, and look at anyone's photo album. Everyone looks freakishly red-faced.)
Re: (Score:3, Insightful)
Well if it's a 20 year old bug, it should be renamed to a feature and patented. "Method to produce photo realistic scaling without taking gamma into account."
Re: (Score:3, Insightful)
I'm a cartoonist who runs a web comic, and I've known about this problem for years.
To cut bandwidth, I have a set palette of indexed colors that I use as a base for each strip, and I pick a few extra colors to finish the anti-aliasing. It doesn't take as much effort or time as it sounds, and it cuts bandwidth considerably compared to a trucolor PNG, and doesn't have the artifacts of a JPEG.
However, I noticed that when I reduced one of my strips in size, the brightness always changed, so when I applied my c
Re: (Score:2)
TFA says that Photoshop CS3, in 32-bit image mode, handles things properly*.
*: Where by "properly," I mean "differently than everything else."
Re: (Score:2)
I don't think "32 bit" is what fixed it. What fixed it is that Photoshop also translated to some linear space as a side-effect of whatever he did to convert to 32 bit.
If you have 32 bits I strongly recommend using floating point in it rather than some image format, and if you have floating point then linear light levels work very good. I also recommend 16-bit half floats if you have 16 bits, attempts to make GIMP support 16 bit integers are a waste of time I think, they should go for half.
HA! (Score:5, Funny)
Well, I am SURE glad I'm using Linux^H^H^H^H^HWindows^H^H^H^H^H^H^HMac^H^H^Hshit.
Re: (Score:3)
Actually, according to TFA, Apple's built-in toolkits (used by Aperture and Pixelmator) seem to be immune to this bug. Photoshop ceased being a mac-like application a very long time ago.
This is one of many reasons why creative professionals prefer macs over PCs --- and I'm not saying this as platform evangelism -- for one, you'd be hard pressed to disagree that Mac OS X's font-rendering, kerning, and anti-aliasing abilities are far superior to those provided by Windows when presented with side-by-side exam
Re:HA! (Score:5, Informative)
This is one of many reasons why creative professionals prefer macs over PCs --- and I'm not saying this as platform evangelism -- for one, you'd be hard pressed to disagree that Mac OS X's font-rendering, kerning, and anti-aliasing abilities are far superior to those provided by Windows when presented with side-by-side examples.
Mac OS X's font rendering is different [joelonsoftware.com], but calling it "far superior" is simply platform evangelism.
OS X renders text so that the on-screen representation looks more like the printed representation, which is good for tasks like designing print advertisements (where you want to approximate the finished product as closely as possible). Windows takes liberties with the shape and spacing of on-screen text in order to line it up with the pixel grid, which is good for tasks like word processing and programming (where legibility on screen is more important). When you're used to Windows, Mac text looks blurry; when you're used to the Mac, I imagine Windows text looks thin and lanky.
Re:HA! (Score:4, Insightful)
Same with Windows font rendering. It is plainly inferior in all objective measures of typeface fidelity.
Like I said, that's because fidelity isn't the primary goal. Windows goes out of its way to distort rendered text in order to align the character outlines with pixel boundaries.
You might as well claim that donuts are "plainly inferior in all objective measures of bagel quality": they crumble apart when you try to spread anything on them, you can't buy them pre-sliced, none of them come with raisins inside... and that's all fine, because donuts aren't trying to be bagels.
Subjective taste is subjective. Measurably fidelity is not, and handwaving about one being suited more to a given task than another doesn't make it so.
Once again, you're assuming fidelity is the only goal of a font renderer, but that's not the case.
When you take a font designed to be printed at 600 DPI and render it on a 96 DPI screen where each character is only a few pixels high, you face a tradeoff between fidelity and legibility. Apple decided to prioritize fidelity; Microsoft decided to prioritize legibility.
The link you provided does not support that argument. Legibility is not a significant issue.
Perhaps you missed this part: "Microsoft generally believes that the shape of each letter should be hammered into pixel boundaries to prevent blur and improve readability, even at the cost of not being true to the typeface."
I personally find that working in Windows-based terminals on LCD monitors is far more straining than Mac-based ones or CRT monitors--the text is too sharp and loses distinctiveness.
Fair enough. That's a matter of subjective taste.
Others may be accustomed to something else, and that's fine, but it's flat-out falsehood to claim that grid priority makes for better onscreen legibility.
At the point size in the article's example? Yes, you're right, both lines are legible.
But at smaller sizes, it's a plain statement of fact: distorting characters to keep the lines distinct does indeed make for more legible text than accurately rendering them into amorphous blobs.
Re:HA! (Score:5, Informative)
No, I'm pretty sure that font display is measured by fidelity to the creator's intention and design
And I'm pretty sure you're wrong. Sorry. You might choose to measure font rendering that way--fidelity at any cost, even if it means reducing text to illegible blobs--but I don't, and evidently Microsoft doesn't either. In fact, I'd wager that most people don't.
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?
Because in many (if not most) cases, the primary purpose of rendering text is to make that text readable to the person sitting in front of the screen, and the formatting of that text is a secondary concern. In such cases, making "click here" distinguishable from "dick here" is more important than preserving the font designer's artistic vision.
So the question is, if Microsoft had bothered to put some effort into proper rendering, would there be any meaningful loss of legibility?
Empirically, the answer is obviously "no". As even that article points out, the determining factor is familiarity.
Again, this is only true if you ignore what happens at small sizes.
Why the article pretends that Microsoft's decision was anything other than lack of interest in fine-tuning is rather curious. [...] Pixel grid rendering is simply easier to implement
Nope, you've got it backwards: Microsoft's approach involves more fine-tuning. Apple's approach is easier to implement: just scale the outline to the appropriate size and fill it in.
Again, font rendering is measured by fidelity to the creator's intent. If the typeface is illegible because of blurring, then it's a poor typeface.
Nonsense. A font that looks fine when rendered in a 15-pixel-high line (on a 300 DPI printer) may look illegible when rendered unchanged in a 5-pixel-high line (on screen). That doesn't mean the typeface is poor, it just means it's too intricate for such a low resolution.
But Microsoft's decision to abandon the design in favor of a simplistic snap-to-grid renderer does nothing to improve legibility.
You seem to be confused about how that renderer works. It's far from "simplistic snap-to-grid": simply snapping the font's vertices to a pixel grid would produce garbage. What it actually does is apply the TrueType hints found in the font file.
The OS X font renderer ignores nearly all the hints, which is why the outline it renders at small sizes looks the same as the one it renders at large sizes: the hints are placed there by the font creator to tell renderers how to distort the outline at small sizes.
(Indeed, Microsoft's ClearType renderer pays less attention to the hints than their old one, because the greater resolution of subpixel rendering makes horizontal pixel-fitting less important.)
I happen to be of the print publication era, and I cannot stand the state of Microsoft and Linux font rendering. I'm happy to concede those with a personal and subjective preference for that system, but the reality is that it is objectively inferior in every way.
No, not in every way; only in the particular way you've chosen to focus on. Your personal, subjective preference is showing.
Re: (Score:3, Informative)
By now it's clear that you have no interest or understanding of any application of digital text other than what you've encountered in your own limited experience, and that you lack the technical knowledge to evaluate or discuss the workings of any font rendering algorithm.
Between your ignorance, your accusations, your nonsensical demands (don't use a bitmap image to demonstrate the renderer's output), and your elitist insistence that you are the sole arbiter of what a font renderer is supposed to aim for as
Re:HA! (Score:4, Interesting)
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.
Re:HA! (Score:5, Funny)
I look better in person. (Score:5, Funny)
I've been telling people for years that I look better in person.
I told them that there's something wrong with pictures of me.
HA!
Now I know.
It's the Scaling Algorithm BUG!
Re: (Score:3, Funny)
Man you gotta come up with a better line than that. Even 'I just went swimming', or 'It's cold in here' is more convincing than that!
In any case, your girlfriend will still be disappointed....
... If you ever get one.
A great demo... (Score:2)
for people with poor quality displays!
I now have a much better understanding of why I have to constantly adjust the angle of my (laptop) monitor every time I move my head. Some of the demos on that page are great for illustrating the effect of a poor quality display (or poor scaling algorithm) on picture quality. I'll keep that page in mind the next time I shop for a laptop.
Re:A great demo... (Score:5, Informative)
If you're looking for lcd test images, http://www.lagom.nl/lcd-test/ [lagom.nl] is probably better. It's got a whole bunch of images dedicated to various monitor problems, along with explanations.
Oh dear. Linear color space again, 11 years later? (Score:5, Insightful)
Come on, this isn't news...
Helmut Dersch (of Panorama Tools fame) certainly posted about this before;
http://www.all-in-one.ee/~dersch/gamma/gamma.html [all-in-one.ee] - Interpolation and Gamma Correction
There's no factual error in the scaling algorithm, as the /. headline would like you to believe - it's a color space (linearity) issue; you have to do your calculations in linear space which means a typical photo off of a camera/scanner gets the inverse of an sRGB curve applied (a gamma of 0.454545 is 'close enough' if you can't do the proper color bits). Then scale. Then re-apply the curve.
And no - for real life imagery, nobody really cares - the JPEGs out of the cameras and subsequent re-compression to JPEG after scaling will have 'destroyed' far more data than the linearity issue.
They're nice example images in the story, but they should be called 'academic'.
Re:Oh dear. Linear color space again, 11 years lat (Score:4, Informative)
The example images that make it really clear are academic examples. But the scaled photos are all enough of a change to be worth noticing and caring about if you're a serious amateur photographer (never mind professional). And they don't look particularly unusual to me (I haven't looked for odd trickery, but I assume he's being honest here).
Re:Oh dear. Linear color space again, 11 years lat (Score:4, Interesting)
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".
Re: (Score:3, Insightful)
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".
In what sense is it not a scaling algorithm bug? The images look different after scaling than before, when interpreted in accordance with the appropriate specs. It seems to me that the specification for the scale function is something like "returns an image that is as visually similar as possible to the original, but reduced in size by the specified amount." It might be known, and it might be better described as using the wrong algorithm than an algorithm bug, but it's definitely a bug in the program.
The
Re:Oh dear. Linear color space again, 11 years lat (Score:4, Informative)
It's basically an implementation issue. The algorithms may be fine as intended ... in linear space. The programmers that implemented them didn't understand linear vs. gamma, or didn't care, or had a fire breathing PHB on their back. Hence we get junk software.
At least all MY image processing code always works in linear space. Bu merely converting 8-bit gamma to 8-bit linear is no good because that now introduces some serious quantizing artifacts (major banding effects happen). So I convert the 8-bit gammas to at least 30 or 31 bit integer if I need processing speed, or all the way to double precision floating point if I need as close to correct as possible. After processing, then I convert back to 8-bit gammas. Even then, you can't totally eliminate some banding effects that result from being in 8-bit. If you can get more bits from the raw images from your camera, that's the best to use. Apparently many JPEG compressors are also doing their DCT calculations in the non-unit gamma space instead of the linear space, too (which reduces the effectiveness of the compression somewhat, and may add more compression artifacts).
Some look worse. (Score:2)
Is it just me or do some of the examples look _better_ with the "incorrect" scaling?
For example, this one of the NASA image:
http://www.4p8.com/eric.brasseur/gamma_21.html [4p8.com]
Look right at the center of that picture on the incorrect scaling one, and without moving your eyes switch it to correct. When I do it at least, it feels like my eyes instantly lose focus. With the incorrect scaling, everything looks perfectly crisp and clear. With the corrected one it takes a significant amount of effort to focus anywhere
Re: (Score:2, Insightful)
Re: (Score:2)
Look at the islands and the lakes. They're crisp at the edges, whereas those islands disappear when you use the incorrect scaling. I wouldn't use the incorrectly scaled image for anything important.
Gamma and Computer Vision (Score:3, Interesting)
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.
Re:Gamma and Computer Vision (Score:4, Interesting)
1. Spend a lot of time calibrating your camera yourself. This is only cheap if your time is worthless
Typically this should be done during the initial set-up of any new camera that a photographer purchases. A Gretag Macbeth colour checker is cheap, the required shot to evaluate the performance of the sensor is quick and easy to set-up and the processing of this test image is fast with the right tools (like this script for photoshop [rags-int-inc.com]). It should take under an hour to do it right and get it as part of the automatic stage of processing your RAW files (basically setting ACR/Lightroom's demosaicing stage), but the benefit is that every picture taken from then onwards does not need extra calibration. Thus your prints look like your shots, assuming the rest of your workflow is equally as calibrated.
While your time is valuable, if you do not calibrate like this, you're wasting time further down the line for EACH image, and thus it's more expensive to not do it...
Old news (and workaround) (Score:5, Informative)
Ok, so he made a very informative page about it, but this is still a well known effect. It affects practically everything you can do in image editing. Blurs, etc. Most people neither notice nor care. It's rooted in the fact that most images come with undefined black and white points and a gamma chosen for artistic effect rather than physical accuracy. Thus correctly converting to linear gamma is hardly ever possible. You can still correct for monitor gamma to avoid some rarely seen inconsistencies and artifacts, but most people don't even notice, so why bother? However, Photoshop does have everything you need to avoid the effect completely, even in the ancient Photoshop 6.0.
Here's how to properly resize in Photoshop:
1. Convert mode to 16 bit (to avoid tone aliasing in the next step, no other influence on the calculations)
2. Convert to profile, select "Custom RGB", set Gamma to 1.0 (this converts the internal image data to linear gamma, no visible change because the image is color managed and corrected back to monitor gamma on the fly)
3. Image Size
4. Convert to profile, select "Custom RGB", set Gamma to 2.2 (default)
5. Convert mode to 8 bit
Done. You can substitute your favorite image filter for the image resize. Unsharp mask works much better at gamma 1.0, for example. Of course you can use several filters before converting back to monitor gamma and 8 bit.
Re: (Score:2)
Open RAW file from a Nikon D2x in Adobe Camera Raw 5.6
Open another copy - no changes in ACR (both are native size for camera)
Copy 1 - Change color profile from ProPhoto (my working RGB) to Custom RGB with Gamma set a 1.0
Copy 2 - Leave in ProPhoto
Resize to half the original size, same pixel depth (both files)
Run unsharp mask to taste on Copy 2 (ProPhoto)
Run same unsharp mask on Copy 1
Convert Copy 1 back to ProPhoto or custom
Re:Old news (and workaround) (Score:4, Interesting)
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).
Picture Publisher 10 Pro and PMView 3 work fine (Score:2)
So there you go.
Old news (Score:5, Interesting)
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 [verizon.net]. See here for the overall paper: http://mysite.verizon.net/~spitzak/conversion/index.html [verizon.net] and a Siggraph paper on the conversion of such images here: http://mysite.verizon.net/~spitzak/conversion/sketches_0265.pdf [verizon.net], 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.
Easy fix without changing software (Score:2)
I have a Shareware app that I purchased something like 15 years ago. It exhibits the bug; but it also has a gamma correction function. I corrected the gamm to 0.46 (approx inverse of 2.2) then scaled the test image of the Dalai Lama, then corrected back to 2.2. It looks fine. YMMV I suppose; but if your app supports gamma correction then by all means try this trick before doing anything more drastic. That's assuming of course that it's really critical for you; which as others have pointed out it probably
ok, now that this is fixed (Score:2)
now that this is fixed, can we finally have those infinite resolution zoom-in functions they have in the movies?
But is it Art? (Score:2)
In the short run, look for a new marketing bullet point.
Wrong (Score:2, Insightful)
"There is an important error in most photography scaling algorithms."
No, there isn't. If millions of professional users haven't been bothered by it over the course of two decades, it is CLEARLY not important.
By the way: (Score:2)
Has anyone else noticed the “dark gamma” cancer that came over the Internet since the dawn of cheap LCD displays?
I have a couple of very carefully calibrated displays here, and pretty much everything on YouTube and every image on the net has a way too deep gamma.
Which is caused by the LCDs (especially the cheap ones) all being extremely white and having a distorted gamma by default.
It’s really annoying, since I always have to switch the color profile when I want to see anything in those vi
Editing in RGB is wrong too (Score:5, Informative)
Sound makes a good analogy. When you play music through any given combination of source, amp and speakers, it sounds different. Sometimes we actually like a particular type of sonic "distortion". It's never exactly like the "original" live music, though.
Likewise, any graphics manipulation is "distorting" the original. In fact, when I take a digital image and run it through Lightroom, do a range expansion/equalization, and do a bunch of tweaks to make the image look good, I'm making much larger changes than those little scaling problems listed in the article. The point is, do you think the result looks good?
There's other important variables, such as what colors are next to other colors in the image, how long you look at the image, what else is around you, how tired you are, etc. There's no such thing as color fidelity, there's only approximations to it. Color is hard, and I mean, really hard. See Hunt, "The Reproduction of Colour", or any number of other fine texts to learn more.
Re: (Score:3, Informative)
Actually, different color spaces are OK, so long as they are just linear transformations from cone space. That is the case for (linear) RGB, (linear) HSV, XYZ, and a few others. As long as the transformation is linear (i.e. just a matrix times the color vector to give you a color vector in the cone space), you can apply any linear operation (such as scaling, blurring, and other weighted sums), and the order of transformation is exchangeable.
For example, say LMS = M * RGB and you want to average two pixels.
Is there a way to use this for steganography? (Score:2)
Hummm, can you turn this bug around and come up with an image that appears totally gray in normal size but looks like something recognizable when you scale it up or down? If so, that could be a basis of some cool steganographic hack.
By Accident (Score:2)
By accident, I happen to have the aforementioned (TFA) Lightroom 1.4.1.
That wasn't skill, that was luck.
I am a Pro Photographer and I've just purchased (well, the Mrs. got it for me for Christmas) a *Nikon Super Coolscan 9000 WITH matching photon torpedo sleds, complete with very lame software and support.
I'm about to begin transferring a considerable amount of slides to digital and this is news to me. I still shoot film and plan to continue until pried from my cold dead hands etc., etc.
The article illustra
I thought it was just me (Score:3, Interesting)
Re: (Score:2)
Yeah, I think it comes down to what the graphics files specify. This is the first I've heard that 24-bit color is logarithmic. I suspect that.. it isn't..though. If it is, then yeah, the scaling algorithms ought to have been taking it into account.
Any time you're taking an average, you can hand-craft a set of points that average to whatever you want. The dalai picture doesn't really prove anything, only that a log/exponential scaling algorithm might have some interesting, perhaps even desirable resul
Re:Author expands scaling defination (Score:5, Funny)
I am sure the Chinese government prefers the current implementation.
Re: (Score:2)
Re: (Score:3, Informative)
You're absolutely correct, AC. The reported issue isn't about a linear/nonlinear gamma bug at all - it's an averaging side effect.
The sample Dalai Lama image on TFA's page is intentionally constructed of interlaced lines of red and green data to thwart the averaging of source data used in common scaling algorithms. If you use the Gimp with the "None" scaling method, which will just pick-up every other row and column when scaling by 50%, (instead of trying to average 2x2 grids) you get a mostly-green image i
Correct, yes. Expected, maybe. Desired, no. (Score:4, Informative)
I think the author specifically isn't stating whether the scaling is correct or not - it is; the whole story doesn't relate to scaling at all, but rather color space and how -it- affects, among other, scaling. Yes, with filtering - scaling without filtering can hardly be called scaling at all as you're just discarding data - and for anything but multiples of 2 (4x, 2x, 0.5x, 0.25x, etc.) that'd have a whole 'nother set of problems.
The author, I think, is suggesting, quite rightly so, that while...
The desired result for scaling down likely being that of the same visual image as when you simply stand further back.
( although at some point the resolution limit of a display and the image itself being presented on that display prevents that concept from being applied to "moving your eyeballs closer to the screen" for scaling up. )
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
Actually a good scaling algorithm should perform a lowpass filter when downscaling. This is similar to downsampling of digital audio where you do need to filter out frequencies above half the sampling rate. Leafing these higher frequencies in would cause noise because they can not be faithfully represented in a lower resolution file.
Re: (Score:2)
All I know is that you actually need to remove any gamma information from a PNG file in order to display them correctly in most browsers. Otherwise, they're too dark on some configurations and too light on others.
Re: (Score:2)
This is because the gamma value that programs wrote to the png file is wrong.
I think almost all software nowadays ignores png gamma values. I have gotten in some arguments with some color management folks because imho it works best to ignore *all* "color management" such as embedded profiles. They are wrong far more often than they are right, because the whole field is very confusing and software is filled with a zillion bugs.
To answer the grandparent, the "gamma" is used to convert the numbers in the file
Re: (Score:3, Insightful)
But the point of the article is that it is possible to do it correctly. As many posts have pointed out, the standard gamma for sRGB images where the gamma is not specified is 2.2. Not taking that into account is, in fact, an error. If the image data are not linear to begin with, then why are we applying algorithms to the image as if they were?
Changing the image's gamma value during scaling is an error, plain and simple, especially when we know what the gamma of the image is to begin with!
Programs like Pi
Re: (Score:3, Interesting)
It's not at all complicated. Many applications do properly handle it. Nuke, Shake and other compositing apps have no problem.
Pixel^(GAMMA) -> Scale -> Pixel^(1/GAMMA) I wouldn't call that a terribly complicated process.
Or even better. On open convert it to linear. Then on save convert it back. Maybe then Photoshop and company would actually handle alpha channels correctly *grumble* *grumble*...
Re:And this is still why, even in 2010. (Score:4, Funny)
The 270-year-old professional portrait artist tells me there is just a difference and photography hasn't made it up yet. He isn't giving up his canvas and I can't really blame him. I guess this isn't the film's fault and it shouldn't affect anything if the subject can be made to hold motionless for several minutes in a brightly-lit setting, but it makes you question if human-driven devices and systems should be abandoned at the current rates.
bugs filed (Score:3, Funny)
Check the Gimp bug database. It has complaints going back many many years. Trouble is, a bug report is easy to ignore and/or misunderstand.
Getting this fixed requires sitting down with all the core developers and using small words until it sinks into their thick skulls.