What's the case for gamma today?

[digitaldog]

<p>We have to end up with gamma encoded data to print and view the data (certainly in non ICC aware applications). We have to move from scene to output referred! As long as the heavy lifting in the converter is happening in a linear TRC (which due to the data, it has to), as long as you render the gamma corrected data in high bit (even 24 bit depending on the output, say the web), why does anyone need to be dealing, post raw conversion with a linear data set and linear working space? The display is gamma corrected. The printers are gamma corrected. We have to convert to make the print. We can do this directly from linear to gamma corrected data in Lightroom or any converter that has output facilities. Post processing is just that, it doesn’t need to be (some may argue shouldn’t be) in a linear color space. </p>

[jack_hogan]

<blockquote>

<p>why does anyone need to be dealing, post raw conversion with a linear data set and linear working space?</p>

</blockquote>

<p>Fair enough. However, since the data STARTS linear the real question (and mine from the beginning) is why feel the need to convert it by 'default' into something else - unless you have to. In the meantime you can post process to your heart's content with the least noisy, most accurate, densest, highest 'resolution' etc. data you are going to have.</p>

<p>Let me summarize the minuses, as I understand them, of converting to a gamma corrected color space off the bat:</p>

<ul>

<li>Every time you apply gamma you (perhaps imperceptively) amplify noise in the shadows and quantize the highlights.</li>

<li>Every time you convert to a different color space, you need to go through a gamma round trip</li>

<li>Many arithmetic operations on color values need to be performed on linear data, forcing a gamma round trip (if not already in a linear color space)</li>

<li>Many operations are more complex in gamma</li>

<li>More operations mean slower processing</li>

</ul>

<p>Now the pluses of applying gamma off the bat:</p>

<ul>

<li>Maybe it will be needed sometime in the future. Maybe not.</li>

</ul>

<p>It seems pretty weak to me. Are there other pluses?</p>

 

[digitaldog]

<blockquote>

<p>However, since the data STARTS linear the real question (and mine from the beginning) is why feel the need to convert it by 'default' into something else - unless you have to.</p>

</blockquote>

<p>Actually the data starts out with something that doesn’t resemble an image. But to answer your question, which is discussed in my ICC white paper, its because we need output referred data. </p>

<blockquote>

<p>Every time you apply gamma you (perhaps imperceptively) amplify noise in the shadows and quantize the highlights.</p>

</blockquote>

<p>The key word here is <em>perhaps</em>. Its a bit like the argument that when you edit an image, due to rounding errors, you degrade the data. If your image doesn’t need editing fine. But the reason we have tools like Photoshop and the like is we <strong>do</strong> need to edit the numbers. A bit of data loss is far preferable to an image appearance we don’t like or want. Do it in high bit, the rounding errors (which are still there) are moot, we don’t see it. Same with the gamma conversion you point out. We need output referred data. If you want pristine gamma 1.0 data, fine but if it looks awful, what good is it? IF you ever hope to print it, you are going to undergo at least one conversion anyway, the gamma is going to be different as will all the resulting values (and gamut). </p>

<p>There may be misses but they are far less an issue than leaving the data alone. We have to print the data, we have to view it (often without the benefit of a profile that defines the 1.0 TRC nature of the data). </p>

[jack_hogan]

<blockquote>

<p>If you want pristine gamma 1.0 data, fine but if it looks awful, what good is it?</p>

</blockquote>

<p>It would be no good. However, you can make whatever changes are needed to make it look good on linear data, just as well (better, as it turns out) as on gamma encoded data - without all the negative side effects. So why convert it to start with?</p>

<p>If you wrote a white paper on this subject, I would be interested to read it. Where can I find it?</p>

 

<blockquote>

<p>Do it in high bit, the rounding errors (which are still there) are moot, we don’t see it.</p>

</blockquote>

<p>Maybe, maybe not. It is not just the rounding errors. However, in linear you do not have this problem, so why bring it on ourselves?</p>

[digitaldog]

<blockquote>

<p>However, you can make whatever changes are needed to make it look good on linear data, just as well (better, as it turns out) as on gamma encoded data - without all the negative side effects. So why convert it to start with?</p>

</blockquote>

<p>What negative side effects? Again, it has to end up gamma corrected for output to anything but the above scenario (a display) and with an embedded profile, viewed within an ICC aware app. For that one, arguably far from demanding output, what’s the big deal? What gain will you see on-screen from this more “Pristine” data? </p>

[jack_hogan]

<blockquote>

<p>What negative side effects?</p>

</blockquote>

<p>IMHO the best you can do starting with gamma encoding vs linear is break even in the end. In linear you may actually win. The downside (from a few posts up):</p>

<ul>

<li>Every time you apply gamma you (perhaps imperceptively) amplify noise in the shadows and quantize the highlights.</li>

<li>...</li>

<li>Many arithmetic operations on color values need to be performed on linear data, forcing a gamma round trip (if not already in a linear color space)</li>

<li>Many operations are more complex in gamma</li>

<li>More operations mean slower processing</li>

</ul>

<p>Am I missing something?</p>

[digitaldog]

<blockquote>

<p>Am I missing something?</p>

</blockquote>

<p>I think you are. First, the bullet points such as “you always amplify noise” needs to be shown and proven (I’m not saying its never the case or always the case, I think it needs to be shown). And as I’ve tried to illustrate, you have to end up with gamma corrected data eventually unless your only output is to the color managed display with an embedded profile with the output going to an arguably not very demanding device (a display). You have to convert to the printer output device. And its not slower depending on what app you do this.</p>

[Tim_Lookingbill]

<blockquote>

<p>• Every time you apply gamma you (perhaps imperceptively) amplify noise in the shadows and quantize the highlights.</p>

</blockquote>

<p>I don't see this on the display or on any prints. Gamma is only applied once after the conversion from linear Raw to display for web viewing (2.2 gamma). The ROI in time and money you're advocating to keep the data in a linear state isn't worth the hassle.</p>

<p>As for slower processing for complex operations converting to 1.8 (ProPhotoRGB) or 2.2 (AdobeRGB/sRGB) gamma, I don't see this either. I clocked converting out of ACR and Raw Developer to be about 6-8 seconds per image on average on a 2004 1.8 ghz G5 iMac. I'm sure it's much quicker on a 2010 system.</p>

[jack_hogan]

<blockquote>

<p>amplify noise” needs to be shown and proven</p>

</blockquote>

<p>Shown: did you try the experiment I suggested a few posts up? Did you not see noise jump out at you after the first two or three iterations? It was building up from the very first time. As far as proof is concerned, it was done a few centuries ago, but you can prove it to yourself just by reading the equation. This is the way that Burger and Burge read it in 'Digital Image Processing', 2008:</p>

<blockquote>

<p><em>"The tangent to the function at the origin is thus either horizontal (gamma>1), diagonal (gamma=1), or vertical (gamma<1), with no intermediate values. For gamma<1 this causes extremely high amplification of small intensity values and thus increased noise in dark image regions. Theoretically, this also means that the gamma function is generally not invertible at the origin."</em></p>

</blockquote>

<p>Why else would sRGB et. al. linearize the function near zero? How does ProPhotoRGB or aRGB deal with it?What? They don't?</p>

<blockquote>

<p><em>Am I missing something?</em> I think you are.</p>

</blockquote>

<p>What am I missing, specifically? Again not a rhetorical question.</p>

 

[joe_c5]

<blockquote>

<p>Why should Lightroom (which by some accounts keeps data linear until the end) need to apply gamma before passing data to Photoshop or another post processing program?</p>

</blockquote>

<p>It shouldn’t need to. I am not sure why Lightroom allows any color space to be used for an export but limits the choices for external editing to sRGB, Adobe RGB or ProPhoto RGB.</p>

<p>I do all (well, most, occasionally I just don’t care) resizing and sharpening in either Lightroom or 16-bit gamma 1.0 space. Doing the same in a gamma 2.2 space would give incorrect results. Can anyone confirm that the latest version of Photoshop handles this automatically without extra steps?</p>

[jack_hogan]

<blockquote>

<p>I don't see this on the display or on any prints.</p>

</blockquote>

<p>All right, so failing to find a reason to support gamma, the argument is turning to 'I cannot see the difference, so I might as well pretend that it is not an issue'. Go back to my first post. My question is not why linear, but why gamma. Until proven otherwise, gamma can only be worse than linear because it is a distortion of linear data.<br /> Why is Lightroom, developed in the last ten years, based on a default linear space? If Photoshop were to be written today, as opposed to twenty years ago when Jpeg and 8 bits ruled, would it be based on a default gamma corrected color space? I haven't heard one reason in this thread that would support this view.<br />.<br>

Thank you Joe_C. What gamma 1.0 space do you use?</p>

[digitaldog]

<p>Because <strong>its not an issue</strong>. The only time it can even <strong>be</strong> an issue is on-screen display. You simple can’t have a linear data file go to an output device. I don’t know why this isn’t yet sinking in. <br>

I’ve got an 8-bit display path currently (because I’m on a Mac despite the high bit data, display panel etc). The largest image I can display on my 30” is 1920x1200, to a wide gamut (97% of Adobe RGB (1998)) display. That’s the most demanding output device I can view a gamma 1.0 image. And as Tim says, we don’t see anything at all useful about viewing this data in 1.0 TRC. Once we have to print a 30x40 on a far higher resolution output device with a far wider gamut, using way more pixels, its gamma corrected, there is no way around that. </p>

<p>I’d think you’d be more upset that on this high bit, linear preview of data on a display, you either have to sample it way down to fit at 1:1 or live with the “data loss” (and there is a visual degradation) when you zoom out of a document that’s 5000 pixels wide so it fits fill image on that 30” display. </p>

[joe_c5]

<blockquote>

<p>What gamma 1.0 space do you use?</p>

</blockquote>

<p>I use whatever primary colors I was using to begin with. Usually that tends to be linear sRGB, which doesn’t seem like a good name. Anybody know if there is a real name for such a color space?</p>

<blockquote>

<p>Because <strong>its not an issue</strong>. The only time it can even <strong>be</strong> an issue is on-screen display. You simple can’t have a linear data file go to an output device. I don’t know why this isn’t yet sinking in.</p>

</blockquote>

<p>I have to disagree. Lots of software performs important operations incorrectly in gamma space. Is the latest Photoshop any better? Up through at least CS2 it did not.</p>

[jack_hogan]

<blockquote>

<p>You simple can’t have a linear data file go to an output device.</p>

</blockquote>

<p>I understand this very well, as you can read in my first few posts. My question, which you are not addressing, is why move to a gamma corrected color space when already in a linear color space with said advantages (until proven otherwise). <br>

'You are going to have to apply gamma in the end' is not a satisfying answer in the same way that hearing 'we are all going to die in the end' will not preclude me from living a good life until then.<br>

Why isn't there a gamma 1.0 working color space for photographers in 2010? If it ain't broke don't fix it?</p>

[digitaldog]

<blockquote>

<p>I have to disagree. Lots of software performs important operations incorrectly in gamma space. Is the latest Photoshop any better?</p>

</blockquote>

<p>Again you are missing the point, the data has to go gamma corrected for output. <br>

And what do you mean (and what proof do you have) when you state <em>Lots of software performs important operations <strong>incorrectly</strong> in gamma space. </em>Incorrectly?</p>

[jack_hogan]

<blockquote>

<p>I use whatever primary colors I was using to begin with. </p>

</blockquote>

<p>@Joe C: Ah, of course. And where did you find (or how did you 'make') these color spaces?</p>

[digitaldog]

<blockquote>

<p>My question, which you are not addressing, is why move to a gamma corrected color space when already in a linear color space with said advantages (until proven otherwise). </p>

</blockquote>

<p>My question, which you are not addressing, is why <strong>NOT</strong> move to a gamma corrected color space when its going to have to be in such a color space anyway. <br>

IF you want to work in a linear gamma space until you print, use Lightroom and print from Lightroom. You are not editing pixels anyway, you’re making metadata instructions for rendering FROM linear to gamma corrected data.</p>

<blockquote>

 

<p>Why isn't there a gamma 1.0 working color space for photographers in 2010? If it ain't broke don't fix it?</p>

 

</blockquote>

<p>Because there’s no reason OR you can do so with LR or you can attempt to get linear data with a profile out of some RC (not ACR or LR). <br>

You are suggesting a solution in search of a problem, the problem doesn’t exist. </p>

[joe_c5]

<p>If an image is resized to be smaller, and do so in gamma 2.2 space, the resized image will be darker than the original image. Resizing up will be wrong too, just I cannot remember whether it ends up too light or too dark. Whether this is objectionable is a matter of debate, but it is provably incorrect.</p>

<p>Sharpening has similar issues, as do others, just resizing and sharpening are two easy ones to see the difference because they are not meant to change the overall brightness.</p>

<p>Some examples can be found at http://www.4p8.com/eric.brasseur/gamma.html.</p>

<p>I have verified this myself in some software, but do not have Photoshop CS3, CS4 or CS5 to see if Adobe ever addressed it. The issue has been around as long as digital image editing has, so clearly they have not been in any hurry.</p>

[jack_hogan]

<blockquote>

<p>why <strong>NOT</strong> move to a gamma corrected color space when its going to have to be in such a color space anyway. </p>

</blockquote>

<p>Andrew, between capture, fixing the picture to your liking, post processing, and saving the image for posterity there are millions (billions?) of operations on your data which are best performed on LINEAR data (just as an example, color operations). Then, and only then, if you need to, you can apply a gamma curve for output.</p>

[digitaldog]

 

<blockquote>

<p>Andrew, between capture, fixing the picture to your liking, post processing, and saving the image for posterity there are millions (billions?) of operations on your data which are best performed on LINEAR data (just as an example, color operations). Then, and only then, if you need to, you can apply a gamma curve for output.</p>

</blockquote>

 

<p>So instead of proving this, we are to take that all image processing applications are just doing these functions wrong? is Timo back? </p>

[roger_smith4]

<p>Jack, based on what evidence are manipulations best performed on linear data? Are you referring to raw digital captures, scanned film or both?</p>

<p>It sounds like you like the Lightroom/ACR way of working.</p>

[joe_c5]

<blockquote>

<p>And where did you find (or how did you 'make') these color spaces?</p>

</blockquote>

<p>For linearized sRGB and AdobeRGB I just downloaded two I found somewhere since it was easier than making them. If I ever needed to publish anything in these color spaces I would find a way to make my own so as to avoid any copyright issues with the icc profile.</p>

<p>I am afraid I do not know exactly how I would go about it. Worst case I could write them with a copy of the ICC spec and a hex editor.</p>

[digitaldog]

<p>Pretty easy to make them (or any variant). Select the original working space in Photoshop’s Color Settings, toggle to Edit. You’ll see the WP, TRC gamma and primaries, just edit the TRC and save as a new profile out of PS.</p>

[jack_hogan]

<blockquote>

<p>So instead of proving this, we are to take that all image processing applications are just doing these functions wrong?</p>

</blockquote>

<p>Now now, don't change the subject. Joe C is correct, some programs get lost in the complexities of gamma, but nobody is saying that all image processing applications are wrong. However, what seems to be possible in 2010, which was not possible only a few years ago, is working in a linear color space without the limitations of the past (not enough bit depth, memory or processing power). So now that we can, why settle for second best?</p>

<p>Thanks for the Gamma 1.0 making tip, Andrew.</p>

[joe_c5]

<blockquote>

<p>So instead of proving this, we are to take that all image processing applications are just doing these functions wrong?</p>

</blockquote>

<p>Please see above. I and others have proven that many of them were wrong. If one values correct functions, it might be worth quickly testing whatever software one uses.</p>

<p>This image from the end of the link I posted is great, try scaling it down 2:1 and see what happens.<br /> http://www.4p8.com/eric.brasseur/gamma-1.0-or-2.2.png</p>