Slashdot Mirror
Scaling Algorithm Bug In Gimp, Photoshop, Others
Wescotte writes "There is an important error in most photography scaling algorithms. All software tested has the problem: The Gimp, Adobe Photoshop, CinePaint, Nip2, ImageMagick, GQview, Eye of Gnome, Paint, and Krita. The problem exists across three different operating systems: Linux, Mac OS X, and Windows. (These exceptions have subsequently been reported — this software does not suffer from the problem: the Netpbm toolkit for graphic manipulations, the developing GEGL toolkit, 32-bit encoded images in Photoshop CS3, the latest version of Image Analyzer, the image exporters in Aperture 1.5.6, the latest version of Rendera, Adobe Lightroom 1.4.1, Pixelmator for Mac OS X, Paint Shop Pro X2, and the Preview app in Mac OS X starting from version 10.6.) Photographs scaled with the affected software are degraded, because of incorrect algorithmic accounting for monitor gamma. The degradation is often faint, but probably most pictures contain at least an array where the degradation is clearly visible. I believe this has happened since the first versions of these programs, maybe 20 years ago."
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...
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.
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?
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.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
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.
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.
Well, I am SURE glad I'm using Linux^H^H^H^H^HWindows^H^H^H^H^H^H^HMac^H^H^Hshit.
It is pitch black. You are likely to be eaten by a grue.
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.
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!
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.
So if this is the future...where's my jet pack?
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.
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 - 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'.
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
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...
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.
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.
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).
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 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.
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.
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."
Whew!
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.
TFA says that Photoshop CS3, in 32-bit image mode, handles things properly*.
*: Where by "properly," I mean "differently than everything else."
Kid-proof tablet..
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".
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).
now we need to go OSS in diesel cars
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*
These posts express my own personal views, not those of my employer
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?
So there you go.
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?
My software has been calculating in linear space for over a decade now (this is the Nuke Compositor currenlty produced by The Foundry but at the time it was used by Digital Domain for Titanic). You can see some pages I wrote on the effect here: http://mysite.verizon.net/~spitzak/conversion/composite.html. See here for the overall paper: http://mysite.verizon.net/~spitzak/conversion/index.html and a Siggraph paper on the conversion of such images here: http://mysite.verizon.net/~spitzak/conversion/sketches_0265.pdf, in fact a lot more work went into figuring out how to get such linear images to show on the screen on hardware of that era than on the obvious need to do the math in linear. Initial work on this was done for Apollo 13 as the problems with gamma were quite obvious when scaling images of small bright objects against the black of space.
For typical photographs the effect is not very visible in scaling, as the gamma curve is very close to a straight line for two close points and thus the result is not very much different. Only widely separated points (ie very high contrast images with sharp edges) will show a visible difference. This probably means you are trying to scale line art, there are screenshots in the html pages showing the results of this. Far worse errors can be found in lighting calculations and in filtering operations such as blur. At the time even the most expensive professional 3D renderers were doing lighting completely wrong, but things have gotten better now that they can use floating point intermediate images.
One big annoyance is that you better do the math in floating point. Even 16 bits is insufficient for linear light levels as the black points will be too far apart and visible (the space is wasted on many many more white levels than you ever would need). A logarithmic system is needed, and on modern hardware you might as well use IEEE floating point, or the ILM "half" standard for 16-bit floating point.
Comment removed based on user account deletion
That should read: "There is an UNimportant error in most photography scaling algorithms".
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.
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.
I shoot film so meh
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. )
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?
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
i demand immediate recall!
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.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
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.
now that this is fixed, can we finally have those infinite resolution zoom-in functions they have in the movies?
--
Stay tuned for some shock and awe coming right up after this messages!
Comment removed based on user account deletion
Looks ok to me. Besides, I think I just read a Slashdot article that all digital media is going to rot in the long run.
In the short run, look for a new marketing bullet point.
This issue is a bit more complicated than you think.
"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.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
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 videos. And images I create for the web end up looking very white on Joe Sixpack’s displays. :(
I wish there was a way to punch every display company boss in the face for not enforcing proper calibration. :/
Any sufficiently advanced intelligence is indistinguishable from stupidity.
Several people have spoken about "linear" RGB. That's nice and gets rid of some small level of distortion introduced by the non-linearity. However, it only starts there. For example, the eye sees R, G, and B differently. It is more sensitive to green than red, and to red more than blue, but it's not even that simple as the equations in your eye's processor are much more complicated. Many algorithms that treat the three "equally" are going to change the perceptual mixture. One can use other color spaces, such as HSV, Yuv, xyY, etc. with different advantages and disadvantages
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.
Join the window installer's union, where prosperity is a brick throw away!
Helmut Dersch (of Panorama Tools fame) certainly posted about this before;
http://www.all-in-one.ee/~dersch/gamma/gamma.html - Interpolation and Gamma Correction
255 / 2 = 122 ???
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.
warning: it's a picture of a dude sticking his own dick up his asshole? wtf??
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 illustrates to me what I've always seen as a result of a combination of 2.2 gamma and photo manipulation - degradation of image - but I'm not expert in that - this guy is.
We shoot digital for all the commercial clients and reasons (Hasselblad w/ Sinar back).
I still use 1.8 gamma, because it sounds cool, actually, because we use a lot of Macintoshes, but never-the-less this guy makes me happy with his findings.
I can imagine if I’d just been a little bit more on the ball, so to speak, that I’d be finished by now only to be cursing him along with the rest of you, but for a different reason.
So - this fellow is a God send to me.
So, I imagine this is where I’m supposed to put in my Flickered link to show you how AWESOME I shoot.
But I don’t roll that way.
You’d be hard pressed to find but, maybe five or so released to swarming masses that is - us, basically and they’re heavily watermarked Stegoed, with an occasional Bear Trap.
But I do have Goodies.
Get from a friend [or find] a Fuji Finepix Pro S2 - S5, and this ICC profile , install, you'll be amazed.
FinePix.icc
These are very nice, also.
Ekta Space PS 5, J. Holmes.icc:
http://www.josephholmes.com/propages/AvailableProducts.html
Beta RGB:
http://brucelindbloom.com/index.html?BetaRGB.html
*The Nikon Super Coolscan 9000EN software has .icc profile problems, namely they’re out of spec with OS X 10.4.x (?) up and will have to be substituted with clones to make it work properly.
See examples below.
Nikon Scan 4.0.2 [M] /Library/Application Support/Nikon/Profiles/%_NKWide_CPS.icm /Library/Application Support/Nikon/Profiles/NKAdobe.icm /Library/Application Support/Nikon/Profiles/NKApple.icm /Library/Application Support/Nikon/Profiles/NKApple_CPS.icm /Library/Application Support/Nikon/Profiles/NKLch.icm ... ad nauseam
Header profile class is not correct.
Tag 'desc': Tag size is not correct.
Tag 'desc': Tag size is not correct.
Tag 'desc': Tag size is not correct.
Tag 'desc': Tag size is not correct.
Header connection space is not correct.
Header data space is not correct.
Header profile class is not correct.
Tag 'desc': Tag size is not correct.
Tag 'A2B0': Number of input channels is not correct.
Tag 'A2B0': Number of output channels is not correct.
Tag 'B2A0': Number of input channels is not correct.
Tag 'B2A0': Number of output channels is not correct.
If you know of someone who’s made the changes please post.
~hylas
and gegl.
seems gimp (development versions anyway) already have this solved.
I wonder how this will affect emulators. Did old computers (say, the Amiga) use a gamma of 1.0?
http://outcampaign.org/
Even R300 which was released in 2002 has bits to turn gamma and degamma on on textures and AA resolve. See here http://www.x.org/docs/AMD/R3xx_3D_Registers.pdf and search for gamma.
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 rest of the post I basically agree with: the differences are minor except in weird test images. However, if I want to adjust the brightness, I'll do that. If I edit the photo at full res and then save at lower res for use on the web, I don't want the result to look different. I wouldn't be able to tell the difference if not in swappable comparisons, but one might still look better.
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*
I don't see why this is worth defending. It's obviously incorrect, even if the errors are minor. If I resize something, the tool should just resize, not also shift brightness levels. I don't like to over-analyze or over-edit my photos, but I do want my tools do precisely what they're supposed to, neither more nor less. I like manual settings on my camera, and if I want to change brightness levels then I want that to be explicit.
In some rare cases, yes. And now I know why.
The 70 year old professional photographer tells me there is just a difference and digital hasn't made it up yet. He isn't giving up his film camera and I really can't blame him. I guess this isn't the camera's fault and it shouldn't effect them if left unedited, but it makes you question if analog devices and systems should be abandoned at the current rates.
"They confiscated everything, even the stuff we didn't steal!"
I care and I've seen this on day to day photos.
If a "save for web" or email picture function adds 22% brightness and lowers the picture contrast that sucks.
The overall error result of the "wrong" scaling is that dark areas "bleed" into adjacent light areas. Light objects shrink slightly relative to everything else in the image and dark objects expand slightly. If there are a lot of high-contrast patterns next to each other, the result of this bleed is an overall darkening of that area.
Table-ized A.I.
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)
32-bit is of course linear, thus fixing the problem.
It's rare to have anything 12 bits or more that isn't linear, and rare to have anything 8 bits or less that isn't.
16-bit half floats aren't natively supported by Intel. You can do 4 floats in an XMM register (SSE) or 4 shorts in an MMX register. Even w/o vectorization, integers and 32-bit floats are easy. Using 16-bit half floats may seem easy in some programming languages, but it's not nice for the CPU.
Where did this 2.2 gamma value come from? Is it based on some mathematical or physics truth, or based on tests of human perception?
Table-ized A.I.
In what sense is it not a scaling algorithm bug?
This affects alpha blending, including anti-aliased drawing tools.
I think people tolerate it because it's like traditional cartoons: you get a bit of a dark line around everything, more or less. IMHO, that's yucky.
Serious problems happen when you repeat an operation in the same spot. Things like a smudge tool get an odd sort of asymmetry, with black-to-white and white-to-black operations being different.
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.
Eric Brasseur, in his otherwise excellent web page on the subject writes:
Technically speaking, the problem is that "the computations are performed as if the scale
of brightnesses was linear while in fact it is an exponential scale." In mathematical terms:
"a gamma of 1.0 is assumed while it is 2.2." Lots of filters, plug-ins and scripts probably
make the same error."
That is sort of right in a sense, but the assumption that it is a problem with the scaling algorithm and worse, that it should be fixed in the algorithm are both wrong and a dangerous way to start thinking about this situation. In fact, this isn't really a bug anymore than the misuse of any tool is a bug. What is really needed is more knowledge and expertise on how to create and utilize a color managed imaging workflow.
Almost all image processing algorithms contain simple addition somewhere and for simple addition to wok as you might expect, the image encoding function must be linear. (Adding logarithms for instance actually results in a multiplication operation. That is how slide rules work. What's a slide rule? Hmmm...) Scaling involves filtering and nearly all filtering algorithms involve addition, but so does a blur, over, blend, key, mask, matte, color correction, dithering and quite a few others. This problem isn't limited to scaling operations and it isn't a actually a bug at all, but rather an education and understanding issue.
The right thing to do is to linearize your images prior to doing any kind of manipulation and keep them linear throughout the whole image manipulation process, only transforming them to something else for final delivery (or approval if that is an issue). By linear, I mean that the relationship between the luminance encoding and light is linear. You see, it isn't the image or the file that is linear or non-linear, it is that transfer function between code values and light. When I say linear, I mean that for a function f, f(a) + f(b) = f(a+b) and a*f(b) = f(a*b). Anything else is non-linear.
The problem with working with linear images is that unless you are careful and know what you are doing, your monitor being a non-linear viewing device, won't display the images correctly, so if you linearize your images, they won't look "right" on the monitor, although they will be correct mathematically. The solution to that is to employ LUT in the viewer such that linear data is displayed correctly. Photoshop can do this and has been able to do it for years. The fact that people don't understand how to use that feature and why doesn't mean that there is a bug in the scaling algorithm.
By the way, high end 2D image manipulation tools like Shake and Nuke to name two are used in the most demanding imaging application possible, motion picture visual effects. With regard to internal image processing, they presume that data is linear. They rely on the expert knowledge of the user to insure that the proper image encoding, that being linear to light is used.
Lastly, I think thinking of this as a bug in scaling algorithms and trying to fix it by revising scaling algorithms rather than recognizing that it is really a problem with image data being encoded non-linearly is a completely wrong headed approach. It only addresses one use case, that being scaling and ignores all of the other problems with non-linearity. A better approach would be to educate people as to what is actually happening, why it is happening and then just teach them to use the tools they have.
Just presuming that the input image has a 2.2 gamma and correcting for it in just the case of scaling but not in other 2D image manipulations only just serves to muddle the issue.
Ultimately, you want is a display subsystem (display card and monitor) that has been profiled and then corrected to match as closely as possible some idealized target like sRGB or Rec. 709 just to name two. The easiest way to do that i
> Ok, so he made a very informative page about it, but this is still a well known effect.
Then why is everyone doing it wrong?
You WILL assume a gamma value.
Dumb code implicitly assumes a 1.0 gamma. Most files are approximately the sRGB gamma, which is 2.2 if you ignore some oddities. Very rarely you may encounter an ancient Mac file with a 1.8 gamma.
So, if you do nothing, you're at 1.0 and sucking hard on most files.
Applying square and square root (gamma 2.0) is really cheap and easy, and it gets you a lot closer. I think you can even vectorize it in one direction.
. . . you'll probably see an error message.
Great idea using the Dalai Lama image.
wget -O - http://www.4p8.com/eric.brasseur/gamma_dalai_lama_gray.jpg | djpeg | pnmdepth 65535 | pnmgamma -ungamma -srgbramp | pamscale -filter=sinc 0.5 | pnmgamma -srgbramp | display
This isn't a bug. Don't call it a bug. It's a specific way of operation.
The results in these program differ from what a *single* person expects - and this person is not a computer graphics person. On the other hand, the results are exactly what many computer graphics people expect.
The operating domain of these scaling algorithms is a computer image. It has nothing to do with "real" things, and nothing to do with the mistaken imagination of the author of TFA.
we discovered a new way to think.
The article has seven lines of text followed a section on how to find out if your software has this problem.
I know this is slashdot but surely you could make it seven lines into an article...
No sig today...
All of the software in question had already started development before there was any kind of standardization of monitor gamma, at a time where most image formats, even if they had considered the question of how to contain information about the gamma, were written incorrectly without proper gamma information.
The standard for Apple monitor gamma was 1.6, and for IBM PC monitors it varied but was almost invariably larger.
So it was impossible for these software projects to "do it right", so they just did it the only way they could, by assuming that gray levels were linear. BTW, that was the case for NetPBM also for at least the first 10 years of its life.
20 years of image processing wasted, just like that! Spose I better start again...
Afair all modern graphics cards (DX10-11) must have the ability to handle gamma for all sampling operations, i.e. internally they must convert each contributing sample into a linear value before averaging them. BTW, the conversions are not quite log/antilog, a small part of the input range is linear!
DX10 requires these conversions to be very accurate, with at least 10-bit precision in both directions, so as long as you can live with any of the supported sampling algorithms you can just let the graphics driver do all the hard work.
If you cannot depend on the hardware, maybe because you'd like to use Sinc sampling, then it isn't too hard or expensive to do it in sw either:
I have written SSE-based sw to do these operations, which means that the conversions had to use polynomial approximations to make it possible to do multiple of them in parallel. (For a single sample at the time, a lookup table is the obvious choice: A 256-entry table of 16-bit values uses just 512 bytes, while a reverse table going from 11-bit averages to 8-bit gamma samples needs 1KB.)
Using a very simple polynomial makes it possible to convert 4 individual samples simultaneously.
Terje
"almost all programming can be viewed as an exercise in caching"
32bits doesn't automatically mean the data in the file represents linear light pixel data. I could write a png file with the data in log colorspace if I wanted to, shouldn't but I could if I wanted to. Same goes for writing data to an OpenEXR file.
Image file formats are containers of data and as Bill posted in a previous thread more often then not the colorspace encoding in files is either read wrong or ignored in the various graphics applications. And don't even get started with Apple applications doing 1.8 gamma encoding.
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...
It's already been discussed here in relation to the Gimp, but the maintainers only seem interested in fiddling with the interface. Sigh.
The PNG format does not provide for the possibility of more than 16 bits per channel.
The PNG format does not provide for the possibility of logrithmic data.
32 bits nearly always means an IEEE floating-point value such that 1.0 is white and 0.0 is black, and 1.0 gamma is used. It's seldom used in files; this is primarily an in-memory format.
Funny to see everybody pooh-poohing this effect: "oh you can barely even notice that, who cares", when it's outside their particular expertise, but when the discussion turns to flavours of Linux, or different coding methods or Star Wars trivia, the same geeks get sand all over their vaginas for even more subtle distinctions!
FWIW, I'm a graphic design professional, and I'd prefer my tools to do what it says on the box. I have little patience with "meh, it's close enough" when we are talking about MATHEMATICS where it's possible get it ABSOLUTELY correct. And if all you need to do is a gamma conversion before and after the operation, I don't buy the "too much work" argument either.
If what you say is really true, those 'annoyed' users would adapt far quicker to the correct approach, than if it were correct to begin with, and everything went to the pear shaped approach.
We should be simplifying and correcting things (starting at the hardware level, and then moving to the software layer as a last resort), not sticking with arbitrary standards.
Why OpalCalc is the best Windows calc
if I want to adjust the brightness, I'll do that.
You're fired up about this "scaling bug" because someone told you about it, not because it actually matters to you, and the above snippet proves it. Do you know what happens when you "adjust the brightness"? Do you care? Basically all brightness/contrast/levels/curves/whatever adjustments change the colors (and not for just one reason either). Image editing is much more complicated than you think it is. If the effects of non-linear gamma on scaling are news to you, you just got your feet wet. The same basic cause affects everything which combines pixel data or changes existing pixels, i.e. everything. That's why calling it a scaling algorithm bug is wrong. Before we start worrying about non-linear gamma, we should fix the clipping behavior of exposure compensation in most RAW conversion software.
Since I'm not currently in a position to do the experiment, does Photoshop do the filtering operations for scaling in a linear space if you set the "Blend RGB Colors Using Gamma..." option under the color settings? (Or does that only work for blending images?) I can understand the filtering mode being optional, because converting to a linear space and back (especially doing it properly, rather than with a gamma hack) is going to be slow for an arbitrary color space, but I'd not appreciated that Photoshop lacked the option entirely.
Mtpaint has a "Gamma Correction" check box. If you check it you get the faint picture. If you leave it unchecked you get the grey box. Not bad for an editing program that fits entirely in one uncompressed 616KB executable.
if I want to adjust the brightness, I'll do that.
You're fired up about this "scaling bug" because someone told you about it, not because it actually matters to you, and the above snippet proves it. Do you know what happens when you "adjust the brightness"? Do you care? Basically all brightness/contrast/levels/curves/whatever adjustments change the colors (and not for just one reason either). Image editing is much more complicated than you think it is. If the effects of non-linear gamma on scaling are news to you, you just got your feet wet. The same basic cause affects everything which combines pixel data or changes existing pixels, i.e. everything. That's why calling it a scaling algorithm bug is wrong. Before we start worrying about non-linear gamma, we should fix the clipping behavior of exposure compensation in most RAW conversion software.
Yeah, it's news to me that it has this impact. (I knew about nonlinear color spaces and such, but never really thought about how it impacted stuff like this — I find it interesting, but I haven't actually written software that cares that much. And now that I think about it, this bug exists in at least a fractal generator I wrote once.)
But hey, I learn lots of new things about photography. I wouldn't call myself a "serious" amateur, but I know (and care) more about the details than most people. And pretty uniformly, any time I find the camera or software is doing something complicated and automatic, I want the manual version. I use semi-automatic exposure settings more often than fully manual, but there's no way I'd buy a camera that didn't have the manual version. Similarly, I mostly want my software to just stay out of the way. For images I care about, my usual procedure is to take it correctly in the first place, and then I use software to remove noise and scale it down. Occasionally I'll adjust various color options; when I do, I basically just care about a very subjective "make it look good". I may not understand the finer points, but I understand that those tools are fussing with color curves. When I want to fuss with colors, I want that; when I want to scale the image, I sure as hell don't.
this and many other reasons are why vfx dudes work in linear light and have been for a very long time
lol... Just skip down all the way to the end of the article and scale the last image 50%:
http://www.4p8.com/eric.brasseur/gamma-1.0-or-2.2.png
I noticed this bug the other day but I thought perhaps I made a mistake somewhere. I am creating a Drupal site for photos and it has a dark background. I was just testing out the image upload and I used an unscaled image. Later I scaled the same image down to save space and re-uploaded the image. The brightness was noticeably different. It's actually very hard to tell in a lot of cases, especially with a brighter background. A dark background really makes the bug apparent.
Time makes more converts than reason
It's not really filtering. It's that the scaling is being done in the wrong color space. If you resize an image, you should convert it to linear data before using averaging and resizing algorithms, and then back to gamma-based values after.
I would take a bet that GD Image Library's JPEG compressor has that bug.
Sensationalism. This is the kind of sensationalism I used to get into, actually. OMG! GIMP antialiased lines look like ropes because they don't account for gamma properly! (I noticed that 10 years ago.)
Yeah, so what happens is that these apps scale the image with colors in luma space. In luma space, the color ramp of pixel values looks linear to the human eye. The thing is, the human eye is not linear, so it's technically incorrect to do linear math to combine pixel values in luma space.
Instead, we should be working in luminance space. Luminance is linear in terms of physical light intensity, and you can do linear math directly on luminance values and have them make physical sense.
The reason we use luma is because it's more compact to represent what you can SEE in a static image. What takes 8 bits in luma space requires 14 bits in luminance space to get the fine just noticable differences at the right end of the spectrum.
Most people who have some reasonably advanced education in graphics know ALL about this. And they also realize that it's just not worth worrying about most of the time. I've messed around with gamma-aware scaling, antialiasing, and dithering. Except for very rare circumstances, if you have fine-enough steps in your luma space, it's very difficult to tell the difference, if there even is any. Even dithering to a 6x6x6 color cube looks almost as good in luma as it does in luminance. The only situation where it's vital is if your color space is really small. For instance, if you wanted to dither a color image to a 2x2x2 color cube (8 colors), then ignoring gamma makes it look completely wrong.
I'll make a physics analogy. This guy is complaining that Newtonian mechanics is inaccurate compared to Einsteinian, except that we're dealing with speeds of 100s of miles per hour. Not going to make a noticable difference.
I work with RGB for science purposes all the time. To me the RGB levels are directly proportional to the number of photons collected. If I fuse ccd pixels then the number of photons collected is just the sum of the pixels counts. If this were my eyeball and not a photon collector then the same logic applies. If you reduce the number of pixels it's like focusing the image to a smaller portion of your retina. Each rod will collect proportionally more photons.
thus if I reproduce this image on scree so that the number of photons leaving a pixel is proportional to the RGB level then this is reproducing the image as I would have seen it.
When I go to display this on a screen, then the graphics system will naturally apply a gamma correction. This correction is there to correct for the screen phosphor response NOT the eyeball's response. It is intended to make it so that 128 has twice the photons as 64.
Thus I think the analysis is wrong. You don't want to average in gamma space. you want to average in RGB space then apply a gamma just like is being done.
I think the real problem is that when you sum pixels their not only is the sum larger but the dynamic range of the image pixels is larger. Thus if you need to compress this back to 8 bit dynamic range you have a problem.
So my conclusion is the problem is NOT that you want to do
pixel^gamma -> average regions -> pixel ^(1/gamma)
but instead average lineraly
pixel^gamma -> sum regions -> ??? some how compress dynamic range ????
I don't know what the correct compression is. But it makes no sense to me to non-linearly sum things that correspond to actual photon counts.
SO either I misread the article (don't think so), or the article is right about there being an overall dynamic range compression issue but wrong about the solution, or I am not understanding some key concept here.
can someone explain to me what I'm missing?
Some drink at the fountain of knowledge. Others just gargle.
(This may be off topic, in which case, please ignore.) I was wondering if rgb should be converted to linear before computing color distances? And, what is the better way to compute color distances (since the euclidean distance of rgb values seems like a really bad choice).
He is right that the eye has a logarithmic response. Unfortunately, most digital sensors have a linear response. In this sense he is wrong. If you scale sensor data, the linear scaling is right. I suspect his anomaly is due to overflow in the linear calculation and the fact that the logarithmic calculation won't overflow.
If you have a camera that can output a raw data file then, yes, the values will be linear, but for standard JPEG (or video) output, the camera will have mapped the linear data to non-linear.
Thank you, that is a very clear explanation of this problem and how gamma affects output. I can finally visualize what is being talked about here :)
zomg!
His inversion routine used on every other line in the original image is flawed!
It's working in linear space (gasp) otherwise the resulting images would have been switched.
(tongue in cheek)
Is any of the code you have written available under a free license? I realize that what you have written for geological analysis software is likely to be kept private, but perhaps there's other bits of code which could be helpful to the rest of the world?
Finally! A year of moderation! Ready for 2019?
Here's a snippet of code I wrote 3 years ago: /*
* The first part is semi-magic, it depends on doing a small amount
* of fast bit-twiddling operations directly on the fp bit pattern:
*
* Treat the fp value as an Int
* Take the top 16 bits of the mantissa and
* the last exp bit, adjust that bit:
* Square it for a second-order correction:
* The fp exponent is nearly a log:
* The 2nd order term must be scaled by 5/8196
*/
inline int rr_log2(float f) // The float->float code uses the function above, converting // back to float and scaling by 2^(-23):
{
int e = AS_INT32(f);
int m = ((e >> 7) & 0xffff) - 0x8000;
m *= m;
e += (5>= 13;
e -= m*5;
return e;
}
inline float RR_LOG2(float f)
{
int e = rr_log2(f);
float t = (float) e * (float) (1.0f/(65536.0f*128.0f));
return t;
}
Terje
"almost all programming can be viewed as an exercise in caching"
I don't see why this is worth defending. It's obviously incorrect, even if the errors are minor. If I resize something, the tool should just resize, not also shift brightness levels. I don't like to over-analyze or over-edit my photos, but I do want my tools do precisely what they're supposed to, neither more nor less. I like manual settings on my camera, and if I want to change brightness levels then I want that to be explicit.
It's not a matter of defending it. It's a matter of whether or not it's significant in most real world photography.
It's also not necessary to look at this is as incorrect. You can think of it as deviations on an algorithm. In other words what they are "suppose to" do is open to some interpretation. There are in fact several common algorithms for resizing. If you care so much let me ask you how often you change to a different algorithm in the dialogs? Do you choose your software based on the options available in a resizing dialog? Or is this noteworthy but being blown way out of proportion?
These posts express my own personal views, not those of my employer
"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."
And yet, for the last 20 years, the porn I look at is crystal clear!
Who wrote the original buggy code and who all copied it?
This may be a real bug and might have come from some wrong/incomplete understanding that existed 20 years back. But somehow I can get the above question out of my mind...
Have any images exploded due to this glitch? When will the recall be announced?
Excellent, but it's difficult to actually use it in code without a license... This code is so short that some can argue that copyright does not apply, but it is highly non-trivial and so I don't think that argument would be likely to hold up in court.
The same applies to the snippets of code you sometimes publish on comp.arch: Very interesting, but there's no mention of a license.
Finally! A year of moderation! Ready for 2019?
I'm perfectly happy, and assume, that any code snippets I post will be picked up and reused. If whoever does this includes a comment that I wrote it originally, that's all I expect.
Terje
"almost all programming can be viewed as an exercise in caching"
From the gamma FAQ:
On the other hand, if your computation involves human perception, a nonlinear representation may be required. For example, if you perform a discrete cosine transform on image data as the first step in image compression, as in JPEG, then you ought to use nonlinear coding that exhibits perceptual uniformity, because you wish to minimize the perceptibility of the errors that will be introduced during quantization.
The usual concept is "delta-E", which tries to approximate color distance, but how accurate it is depends on the color space you are calculating with. http://www.colorwiki.com/wiki/Delta_E:_The_Color_Difference
Join the window installer's union, where prosperity is a brick throw away!
Who is that bald dude? I wanted my lines in the smaller image, not him!