That is kind of a "please proof-read an articles conclusion"-question. Some time ago I found this page: Gamma error in picture scaling.

I grasp the point, that the luminosity-curve is not linear and that some (most) software does assume a linear scale and thus resizes badly.

But as I do not have so much experience in the field of image-manipulation / gamma / etc (just starting with the fine points of post-processing), let me ask you: is this guy right about this error during resizing? Is his method to determine erroneous software correct?

  • The link is to a highly technical article that is less about photography than about algorithms used in photo manipulation software. I'd say this was off-topic. – NickM Jan 28 '11 at 12:57
  • 3
    Might be. But resizing is part of my picture-processing. I often batch-resize pictures before giving them out and wonder if this gamma-error a negative impact on them I did not really notice until now. (edit: I even resize for first evaluation, as my screen is only 1920x1080 and I like to evaluate full-picture instead of 100% zoom. So first sorting of pictures itself is impacted.) If the author is right, I'd better have a look into finding alternative SW. – Leonidas Jan 28 '11 at 13:21
  • Yes, the article is correct. But it is very hard to notice the error on images that aren't contrived - that's why it's so widespread in common software. – Mark Ransom Sep 27 '17 at 2:36

Before even looking at the article, I say that there certainly is some amount of skew in levels when resizing a JPEG image. This is due to the fact that the RGB values are obtained from the RAW after a gamma (non-linear exponential) correction was applied to the RAW pixel values. Then, while scaling, values from adjacent pixels are averaged through some method (linear, cubic, lanczos) in a manner that is different from the specific gamma correction. This averaging is a linear operation by its nature, and applying it over the non-linear gamma correction introduces the skews.

That said, I think if you scale the RAW itself, assuming it's done properly before the gamma correction, you should be fine. I am not sure how the various software do it, though.

BTW, the RGB planes themselves are obtained by interpolation of near pixels on the RAW matrix - this is called the Bayer pattern demosaicing.

  • Interesting option to find a SW that scales (interpolates) the non-corrected RAW (more/again) to the sizes I use and applies the gamma later. – Leonidas Jan 28 '11 at 14:51
  • @Leonidas - it looks like in the article you provided there is a list (albeit an old one) of "correct" software: 4p8.com/eric.brasseur/gamma.html?#solutions – ysap Jan 28 '11 at 19:11
  • Yes, there is. Today I already used the first, pamscale readily available with Linux/cygwin. I overlooked that RawTherapee is part of the list - that might implement the solution you suggest. But: question remains if there really is this problem on doing rescale on JPG. I do not have photos like his example from the bugs eyes readily available to test the idea. – Leonidas Jan 28 '11 at 20:26
  • @Leonidas - I guess you can download the sample images from the article and use it in whatever processor you use to test for correctness. Also note that the solution I suggested is one possible approach, and is relevant only when you have a RAW processor (LightRoom is in the list, so maybe it is an OK software?). What the writer seems to do (I did not read the whole of it yet) is first do the inverse gamma transform (effectively returning to the linear RAW space), interpolate and last gamma transform again. – ysap Jan 28 '11 at 20:50
  • What do you mean "if he is right"? Mathematically? Sure he is! About the setup? Well, this is up to you to check. – ysap Jan 28 '11 at 21:14

This article is technically correct. Easiest way to verify is to try resising white-and-black checker patterns. All software I tried shows abrupt luminosity change when downsising checker pattern by factor of 2, and simple logic suggests that there should be no luminosity change. And if you try gamma correct with 0.45, then resize, then correct with 2.2, you will have expected luminosity like original pattern had.

But in reality it makes much less sense than in that specifically crafted pictures. Even "real life" illustration from the article is given in very contrast situation (a dragonfly photo on dark background)... and difference is still not apparent until both correctly and incorrectly resized pictures are shown side-by-side. My laptop screen makes more difference in these pictures from imperfect backlight and angles.

Things could change if one would use wider arithmetics (16 bits per channel), but software tends to use non-linear transfer function for high color depths, so this case is gamma correct. I didn't checked Photoshop for this, but I've tried to build gimp 2.10 from git, and it done things properly for high color depths.

The raw processing software, where it makes sense, heavily uses non-linear curves, too (starting with camera profile and white balance) and is generally color profile aware. For example darktable converts to Lab early and does most work in that color space, so said article isn't applicable to it at all.


Simply take the picture he published, resize it with your software and check the result.

Photoshop introduced the gamma correction about 3 years ago, other applications have an option (IrfanView), other applications still don't use gamma at all.

You have to check yourself, the article you linked is based on real issues on real applications, not theoretical.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.