Gamma encoding revisited

Discussion in 'Digital Darkroom' started by frans_waterlander, Apr 2, 2012.

  1. I've just read through 10+ pages of Jack Hogan's post of November 2010 called "What's the case for gamma today?" And I was amazed at how Jack tried to get answers but never seemed to get them to his basic question. Many discussions on photo forums and articles on the subject of gamma encoding seem very flawed or misleading to me, so let me state what I very much believe to be the case and envite your feedback.
    This is what I believe to be true:
    a) gamma encoding was introduced in the 1940's to correct for the non-linear response of CRT's in TV's
    b) gamma encoding has nothing to do with the eye's non-linear response
    c) LCD monitors' natural response is far more linear than CRT monitors
    d) LCD monitors' calibration to gamma 1 requires way less correction than for gamma 2.2
    e) If we started from scratch, it would make oodles of sense to process camera output linearily without gamma encoding, calibrate our LCD's to gamma 1 and let the printer drivers translate to whatever is needed to get a linear print
    f) Since we have an enormous legacy of gamma encoded images/videos and programs/monitors expecting gamma encoded input, it will take a revolution to do the gamma 1 scenario
    g) gamma encoding/downsampling to 8-bits makes for small files and fast transmission, but degrades images to barely acceptable, particularly in the shadow areas
    h) as a side-benefit, gamma encoding done correcly lowers the steps between brightness levels in the shadow areas where our eyes are most sensitive to brightess changes and increases step sizes in the brightest areas, where our eyes are the least sensitive
    i) only image files of 12-bits or more per color can be gamma encoded/downsampled to 8-bits with reasonable shadow quality; any lower bit depth of the original image file will result in nasty artifacts in shadow areas due to rounding/quantization; the lower the original image file bit depth, the worse the artifacts
    I have spreadsheets and charts to show the step size changes and artifacts caused by gamma encoding image files of various bit depth, from 8-bit through 12-bit and at a theoretical infinite bit depth.
    Your feedback will be tremendously appreciated.
     
  2. Your feedback will be tremendously appreciated.​
    Don't have a clue on what to add to what you've already lined out, Fran. I don't see any evidence of added benefit or that it's worth the hassle in changing something that's been working fine for at least a decade in digital photography.
    BTW where the heck you been? Haven't seen any of your postings here for quite some time.
     
  3. Tim, some people, including me, wouldn't necessarily agree that gamma encoding works fine. The benefits of not-encoding/linear gamma would be greatly simplified image editing programs, less damage to image files -although that damage may not be visible to most people when working with 12 or more bits per color - easier LCD calibration with less loss of levels, and a more logical approach that would be easier to understand. Right now many people believe, in error I may add, that gamma encoding is needed because of our eyes' non-linear response and that it somehow creates a "perceptually uniform" work space. Most articles that I've been able to find reflect that erroneous believe, even from some people very respected in the field of digital photography. And not many people, it seems, have a solid understanding of the issue of modified step sizes with gamma encoding.
    I've been busy developing some woodworking skills (turning wood objects on a lathe) and writing a book.
     
  4. Frans, you are completely right — there is tons of contradictory information floating around. I'm far from an expert and I'm happy to be corrected, but I think there are a couple subtle issues here.

    It's my understanding that gamma encoding originally was not used to compensate for non-linear CRT response (a
    common misconception), but to improve performance given limited computational 'bandwidth.' Gamma encoding
    allows one to use lower-bit data more effectively by aligning them more closely to human perception in effect using bits
    were we can perceive them rather than where we can't. So it IS related to the eye's non-linear response, just not in
    the way many people think. It's a process aimed at improving performance not perception.

    We have enough computer power these days that we could spare the memory to encode linearly, but I'm not sure
    it's really a simplification. You need to either go to floats or high-bit data to keep the same quality. To me, it
    seems simpler to add a little exponent from time to time especially given the unrealistic requirement to change
    entrenched workflows in order to make a linear encoding work globally.

    Of course there are plenty of people working with linear data, especially in the 3D rendering field, so it's not
    unthinkable.
     
  5. It's about the look of the final image. It's always been about that from the very beginning.
    Show me proof in the form of an image that the way things have been working need to be retooled for linear encoding.
    I have discovered one aspect of working on linear data in ACR in a gamma encoded output space (mine the 1.8 gamma ProPhotoRGB) near the black point that's had me scratching my head. Jeff Schewe suggested this tip for gaining extra shadow definition by using combinations of Black point adjust, Fill and the bottom slider on the Parametric curve.
    Doing this using only Point Curve tweaks wouldn't work because for some reason the point nodes representing what I'm seeing in shadows down to the black point wouldn't respond. It's like the levels near absolute black are beyond the black point located on the Point Curve.
    Below is a demonstration of what I'm talking about in trying to add definition to shadow detail in shaded foliage. The left side looks sort of flat and murky while the corrected side with the added adjusts looks as if it's been sharpened which it hasn't. I can only assume the software has been engineered to deal with this mapping mismatch between what's seen on screen and where it actually shows up on an adjustable curve.
    00aDyS-455223584.jpg
     
  6. It's about the look of the final image.
    This, of course, is a sensible point of view from a photographer or retoucher. There is another point of view — that of the developer or someone who spends time making efficient workflows. I think the point Frans is making is that we could get the same or marginally better final images with considerably less complication if we abandoned gamma encoding. Gamma encoding has always been confusing and a source of errors for developers. Of course it's only less complicated after the messy business of changing the entire world.
     
  7. @Mark: Gamma encoding has been used since the 1940's to correct for non-linearity of CRT's used in TV's. Rather than add cost to millions of TV's to correct for this non-linearity, they choose to add cost to hundreds of TV broadcasts. The need for sending image information in large quantities to remote locations didn't arise until decades later and when that did happen, gamma encoding offered the side-benefit of allowing data to be compressed to 8 bits with preservation of detail in the shadows to some degree.
     
  8. There is another point of view — that of the developer or someone who spends time making efficient workflows.​
    Oh please, please, please... show me how this can work for creating efficient workflows. I am all for that. I just wish it was for creating efficient workflows for the person editing the image as I just did. You don't know how much time I spend fixing things like I demonstrated above which can't be applied to all images. There's no one size fits all approach. A developer only has to fix one thing, their software. Wow! If I only had it that easy.
    You want to talk about efficient workflow? Try editing 1000 images to look as good as THEY SHOULD coming straight from the camera. Why don't we talk to the camera manufacturers and get them to solve this. They are the source, you know, of every digital camera image.
     
  9. Tim: The look of the final image is one thing; how we get there is a totally different story and a twisted story it is! Does gamma encoding allow for more or less acceptable compression to 8 bits for marginal quality images to be sent to remote locations? Absolutely. But for higher quality work, gamma encoding has only drawbacks: rounding/quantization losses when encoding the image,when editing the image and when decoding the image; more complicated image editing programs; more drastic corrections to LCD monitors to force a gamma 2.2 on them, rather than make minor corrections to their inherent gamma which is much closer to 1 than to 2.2. Rounding/quantization losses are not a problem for most people when working with higher bit depth, but editing program complications and LCD issues are the real biggies here.
    I"m kind of at a loss with your editing example as it looks to me that you have darkened the shadows in both cases and that couldn't possibly help to get more detail in the shadows.
     
  10. But for higher quality work, gamma encoding has only drawbacks: rounding/quantization losses when encoding the image,when editing the image and when decoding the image;​
    Show me this happening in a high quality image. Prove it!
     
  11. I"m kind of at a loss with your editing example as it looks to me that you have darkened the shadows in both cases and that couldn't possibly help to get more detail in the shadows.​
    So much for consistent, calibrated display standards, right? And you want to retool everything to accommodate that techno tower of babel?
    On my calibrated display the right side has more definition and clarity. In fact I went back and tweaked the point curve and grabbed even more definition and clarity. If you have an easier, faster way of doing this with 1.0 gamma output, I'm all eyes. Please prove it.
     
  12. "Show me this happening in a high quality image. Prove it!"

    Tim: I said "Rounding/quantization losses are not a problem for most people when working with higher bit depth...", but I can't say for sure that they never will. I do know that gamma 1/2.2 encoding decreases the step size between neighboring brightness levels for the area between 0 and 25% of the full scale input, but it increases it for input values of 25% or more; at 50% it is 1.5 times the linear file step size and at 100% is is 2.2 times. Any image editing introduces more rounding/quantization errors. All this may or may not cause banding in bright gradations like blue sky. Of course I could force this to show up by using extreme image editing of a high-bit-depth file, but that wouldn't prove anything one way or the other.
    Way more important are the issues of image editing program complexity and the necessary larger corrections to force an LCD monitor to a gamma of 2.2.
     
  13. "So much for consistent, calibrated display standards, right? And you want to retool everything to accommodate that techno tower of babel?"

    A truly linear workflow would have a consistent standard of gamma 1: camera sensor, editing software, monitor calibration, printer driver. Wouldn't that be nice? And I already said that it would be darn hard to implement it everywhere.
    On my calibrated monitor the right side of your image shows more definition and clarity in the shadows as well (as it would on a non-calibrated monitor, for that matter). What I still don't understand is why you pull the curves down in the shadow area when you want more definition in the shadows, unless you wanted improvements in that area of the shadows where your tweaked the curves to go back up again, at the expense of the deeper shadows.
    By the way, this issue of how you propose to deal with shadows doesn't have much relevance to the thread's issue of gamma encoding, does it now?
     
  14. I see no reason why you couldn't do this within your own workflow if you thought it would be worth it.
    Spectraview will let me calibrate my monitor to 1.0 gamma, you could create a profile for a linear
    working space, and if you are working with raw data, the input is already linear. You would only need to
    gamma correct images you sent places that were expecting them—like the web.

    Most people don't want to go that far especially since a linear monitor would be pretty bad for other
    tasks that assume gamma correction. Lightroom's workflow is a nice compromise. Everything under the
    hood works with linear data only adding gamma correction for the histogram, RGB readout, and output
    image. This avoids the rounding problems without the need to change the world.

    I dabble in programming and scripting and work with color a lot. I agree that everything would be easier
    and less error prone if we could always count on linear data.
     
  15. "Spectraview will let me calibrate my monitor to 1.0 gamma"
    Mark: I'm not sure if that's a good idea. It could be that the circuitry in the NEC monitors has been optimized so that calibration to 2.2 would cause the least correction and if that's the case you could do more harm than good.
    I definitely need to get myself educated on what's out there like Lightroom.
     
  16. By the way, this issue of how you propose to deal with shadows doesn't have much relevance to the thread's issue of gamma encoding, does it now?​
    Doesn't your quote below relate to steps available for adding definition to shadow detail...
    I do know that gamma 1/2.2 encoding decreases the step size between neighboring brightness levels for the area between 0 and 25% of the full scale input, but it increases it for input values of 25% or more; at 50% it is 1.5 times the linear file step size and at 100% is is 2.2 times.​
    The pull down of the parameter curve points to an issue of where exactly the linear sensor data Black Point maps to the actual preview of absolute black on my calibrated display. For some mysterious reasons using that parametric shadow curve acts like a black point kicker I can't get using the point curve. Linear preview may not match up to linear data is what my point is about going all linear.
     
  17. "Doesn't your quote below relate to steps available for adding definition to shadow detail..."
    Tim: the gamma encoding side-benefit of having smaller steps available in the shadow areas will only be noticeable when you compare a linear 8-bit file to a gamma-encoded 8-bit file; with higher-bit-depth files you won't be able to see the difference. And since you wanted to have a discussion on how all this relates to high-bit-depth files...
    As for your remarks about your sample image and what you did to do what, they raise more questions than they answer. It seems to me that what you do with pulling down the curves for the deep shadows and pull it up again for the slightly lighter shadows is give more contrast to the slightly lighter shadows at the expense of the deep shadows, which would have nothing to do with possible misalignment between the image data, the preview information and your monitor.
    BTW, how exactly does the Block Quote feature work? It's been a long time since I used it and copy and paste + bold doesn't look as nice as the quotes on a blue field.
     
  18. To put text in a gray box as quote you need to select the body of text and click on the double quote symbol in the gray tool box just below the word "Response:".
    00aE5x-455285584.jpg
     
  19. To put text in a gray box as quote you need to...​
    Thanks Bill!
     
  20. My name is Tim.
    My demonstration of linear data to preview misalignment is about how software (ACR) deals with my camera's linear data at the black point region in relation to my preview. Linear data around the area of black point is never consistent image to image depending on exposure and the amount of light in the scene.
    The term linear as it relates between preview and data is never quite precisely defined. The look of actual linear sensor data viewed on a gamma encoded display is quite dark so software like ACR applies a specifically shaped base tone curve under the hood as all Raw converters do that attempts to normalize this dark preview. The black point region of this curve must be very precise because there are fewer bit levels clumped up against absolute black devoted to this region compared to lighter regions.
    If normalization was applied through an 8 bit video system by calibrating the display to 1.0 gamma I believe there is going to be some serious artifacts near this black point region only evident in digital camera images (as opposed to CGI images such as a grayramp made in Photoshop) due to a lack of precision between the display, calibrators and shadow roll off variances from linear sensor data in the black point regions. I want the precision to be applied by my Raw converter (ACR).
    The reason I pushed the black point close to zero while lightening the lighter shadows in my sample image is to provide definition to overcome the reduced dynamic range (flat shadows) of a print, the reason photographers edit digital images.
     
  21. Tim, forgive me for being so blunt, but I have not the foggiest idea what exactly you are talking about. Are you really saying that there is a mismatch between the image data as captured by the camera, the preview information and your monitor? Is this only or more pronounced when viewing linear data? Did you instruct your ACR to not do the gamma encoding? I'm lost and would appreciate any help.
     
  22. Sorry for making this so unclear, Fran.
    Trying to bring out shadow definition near absolute black by placing and adjusting nodes on the point curve (the only tool to indicate what and where this is going on as it relates to the ACR preview on my calibrated monitor) is never consistent image to image. It's like a digital nether world. Sometimes I can get it with just the point curve and sometimes it requires using the parametric "shadow" curve.
    This is why I indicated that there needs to be more precision in manipulating shadow level data (to avoid the cartoonish HDR look from over cranked Fill light to bring out shadow detail) and ACR aids in applying this precision by providing the Fill, Black Point, Point Curve and Parametric curve while at the same time taking into account the user's eyes adapting to viewing dark regions and zooming out to get an overall look from those edits. I'm deducing from these added tools that seem like overkill that Adobe engineers intimately understand this issue AND how it affects editing linear data in a gamma encoded output space.
    If all this was switched to linear encoding at an ICC 8bit color managed display calibration workflow level and retooling the software to map it accurately for that, it still wouldn't solve the off and on nonlinear nature of digital sensor data especially in the shadows I just demonstrated above.
    Now addressing Mark's point about linear encoding for making it easier for developers to create better software, I don't understand what this has to do with digital photography. I'ld think you'ld get more insightful comments posting this topic on a software developer's site. Most of your points mathematically speaking are too complicated to see how it benefits photographers.
    To further put my point across concerning nonlinear nature of digital sensor data in the shadow regions I've posted a pulled back view of the same image crop posted above of the before and after appearance of shadow definition I often struggle with to get it to look natural without the cartoonish HDR look. It's different image to image.
    00aED2-455439584.jpg
     
  23. Now addressing Mark's point about linear encoding for making it easier for developers to create better software, I don't understand what this has to do with digital photography​
    Really? That's a rather myopic view considering how much trouble you are going through to squeeze the final bit of quality out of your software. Conventions and infrastructure that are easier to for people to develop around translate directly to quicker releases, fewer bugs, and cheaper products. Since software is the primary darkroom for just about all photographers these days, things that effect software development effect photographers.
    The situation has improved a lot with the wide adoption of icc profiles, but it wasn't that long ago that questions about gamma encoding made many images mystery meat and was a constant source of frustration. This was especially frustrating when you wanted to drop images into a well-calibrated video system but couldn't be sure what the intended gamma of an image was. It's still a point of frustration on the web. On top of that, it still confuses photographers when trying to understand where exposed values end up on the histogram. Find any web forum topic about exposing to the right or why 18% grey cards don't read 18% in photoshop and you quickly see that this is confusing to almost everyone.
    On a different note, have you tried out Lightroom 4 yet, Tim? Fill light is gone and you now have sliders for blacks, whites, shadows, highlights, and the exposure slider is completely retooled. It's much different and you might like (I stress might) what it does for your shots. The shadows slider works on a much narrower part of the histogram than fill light making the cartoony look a little harder to achieve.
     
  24. Tim: thanks for your clarifications. It seems that you struggle way more with shadow issue than me. My version of ACR doesn't have the parametric curve with its fill and black point adjustments and, judging by what you struggle with, that may be for the better in my case. It remains to be seen if these kinds of issues would be easier or harder to address with linear data, but my guess is that linear data would result in a more straight-forward approach. After all, gamma encoding is an anomaly, a band-aid to correct for the non-linearity of the extinct CRT species.
    Mark: couldn't agree with you more on the issue of gamma encoding causing mayor confusion, the reason why I started this thread in the first place.
     
  25. I've given my 2¢, so I'm done here. Hopefully others more knowledgeable than I will contribute to move this subject along toward more meaningful information with regards to Digital Darkroom issues. Where that is, I have no idea.
    I gave it my best shot. As usual I feel I've waisted my time because I'm no farther ahead than I started with regards to understanding this subject and the benefits it may bring.
     
  26. Tim, I understand and share your frustration. While I've come a long way in understanding the why and how of gamma encoding and how to calculate and graph step sizes and rounding/quantization errors, it isn't clear to me how a purely linear worlflow can be implemented for a reasonable cost, both in terms of image editing software and monitor calibration. I'm not sure if it is a good idea to just take a monitor designed to take encoded files and decode them to a calibrated gamma of 2.2.
    I'm not even sure if companies like Adobe and NEC are seriously looking at easily implementable linear workflows and I don't mean having to buy both Lightroom and Photoshop and a special monitor.
     
  27. There is also a problem from a user-interface point of view. Gamma encoding is everywhere in the
    interface, we're used to it, and it corresponds to the non-linear nature of our perception. A linear histogram
    or curves palette is less intuitive than a gamma-corrected one. The same is true for RGB numbers. We all
    have a pretty good idea where [128, 128, 128] sits visually in a normal workflow and it makes a lot of
    sense to us, but that same tonality ends up around 56 in a linear workflow and is way over on the left of
    the histogram. You can keep the interface gamma corrected even if everything is linear under the hood.
    This is the approach Lightroom seems to take.
     
  28. and it corresponds to the non-linear nature of our perception...​
    I have to strongly disagree: none of the data in the gamma-encoded image file is visible to our eyes until after decoding has restored it to linear.
    A linear histogram or curves palette is less intuitive than a gamma-corrected one. The same is true for RGB numbers. We all have a pretty good idea where [128, 128, 128] sits visually in a normal workflow...​
    I suggest that this is more an issue of having gotten used to distorted data. It makes a lot more sense to me to unlearn the bad habits and use the linear system since that's what the eye will see in the end. The Lightroom approach as you describe it seems to me like a split personality.
     
  29. It makes a lot more sense to me to unlearn the bad habits and use the linear system since that's what the eye will see in the end​
    Yes, but no.
    We, eyes+brain,receive linear data (light photons), bu we "see" not linear.
    We "see" logarithmic (about), or "gamma encoded" (about).
    Our visual system is HDR.
     
  30. Frans, I think you misunderstood me. Data in the gamma-encoded image file IS visible—it's there on the
    info palette, it's on the histogram, it's visible anytime we want to look at the numbers in the file. For
    instance, in the current workflow a grey tone perceptually halfway between white and black is reported
    reasonable close to 50%. That's a useful, intuitive feature that corresponds with how we see the world. In
    a linear workflow 50% is a much brighter tone (about L* 75)—the image may look the same, but the
    reported numbers will all be different. I don't see having an interface that corresponds with our perception
    as a bad habit, but rather good interface design. It's standard practice in many fields to plot linear data
    logarithmically because it makes more sense to us. At some point you simply have to deal with our non-
    linear perception. You can either build an interface to accommodate it or force users to learn numbers that
    don't correspond to their perception, but you can't make it go away.
     
  31. Yes, we have learned to live with gamma encoding and have rationalized it to the point where conventional wisdom says it's the right way, but I'm not so sure. The eye is non-linear, but that doesn't mean it therefor applies to the digital darkroom where we do our editing.
    Let me indulge a little. The eye is claimed to have a gamma anywhere between 1/2 to 1/3, but that's over the full input range of starlight to full sunlight. This enormous range is possible through several adjustment mechanisms if you will: the iris or the eye's aperture, the less sensitive cone receptor in the retina and the more sensitive rod receptors, and then there is the brain. They all work together to span the large input range of light. If the input range is smaller than that, then it follows that a smaller part of the gamma curve is in play which means that the deviations from a straight line are less. I suggest that the input range of what we do in the digital darkroom is way, way smaller than what the eye is capable of: our monitors and prints have a tiny dynamic range compared to what the eye is capable of covering. I suggest that the very limited dynamic range of digital darkroom viewing conditions will operate our eye over a nearly linear range; ergo, a pure linear workflow fits the conditions better.
     
  32. I'm also very interested in this topic, Frans & Mark. One of you guys mentioned that you think the topic of gamma is rather confusing in the literature, with even well respected people/sites perpetuating misleading statements.
    I'd love to see this confusion cleared up. Essentially, I think there's a lot of confusion re: what the actual output of the scene data is on the monitor/output device.
    Let me try to phrase my question thoroughly:
    It seems people always write something like: "because cameras don't see the same way the human eye does (digital sensors record light linearly while the eyes see logarithmically), we apply a gamma curve to the raw sensor data... this has the added benefit of distributing the brightness levels across the available bits better, yada yada."
    My question is: since CRTs/calibrated LCDs essentially apply the opposite gamma curve when outputting images, isn't the overall effect that the real world data -- recorded linearly by the camera, gamma 'encoded', then gamma 'decoded' by your monitor -- is actually represented *linearly* on your monitor (if no significant image editing is done to the RAW file)? If so, isn't it misleading to write that gamma encoding is done to make the camera see more like your eye? Isn't the job of an instrument (camera) to record the signal linearly, then display it linearly, then your eyes do whatever logarithmic transformation it's going to? Why imply that you want to make the camera 'see like your eye' when your eye is already going to 'see like your eye'... if the gamma encoding weren't undone by your monitor, that'd be like applying a double gamma encoding (assuming your eye's response is like a gamma encoding), no?

    The exception would be in the limiting case where an output device has an extremely limited dynamic range (DR)... say a DR over which your eyes essentially see almost linearly. In that case, you may wish to apply some funky curves to the linear data to make it pop more... but given the formidable DR of most modern display devices (9EV for LCDs? 15EV for a JVC projector), seems to me you'd want to mostly just represent the real world data linearly (or with S-curves for contrast/pop/artistic effect). So I just find the common statement of wanting to make a digital sensor 'see like the eye' highly confusing.

    What do you guys think?
     
  33. Unedited linear sensor data is too dark to work with so the Raw file has had an extreme shepherd's hook shaped normalization curve and color description matrix applied in the Raw converter that makes the image viewable on a 2.2 gamma display, a display's native gamma requiring very little curve correction be applied to the video card allowing the majority of an 8 bit/255 RGB tonal distribution in drawing the image on screen with the least amount of banding especially in the shadows.
    There's a bit of designed cheating that has to go on in an 8bit gamma encoded imaging system engineered to devote the majority of drawing 255 tones the eyes can see (low mids to white) compared to what's left for shadows which the eyes don't see as much. At least a gamma encoded working space will allow more refined shadow tweaks using fewer of the 255 levels with software's editing tools written for that gamma encoding. Try editing a linear data file and you'll want to give up because there's no way to tweak shadow detail or bring it out with definition.
    Forcing a 1.0 linear gamma curve correction on an 8bit video system so that dark, non-normalized Raw data looks normal/viewable will cause a lot of banding in the shadows from lower mids into near black because of a doubling of errors caused by not only fewer tonal levels devoted to shadows in the video system but also fewer levels devoted to Raw linear data in the shadows as well as lots of noise that's too much for software to control.
    That's what I think.
     

Share This Page