Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Scaling Algorithm Bug In Gimp, Photoshop, Others

kdawson posted more than 4 years ago | from the black-is-black-sometimes dept.

Bug 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."

Sorry! There are no comments related to the filter you selected.

FP! (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#31254398)

FP!

Oh calm down.. (4, Insightful)

Anonymous Coward | more than 4 years ago | (#31254402)

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:Oh calm down.. (1)

biryokumaru (822262) | more than 4 years ago | (#31254592)

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:Oh calm down.. (2, Informative)

Anonymous Coward | more than 4 years ago | (#31255326)

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:Oh calm down.. (3, Funny)

nollidge (1315833) | more than 4 years ago | (#31255430)

Having read that I am willing to be English isn't his first language

I am willing to be Mavis Beacon.

Monitor gamma? (2, Insightful)

Yvan256 (722131) | more than 4 years ago | (#31254420)

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:Monitor gamma? (2, Interesting)

Trepidity (597) | more than 4 years ago | (#31254474)

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:Monitor gamma? (1)

X0563511 (793323) | more than 4 years ago | (#31254948)

Yes, excepting that this issue is talking about the bug in image editors.

Re:Monitor gamma? (1)

Idarubicin (579475) | more than 4 years ago | (#31255230)

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? (5, Funny)

theskipper (461997) | more than 4 years ago | (#31254486)

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? (5, Funny)

Anonymous Coward | more than 4 years ago | (#31255158)

Well?

Re:Monitor gamma? (5, Funny)

DeathElk (883654) | more than 4 years ago | (#31255396)

Well?

Somehow I don't think you've given him enough time.

Re:Monitor gamma? (3, Interesting)

poetmatt (793785) | more than 4 years ago | (#31254560)

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:Monitor gamma? (1)

tagno25 (1518033) | more than 4 years ago | (#31254630)

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:Monitor gamma? (0)

Anonymous Coward | more than 4 years ago | (#31254920)

For me in FF I get a grey box for the first scaled image and the two smaller ones below show the scaled image shaded (top/middle/bottom) green/grey/red and red/grey/green.

For both IE and Chrome I see the first scaled image as appearing very lightly embossed. Both of the smaller scaled images also appear very faintly embossed, not quite a perfectly even grey.

Re:Monitor gamma? (2, Insightful)

X0563511 (793323) | more than 4 years ago | (#31254990)

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 or green or half-green, half-pink:

(smaller dali or grey box)
(mine draws in grey, despite using Firefox)

Below it is scaled down 1:4. The right one is one pixel wider and higher than the left one. Some browsers display them quite differently:

(two images, differing if you have the bug)

Re:Monitor gamma? (2, Insightful)

DocHoncho (1198543) | more than 4 years ago | (#31255144)

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? (5, Informative)

evanbd (210358) | more than 4 years ago | (#31254584)

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:Monitor gamma? (1)

zippthorne (748122) | more than 4 years ago | (#31254612)

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?

Re:Monitor gamma? (0)

Anonymous Coward | more than 4 years ago | (#31254770)

If your camera produces "raw" image files, that may be the case. If it produces JPEG files, it is almost certainly applying a gamma correction of some kind. Otherwise the images would look very wrong when displayed on a normal computer screen.

Re:Monitor gamma? (5, Informative)

evanbd (210358) | more than 4 years ago | (#31254778)

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:Monitor gamma? (2, Informative)

reub2000 (705806) | more than 4 years ago | (#31254854)

Depends. Standard sRGB used in a jpeg file stores the data in non-linear format. If data was stored in a linear format, then a disproportionate part of the gamut would be in the highlights. On the other hand, a raw file contains the data in a linear format.

Re:Monitor gamma? (1)

spitzak (4019) | more than 4 years ago | (#31255184)

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:Monitor gamma? (1)

shutdown -p now (807394) | more than 4 years ago | (#31255274)

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 (4, Insightful)

smasch (77993) | more than 4 years ago | (#31254802)

The basic issue here has to do with gamma curves and the way they're being handled (they're not).

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:Gamma and sRGB (1)

Anonymous Coward | more than 4 years ago | (#31254896)

Naturally I did not read the article, but if the above post is correct then this is rather sad as operating on the correct signal space in signal processing and/or image processing is a very basic and necessary aspect to consider. Imagine if your cell phone or VoIP didn't take that into consideration (most audio codecs start out in a-law or u-law companding; similar to the idea of gamma curves).

Blah.

Re:Monitor gamma? (1)

asifyoucare (302582) | more than 4 years ago | (#31255076)

It seems crazy to me to embed a particular Gamma value into an image. Surely the point for Gamma correction is just before it is output to a device, and then the adjustment should be device specific (if possible). It is even crazier these days to use a Gamma based on the attributes of CRTs.

In fact it seems so crazy I must be missing something. Am I?

Re:Monitor gamma? (5, Informative)

Idarubicin (579475) | more than 4 years ago | (#31255378)

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:Monitor gamma? (2, Informative)

Anonymous Coward | more than 4 years ago | (#31255500)

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 point.

One consequence is that if you store an image with linear gamma, you need more bits to cover the same dynamic range with the same minimal distance between two dark tones. You can immediately see the decrease in resolution for the dark tones when you create an 8-bit image with a black-white gradient in Photoshop and then convert this image to a color profile with gamma 1.0.

So not only is the 2.2 gamma which is used in the sRGB standard a sensible choice for the display technology of yesteryear, it also makes better use of the allocated bits than a gamma 1.0 image would.

What about Irfanview and Picasa? (1)

cytoman (792326) | more than 4 years ago | (#31254424)

I'm not a pro photosoftware user so I guess none of what's discussed here really affects me. But still, I'm curious about Irfanview and Picasa, the two programs that I use for my photo needs. Are these affected? How do I detect the effect?

Re:What about Irfanview and Picasa? (1)

gnapster (1401889) | more than 4 years ago | (#31254460)

Resize the photo in the linked article to 50% smaller. If you get a grey rectangle instead of something interesting, your software has teh problem. Irfanview 4.25, according to my quick experiments, has the problem when rescaling, but not resizing.

Re:What about Irfanview and Picasa? (1)

tenton (181778) | more than 4 years ago | (#31254462)

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:What about Irfanview and Picasa? (1)

Holmwood (899130) | more than 4 years ago | (#31254498)

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? (3, Informative)

cytoman (792326) | more than 4 years ago | (#31254668)

Gray rectangles in Picasa 3 and in Irfanview 4.25 :-(

short version (5, Informative)

Trepidity (597) | more than 4 years ago | (#31254438)

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:short version (-1)

Anonymous Coward | more than 4 years ago | (#31254572)

Brightness by itself is not a function, so it can't be linear or nonlinear.

Re:short version (2, Informative)

evanbd (210358) | more than 4 years ago | (#31254624)

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:short version (-1, Troll)

wvmarle (1070040) | more than 4 years ago | (#31254880)

Reading the comments I finally start to understand what tfs is trying to say.

All and all I would not call this a bug. Also not a feature. It's an artifact at best. Bugs in the common use of the word are either small animals, or programming errors. This is neither. It's an algorithm that has certain artifacts, and some software (the long list in tfs) apparently uses a different algorithm.

So how is this news? What does it have to do on /. really? This is more something to discuss for graphics people, not for computer people like we are.

Re:short version (0)

Anonymous Coward | more than 4 years ago | (#31255014)

So how is this news? What does it have to do on /. really? This is more something to discuss for graphics people, not for computer people like we are.

It's not news. But the fact that you seem to think, as a "computer person", that you don't need to understand this, is an excellent reason for it to be posted. If you're writing a program that does anything non-trivial with graphics, you should at least be aware of these issues. (In many cases, you may just want to pretend that RGB values are linear, and that may be OK for some applications, but you should be aware that it's an oversimplification.)

(But yes, Slashdot is obviously a totally homogeneous group, and I can't imagine that there would ever be an article posted here that would interest some readers and not others.)

omg you're right! it's not news. (1)

decora (1710862) | more than 4 years ago | (#31255300)

i demand immediate recall!

Author expands scaling defination (0)

Anonymous Coward | more than 4 years ago | (#31254446)

The author seems to think filtering is part of scaling which it is not. A "scaling" algorithm does not include low-pass filtering. The grey square shown is the correct result for a bicubic scale.

Re:Author expands scaling defination (1)

zippthorne (748122) | more than 4 years ago | (#31254598)

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 results.

Re:Author expands scaling defination (5, Funny)

Anonymous Coward | more than 4 years ago | (#31254690)

I am sure the Chinese government prefers the current implementation.

Re:Author expands scaling defination (0)

Anonymous Coward | more than 4 years ago | (#31254914)

Somebody needs to mod the parent comment funny.

Re:Author expands scaling defination (2, Informative)

scdeimos (632778) | more than 4 years ago | (#31254892)

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 instead of the grey image advertised.

Correct, yes. Expected, maybe. Desired, no. (3, Informative)

Animaether (411575) | more than 4 years ago | (#31255282)

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 grey square shown is the correct result

...it is not the expected (by laymen) nor desired (by just about anybody) result.

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:Correct, yes. Expected, maybe. Desired, no. (2, Insightful)

icegreentea (974342) | more than 4 years ago | (#31255480)

Well, as much as desired goes, this also affects how a lot of filters and effects work. For example, it causes most Gaussian blur implementations to 'flare' brights into darks more than they should. And that's been happening for so long, that that's now the expected/wanted behavior out of 'Gaussian Blurs'. If you changed that, you would have some confused/annoyed users.

This isn't really a bug (3, Insightful)

Cassini2 (956052) | more than 4 years ago | (#31254478)

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 (5, Informative)

johndoe42 (179131) | more than 4 years ago | (#31254614)

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.)

Photographer here (-1)

Anonymous Coward | more than 4 years ago | (#31254754)

Completely agreed. This guy writes like he's discovered the holy grail of image processing inadequacy. Honestly, this would be great to have in, say, Firefox.

But when you're scaling in Photoshop you don't want this. Why? Because *every software does it*. As the parent says, software doesn't specify or allow you to set its primitives. Here's a case where we actually have a universal primitive! Woohoo!

OK with that out of the way, it would be great if it took into account the CAMERA gamma for me. But, it looks like (from a cursory glance) his algorithmic treatment could cause loss of detail to the bright and dark shades pretty easily, unless he has some somewhat advanced equations going on. I mean mixing with gamma, you could start clipping easily, unless you're doing it REALLY REALLY properly. Scaling a 21 megapixel image already takes long enough (in batch)... :-(

Anyway. I'm sure the explanation is that someone somewhere has a patent and nobody wants to pay them for it because it's really not THAT big a deal so they don't. And I shoot RAW and use Lightroom any

Re:Photographer here (1)

adolf (21054) | more than 4 years ago | (#31254846)

TFA says that Photoshop CS3, in 32-bit image mode, handles things properly*.

*: Where by "properly," I mean "differently than everything else."

Re:Photographer here (1)

spitzak (4019) | more than 4 years ago | (#31255156)

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.

Re:This isn't really a bug (2, Insightful)

dimeglio (456244) | more than 4 years ago | (#31254824)

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:This isn't really a bug (0)

Anonymous Coward | more than 4 years ago | (#31255270)

Actually I've seen some of these images in Futaba(the BBS 4chan's derived from). When I try to open, say, a NSFW thumbnail, it turns into maccho guy. ouch. It's quite...... common.

HA! (5, Funny)

TheDarkener (198348) | more than 4 years ago | (#31254504)

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:HA! (1)

rafaelolg (1248814) | more than 4 years ago | (#31254864)

I tried with ImageMagick convert and it is not as bad as the firefox resize or the eye of gnome and gimp. One can still see the Dalai Lama after "convert -resize 50%" .

Re:HA! (0)

Anonymous Coward | more than 4 years ago | (#31254994)

I use shit too!

Re:HA! (0)

Anonymous Coward | more than 4 years ago | (#31255354)

Well, I am SURE glad I'm using Linux^H^H^H^H^HWindows^H^H^H^H^H^H^HMac^H^H^Hshit.

Actually, since Preview (the default Apple image viewer) and Aperture (the fancy $$$ Apple image manager) are not affected, I'd say this is a win for ColorSync, and by extension, the Mac and its use in all things graphical.

Re:HA! (2)

moosesocks (264553) | more than 4 years ago | (#31255382)

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 examples. It's lots of little things (many of which likely took the programmers a great deal of time to get right) that make the platform so nice to work with. Likewise, Adobe is quickly exhausting its remaining good will with the graphic design community, as recent Photoshop releases have declined significantly in quality, and have generally added little value to the application, as well as the abomination that is the Flash player.

I haven't checked Win7 yet, but as of Vista, Windows still presented windows-3.1-style dialog boxes when adding fonts. Although this is a fairly superficial example, it provides a great example of Microsoft's general neglect of its existing codebases. Once a feature becomes "stable," it rarely if ever gets refined or tweaked in subsequent releases, while poorly-integrated features get piled on top (although it must be said that when Microsoft finally does choose to overhaul part of the UI, they generally do a pretty good job of it. IE7 and 8 are notable exceptions, and actually seem to have been made intentionally confusing -- even the KDE, GIMP, and Blender folks would struggle to make a UI so cryptic, inconsistent, and foreign-looking)

Re:HA! (4, Funny)

Korin43 (881732) | more than 4 years ago | (#31255474)

Well I tested the site in lynx and I didn't see any problems..

Nitpicking (1, Insightful)

Ekuryua (940558) | more than 4 years ago | (#31254510)

Is what this article is about.
This matter has been known for a long time, and there's a reason why so many softwares ignore it:
it hardly matters. That and it's also way more complicated to do it properly.
Gain / Pain is clearly inferior to 1 there.

Re:Nitpicking (2, Insightful)

caseih (160668) | more than 4 years ago | (#31255276)

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 Picasa and other photography programs certainly should be taking this into account.

Most professional photographers capture all their images to raw format. I think raw images are linear and are mapped to a gamma in post-production. So they probably will be less affected by this error. This may be why the pain/gain ratio for Adobe, for example, would be too large.

Re:Nitpicking (1, Informative)

jabberw0k (62554) | more than 4 years ago | (#31255400)

so many softwares

Urrgh... it's "so many programs" or "so many software packages" ... you don't have "one software" -- you have a piece of software. It's a collective noun like "hardware" and "clothing." There is no word, "softwares."

Re:Nitpicking (0)

Anonymous Coward | more than 4 years ago | (#31255416)

But at least now I know there was some actual reason for why I had to sharpen pics when making my thumbnail images, it wasn't just because I thought it looked off. Contrast really is lost with the standard scaling/resizing routine. Having an alternate method that evaluates the image histogram and correctly adjusts some factors before/during scaling based on that would be nice to have. (Apparently this is what the author is demonstrating.) Now the question is how soon until we can get the plugins to download for our image manipulating software(s)?

I look better in person. (5, Funny)

ipquickly (1562169) | more than 4 years ago | (#31254570)

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:I look better in person. (2, Funny)

grcumb (781340) | more than 4 years ago | (#31254958)

It's the Scaling Algorithm BUG!

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... (1)

Interoperable (1651953) | more than 4 years ago | (#31254580)

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... (4, Informative)

MortimerV (896247) | more than 4 years ago | (#31254888)

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.

Not so common image (1)

cbuosi (1492959) | more than 4 years ago | (#31254632)

1) this image was created to reproduce the bug. except for low definition display (TV/NTSC) its not common to have this "scanlines". 2) instead of resising, just blur the image before and then resise. 3) Interesting bug, thou.

Re:Not so common image (0)

Anonymous Coward | more than 4 years ago | (#31254708)

2) instead of resising, just blur the image before and then resise.

You'll find that blurring the image will cause it to turn almost completely gray.

Re:Not so common image (0)

Anonymous Coward | more than 4 years ago | (#31254822)

Unless, of course, you use a properly-gamma aware blur. But then... might as well just use a properly gamma-aware resize in the first place.

Oh dear. Linear color space again, 11 years later? (4, Insightful)

Animaether (411575) | more than 4 years ago | (#31254664)

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 (3, Informative)

evanbd (210358) | more than 4 years ago | (#31254798)

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 (3, Interesting)

Animaether (411575) | more than 4 years ago | (#31254906)

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:Oh dear. Linear color space again, 11 years lat (0)

syousef (465911) | more than 4 years ago | (#31254970)

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).

Really? It looked to me like the images I looked at need to be pretty badly pixelated (resized well beyond what a serious amateur would find acceptable) for this to be a serious concern. Of course some people are always going to be more interested in over analysing their photos than producing good ones...*shrug*

Re:Oh dear. Linear color space again, 11 years lat (1, Insightful)

Anonymous Coward | more than 4 years ago | (#31255124)

One filter where this issue really bites is "unsharp mask". Non-linear gamma results in very noticeable artifacts around high contrast edges. With linear gamma, you can crank the filter strength much higher without producing these artifacts, resulting in very crisp pictures that do not look obviously sharpened.

It is not a scaling algorithm problem. It's a problem that affects all filters which combine pixels. The only reasonable way to avoid the problem is to hold the image data in memory in a linear representation (as converting it back and forth on the fly every time a filter is applied would quickly accumulate rounding errors). Unsurprisingly every image editing software worth its money already offers that conversion, and doesn't force it on the user because it's not without downsides: The conversion isn't lossless and distributes the tone curve unfavorably in the allocated bits, resulting in either loss of precision at the same bit depth or bigger memory allocations for minimal loss of precision.

Re:Oh dear. Linear color space again, 11 years lat (3, Informative)

Skapare (16644) | more than 4 years ago | (#31254956)

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. (1)

Urza9814 (883915) | more than 4 years ago | (#31254702)

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 near the center of the image, and it takes significant effort to maintain that focus. The corrected one feels like I'm trying to look at a picture when I haven't put in my contacts yet...

Re:Some look worse. (2, Insightful)

BoppreH (1520463) | more than 4 years ago | (#31254812)

That might be true, but it's no reason to turn this into an undocumented and unavoidable feature.

Re:Some look worse. (1)

PitaBred (632671) | more than 4 years ago | (#31255332)

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 (0)

friedo (112163) | more than 4 years ago | (#31254740)

As a programmer who knows nothing about graphics algorithms, can somebody explain to me exactly what gamma is? I've been told I should by worrying about it for at least a couple decades, but thus far my lack of knowledge has not caused by any bodily injury. Use small words.

Re:Gamma (1)

Yvan256 (722131) | more than 4 years ago | (#31254884)

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:Gamma (1)

spitzak (4019) | more than 4 years ago | (#31255146)

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 into the actual brightness, the formula for brightness is pow(N/MAX, 1/GAMMA), where N = number in file, MAX = largest number file can store, and GAMMA = gamma value.

Gamma and Computer Vision (3, Interesting)

drewm1980 (902779) | more than 4 years ago | (#31254764)

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.

Isn't this a bit late? (1)

BoppreH (1520463) | more than 4 years ago | (#31254804)

This software have been around for decades. I've seen people turn to macs because they "display colors better", but in all those years nobody filled a bug report about this?

Color me surprised. With correct gamma, please.

Important error? (0, Troll)

cloudmaster (10662) | more than 4 years ago | (#31254826)

This bug is so important, that it's been in most all software for longer that many of its users have been alive without anyone noticing it. I'd call that a "minor" bug, and maybe a "stupid" bug - but certainly not "important."

Digikam 1.0.0 Immune (0)

Anonymous Coward | more than 4 years ago | (#31254838)

Whew!

Old news (and workaround) (5, Informative)

JackHoffman (1033824) | more than 4 years ago | (#31254840)

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:Old news (and workaround) (1)

ArundelCastle (1581543) | more than 4 years ago | (#31255520)

This is indeed very old news. Looks like the original article is circa 2007, and we're here figuring out that hardly any developers have addressed it.

Here's how to properly resize in Photoshop:

Great tip, but sentences like that are part of the problem.
If Photoshop isn't resizing "properly" it's Adobe's Damn Job to do something about it if they want to charge seven hundred dollars.
Teaching users how to create an action script doesn't quite cut it. At the *very* minimum there could be a checkbox for "Very Precise Gamma Calculations (25% slower)".

"Most people don't even notice, so why bother" shouldn't be an acceptable bullet point in industries like medicine, astronomy, military, and engineering. I guarantee all of which use Photoshop, or another image viewer/processor with the same issue.

It's not "a software" (1)

jabberw0k (62554) | more than 4 years ago | (#31255018)

This is a scaling performed by a correct software...

I see this error more frequently lately. Do you wear "a clothing" or buy "a hardware" ? It's a piece of software, or a software program or package. I can haz grammar nitpick point?

Picture Publisher 10 Pro and PMView 3 work fine (1)

gmezero (4448) | more than 4 years ago | (#31255028)

So there you go.

MSPaint scales selection differently (1)

Imnimo (1264154) | more than 4 years ago | (#31255054)

Taking the Dalai Lama picture, I get two different results from MSPaint. If I paste the image into a new file, deselect, and then scale the entire image by 50% (in each direction so to 1/4 size), I get the gray box. However, if I select all, and then scale by 50%, I get an odd magenta Dalai Lama. Any insights as to why this might be?

Re:MSPaint scales selection differently (0)

Anonymous Coward | more than 4 years ago | (#31255138)

Resize vs Resample?

Or just that the resizing with the cursor uses basic BitBlt API and the resize option does something more advanced.

Old news (4, Interesting)

spitzak (4019) | more than 4 years ago | (#31255056)

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.

That *should* read: (0)

GrahamCox (741991) | more than 4 years ago | (#31255114)

That should read: "There is an UNimportant error in most photography scaling algorithms".

FILM is not dead it just smells funny (0)

Anonymous Coward | more than 4 years ago | (#31255250)

I shoot film so meh

what's the scope of this? (1)

ILuvRamen (1026668) | more than 4 years ago | (#31255288)

So is this like RGB color schemes only in certain scaling modes only? Like if I do a CMYK photoshop project and scale an image down with a non-standard scaling type optimized for reduction or gradient preservation or enlargement or whatever then would it be affected by the glitch?

This is what I got when I scaled the image down. (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31255306)

SCALED IMAGE [imageshack.us]

Easy fix without changing software (1)

istartedi (132515) | more than 4 years ago | (#31255408)

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 isn't. Stil though, it's nice to see this pointed out.

ok, now that this is fixed (1)

Punto (100573) | more than 4 years ago | (#31255488)

now that this is fixed, can we finally have those infinite resolution zoom-in functions they have in the movies?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?