Gorecki83 Posted February 24, 2010 Share Posted February 24, 2010 I just found this on Slashdot: http://tech.slashdot.org/story/10/02/23/2317259/Scaling-Algorithm-Bug-In-Gimp-Photoshop-Others Is it possible that Paint.NET also suffers from this bug? And if so, is it fixable? Regards, Gorecki Link to comment Share on other sites More sharing options...
cryoknight Posted February 24, 2010 Share Posted February 24, 2010 I have tested it, and Paint.NET does indeed have the same bug. Link to comment Share on other sites More sharing options...
Rick Brewster Posted February 24, 2010 Share Posted February 24, 2010 There isn't really a bug. That article is partly sensationalism. Mathematically it has many true statements in it, but the problem isn't nearly as profound as is claimed. Gamma is a multivariable function involving the image source (camera), image file, and display/configuration. Some images don't even specify their gamma scale, and many monitors are incorrectly configured. Making assumptions at any point ends up ruining things, and adding lots of configuration options (e.g., "assume gamma of [x] 1.8 [ ] 2.2") can just add confusion. Resampling methods in Paint.NET, such as bilinear and bicubic, do not take gamma into account. They use a linear scale, as correctly stated in that article. However, it's not always clear what gamma scale should be used. Even if the image says it has a gamma of "A", and the monitor says "B", there's really no guarantee that these values are correct. Or, even if it's correct for my monitor then it'll be wrong when I send it over to your computer. Or, even if you apply consistent post-processing only when displaying the image, some other tool along the chain will mess it up. For example, if the Win7 Photo Viewer is correctly adjusting for image vs. monitor gamma (which I think it does), and you take a screenshot (Print-Screen), then that gamma information is not stored in the clipboard. So you get runaway gamma application as image data moves from tool to tool. The solution could be worse than the problem in that case. It's kind of a darned-if-you-do-darned-if-you-don't situation. The Paint.NET Blog: https://blog.getpaint.net/ Donations are always appreciated! https://www.getpaint.net/donate.html Link to comment Share on other sites More sharing options...
Gorecki83 Posted February 24, 2010 Author Share Posted February 24, 2010 @Rick: Thanks for the interesting explanation! Link to comment Share on other sites More sharing options...
Rick Brewster Posted February 27, 2010 Share Posted February 27, 2010 Also, worth pointing out is that the article itself may not even be correct. He talks at long length about using gamma of, say, 2.2. However, reading up on sRGB at Wikipedia shows that a non-constant/non-linear gamma exponent is actually correct. Which of course makes things even more difficult and worse. 2.2 Actual sRGB The Paint.NET Blog: https://blog.getpaint.net/ Donations are always appreciated! https://www.getpaint.net/donate.html Link to comment Share on other sites More sharing options...
BmB23 Posted March 17, 2010 Share Posted March 17, 2010 Eh, isn't it as simple as assuming inputs are linearly corrected in sRGB, doing the processing as normal but all outputs gets corrected back into linear-for-sRGB? So even if you take a screenshot of a corrected image, it will be corrected for sRGB, and applying the darkening correction will still be correct. If input and output corrections are equal you are not any worse off than without any corrections whatsoever, but all processing and effects now appear correctly. To put it differently, the problem is with "2+2=10", too dark results from effects and runaway brightness in add operations for example. Correcting for that is the important bit (2.2 is a nice approximation, and probably what even your monitor assumes, but actual srgb compliancy never hurts) and as long as inputs (loaded images, colour pickers etc.) are inversely corrected everything will be as consistent from start to finish as if there was no correction. So the problem of overcorrection from already corrected sources doesn't exist any more or less than it did before, and you don't have to care about what the colour space of the input is any more or less than before. (Although abiding by the colour space specified in image metadata would be a good idea surely? Even if it could be incorrect.) The only problem I see would be that gradients would now look odd, since physically linear gradients don't look all that gradient actually. But that's an issue of simply changing the gradient to produce an overcorrected version of itself no? Link to comment Share on other sites More sharing options...
BmB23 Posted March 17, 2010 Share Posted March 17, 2010 Now that I think of it, isn't sRGB for the web only? Whereas the computer and OS simply operates in the 2.2 space of the CRT monitors of olde? Of course there's more variation across individual LCD monitors than that since they aren't as simple in that respect. But 2.2 is the ideal I believe. So in that case it's not actually wrong to assume 2.2 for the output. And then simply embedding 2.2 as the gamma in the metadata? I'm not sure, you'd have to ask someone who knows more about these things than I do. Link to comment Share on other sites More sharing options...
Rick Brewster Posted March 17, 2010 Share Posted March 17, 2010 Eh, isn't it as simple as ...... No. The Paint.NET Blog: https://blog.getpaint.net/ Donations are always appreciated! https://www.getpaint.net/donate.html Link to comment Share on other sites More sharing options...
Recommended Posts