2

I have several DNG image files, recorded with an LGE Nexus 5X using Open Camera for Android as camera app. For further image processing i converted the DNG files to TIF files using Camera Raw 8 and Photoshop CC 2015. I converted the images without changing any color or exposure settings.

As far as I know the DNG files should be linear, (without gamma correction). My question is whether the converted TIF file is still linear or not. Does Photoshop / Camera Raw make gamma correction for TIF files?

mattdm
  • 143,140
  • 52
  • 417
  • 741
Hans Müller
  • 25
  • 1
  • 4

4 Answers4

3

When you view the image with a normal image viewer, is it mostly dark? If not, a gamma curve has been applied. That is, does it look like this?

tif no gamma

That's what you'll get with a pure dump of linear values into a 16-bit tiff file. Or, encoded across 8 bits, and demosaiced, and with white-balance adjusted, something like this:

8 bit color

If it looks like that or similar, you are likely seeing a linear image. This is not normally considered very useful, so when RAW files are converted to image formats used for viewing and distribution, they're almost always processed into something with a gamma curve applied for that purpose.

I converted the images without changing any color or exposure settings.

You may not have changed settings from the default, but your RAW conversation software does have defaults which are not "leave input values unchanged".

See What does an unprocessed RAW file look like? for more. If you really want to extract unprocessed data for doing your own processing, look at using dcraw as referenced there.

mattdm
  • 143,140
  • 52
  • 417
  • 741
  • Thank's! To linearize the images i would need to know the gamma value used for the gamma correction. Is there any way to find it out? – Hans Müller Mar 05 '19 at 08:17
  • Why not just use dcraw? Why do you want linear images anyway? – mattdm Mar 05 '19 at 14:03
  • The problem is beyond gamma which is just an encoding/decoding method specified by tags written into the tiff file. The actual problem is the tone curve used converting from RAW to tiff and that's unrelated to gamma correction. Worse, it isn't defined, it also affects color chromaticity, and isn't reversible. It appears you want to get what's called a "Scene Referred" image. This is a somewhat specialized area for those that do high end reproduction prints. – doug Mar 05 '19 at 18:50
  • @doug Yeah, I kind of glossed over that but it's absolutely the case. In the second image above, dcraw has applied a white balance adjustment as read from the metadata produced by the camera, along with a camera-model-specific color matrix. – mattdm Mar 05 '19 at 18:54
  • @mattdm I want to convert the images into CIELab* color space. As far as I know therefore the images must be linear. Maybe there is a way to directly calculate the Lab* images from the RAW data.. – Hans Müller Mar 06 '19 at 10:21
  • @HansMüller But why do you want to do that? That seems like an intermediate goal, not an end state. – mattdm Mar 06 '19 at 11:34
  • I am looking for indices that correlate with the "greenness" of plants. The b* paramter of the CIEL*a*b* color space might be such an index. – Hans Müller Mar 06 '19 at 12:05
  • 1
    @HansMüller It might be. The CIELAB color space is meant to correspond to human perception; if that's what you mean by "greenness" that might be an appropriate choice. However a) using Photoshop and photographic tools to do this isn't the right choice — you should instead look at dcraw or possibly Matlab, Octave or the like, and you need to really understand the RAW file format and the normal conversion process in order to do something different; b) a consumer camera may not be a good choice for this requirement; and c) this isn't really a photography problem. – mattdm Mar 06 '19 at 15:51
  • 1
    I say "not really a photography problem" because the goal is a measurement, not a photograph, and actually the tools and processes used to produce photographs are getting in your way and you want to do something different. – mattdm Mar 06 '19 at 16:24
1

Gamma is not something that has to be "corrected" It's a scaling to accommodate 8 bit images to adjust the values represented by those 8 bits over a larger dynamic range. A RAW file contains the sensor data which is purely linear (or gamma=1). If you convert a raw file to a 16x3 bit image with gamma set to 1.0 it will look the same in a color managed app like Photoshop as converting it to the same colorspace with a gamma=2.2*. But if you convert it to an 8 bit image file it will look the same overall but the darker parts will have significant banding because human vision is much more sensitive to small changes at low light levels than high light levels.

If you use 16 bit images, gamma will make no difference in how they look or print but, by convention, normal colorspaces have gammas varying from 1.8 (ProPhoto) to 3.0 (RGB scaled based on L*). An 8 bit image will look the same no matter what gamma the colorspace has that it's converted into since the gamma will be reversed when the image is displayed or printed.

*As an aside, you can turn a standard RGB profile like ProPhoto RGB into a gamma=1 version using Photoshop by creating a custom profile and setting the gamma=1. I find it useful to do things like resizing images in gamma=1 to reduce aliasing artifacts and moire that can occur with standard gammas.

doug
  • 1,207
  • 8
  • 13
  • 2
    Gamma absolutely is something to be corrected, and the correct name of the term is "Gamma Correction". See https://www.google.com/search?&q=gamma+correction . "Gamma" is the name of the problem to be corrected. We tend to forget about CRT monitors today, but correcting CRT monitors is the purpose of adding gamma correction. Our standards still do it to prevent obsoleting all the worlds old images. – WayneF Mar 05 '19 at 16:31
  • @WayneF Using "Correction" implies something that is wrong needs to be made right. This certainly applied back in the day of analog CRTs since, as you point out, cathode ray tubes were intrinsically non linear. Gamma is simply an encoding/decoding technique that specifies how the relative luminance is encoded/decoded but not the luminance. It changes nothing visually. Take an 8 bit sRGB image. It's encoded as a modified, 2.4 gamma. If you change the mode in Photoshop from 8 bits to 32 bits, nothing at all changes visually. But what's the new image's gamma? It's 1.0. – doug Mar 05 '19 at 18:19
  • Not correct. Gamma correction obviously and drastically changes the image tones, which is the entire point (to correct for the incorrect non-linear CRT response which is called gamma). There is no clipping due to gamma correction, but brightness DRASTICALLY changes (to correct the CRT response). The 8-16-32 bits is an entirely different concept, not related in any way to gamma correction. Printers also need a big measure of the boosted data, and they know how to deal with it. We should realize that our histograms show gamma data, NOT linear data. (continued next due to length) – WayneF Mar 05 '19 at 19:02
  • Photoshop shows gamma 1.0 as meaning still UNCHANGED, RELATIVE to whatever the original gamma was. If the original gamma was 2.2, and you tweak it to 1.2 in Photoshop, then that means 2.2 x 1.2 = gamma 2.64 is the data that the CRT would see. However, LED monitors are linear, and simply know to first decode gamma correction (discarding it so to speak), but the LEDs do a 2.2 decode, the expectation from the sRGB standard. Our eyes only see the linear decode, we never ever see any gamma data. It has been reverse decoded first, either by the CRT response, or by the LED lookup tables. – WayneF Mar 05 '19 at 19:02
  • @WayneF "Gamma correction obviously and drastically changes the image tones" It changes the image values, not the colors/luminance the values represent. Just like changing 2.3 from single precision to double precision changes the encoded bits but they both represent the same value of very close, but not exactly, 2.3. BTW, floating point has the feature, like gamma encoding, of encoding large values further apart than small values. Since that's intrinsic to floating point, applying an additional gamma is not needed. – doug Mar 05 '19 at 20:08
  • @WayneF "We should realize that our histograms show gamma data, NOT linear data" Histograms vary. In Photoshop, histograms show the RGB values "linearly". That is 127 is in the middle. This is true no matter the gamma of the working space. So, if you convert an image from gamma=2.2 to gamma=1, the image won't change visually but the histogram will shift strongly to the left. – doug Mar 05 '19 at 20:46
  • In PS Levels, if changing gamma, the current visual image certainly does change if you have Preview on, or if you hit OK. It also changes in the histogram, which shows the only data we have. Beginners material only shows linear histograms (gamma would confuse them), but linear 127 is absolutely NOT in the middle of any histogram we see. I will add one more obvious refutal (as a way you can see this) about the histogram data absolutely and obviously being gamma encoded. Gamma encoded data is the only data we have. And then I'm hoping to be gone. – WayneF Mar 05 '19 at 23:09
  • 1
    Take picture of something bright, adjust to reach near histogram 255 (very close, but NOT quite clipped). Then also stop down 1.0 stop for another picture. One stop is 50% of light. Your wrong linear notion would expect to see that peak now at 127 (50% of the 255 previous). BUT IT DOES NOT. It will be near 3/4 full scale. Gamma 2.2 encoding of 50% linear computes 187 or 73%, but camera is also shifting white balance and contrast, etc, so it can't be exactly predicted. BUT SURE AIN'T NEAR 50% LINEAR AS YOU IMAGINE. Histogram data is absolutely encoded with gamma correction. It's all there is. – WayneF Mar 05 '19 at 23:10
  • @WayneF Perhaps we are talking about different things. The gamma of a colorspace is a non-linear, exponential, encoding. When one converts from colorspaces with different gammas no change occurs to the image appearance if the colors are within gamut of the new colorspace. A one stop reduction image will shift peaks at the right hand side of a histogram to the middle when the colorspace is gamma=1. If you convert to colorspaces of differing gammas, the location of peaks will shift but the luminance of the image will not. But a more typical, gamma=2.2 image will shift about 30% from the left. – doug Jun 01 '19 at 02:15
  • Gamma is still exactly the same as done for CRT. It is Not gamma 1, which in editors simply means relative to the original unmodified value, whatever it was (is 2.2 in sRGB). Then changing to 1.2 means 1.2 x 2.2. A one stop reduction does NOT go to middle, in 2.2 data, 255 falls to about 3/4 scale. It is nonlinear, but 3/4 is not an absolute number because cameras are busy doing other shifts too, like white balance and contrast and color profile. Converting color spaces may try to preserve the image colors, but just changing gamma absolutely changes tones, color shifts called brightness. – WayneF Jun 01 '19 at 04:46
  • @Wayne, do you have or know how to get an RGB ICC colorspace in gamma=1? They are quite useful for resizing without introducing blend artifacts. If you look at an image in a gamma=1 colorspace if will shift from the right edge to the middle with a one stop decrease in exposure. One way to test it is with dcraw.c which can output images with an ICC tagged, gamma=1 colorspace. You can see this for yourself in Photoshop. Also, dcraw.c has options to create scene referred images which are colorimetrically accurate and don't have the misc. tone curve additions cameras add. – doug Jun 01 '19 at 05:54
  • doug is correct, @WayneF is not on a few points. First of all, all vacuum tubes follow Langmuir-Child law, but means to linearize were certainly well known - it was a design choice by early television engineers to accommodate CRT non-linearity at the start of the broadcast chain, as system gamma took advantage of human non-linear visual perception which allowed a 30dB reduction in apparent noise in the image. CRT design HAS a great deal to do with the effective CRT gamma, which can vary from 1.5 to over 3.5. Designing CRTs for a target gamma of 2.2 has many advantages. (continued)... – Myndex Jun 01 '19 at 06:51
  • Even back then it was entirely possible to design a TV/CRT driver circuit for LINEAR response, but the non-linearity of CRT display was a desired characteristic for noise reduction and other reasons, just as it is today for bit-depth reduction. Even if CRTs did not have a non-linear response, some form of similar pre-emphasis would have been used for noise reduction, as it is in many other areas of signal processing for broadcast/transmission. 2.2 gamma was specified as part of NTSC color as it was necessary to define gamma for consistent color reproduction. – Myndex Jun 01 '19 at 07:33
  • The salient point: Gamma is still required today, even if we had displays that were linear. Gamma is required to make the best use of available code space. If images were encoded with no gamma, they would need at least 12 bits per color per pixel (36 bits per pixel), but using a transfer curve that is close to the inverse of human perception, such as something between 1/2 and 1/2.5, we can get away with using just 8 bits per color channel (24 bits per pixel). Some image editors like Photoslop may do a lot of things in a gamma encoded workspace, but you can certainly use PS in linear. – Myndex Jun 01 '19 at 07:52
  • And AfterEffects makes it trivial to work in a linear space. A great many operations are better performed in a linearized workspace and not a gamma workspace. Nevertheless, DOUG is correct, the data displayed in Adobe histograms is a linear spread of rgb values, regardless of the image encoding used. The middle of the histogram is 127/128. This is academic, and as someone who works in linear space all the time I can tell you that Adobe's histograms are quite deficient for linear work partly for this reason (another being the controls while linear are not even close to perceptual uniformity). – Myndex Jun 01 '19 at 07:58
  • Gamma is NOT done to fit into 8 bits. Gamma is done to CORRECT the nonlinear CRT response. Without CRT now, it is still necessarily continued for compatibility with the worlds image data. The eye NEVER EVER sees any gamma data, it is always NECESSARILY decoded back to linear for presentation to the eye. Decoding is properly an EXACT REVERSAL of encoding, which must match the CRT, but it could not matter less TO THE EYE what path gamma had taken, because the idea is that data is necessarily exactly reversed back to linear for the eye. Anything else would be distortion, or at least modification. – WayneF Jun 01 '19 at 14:40
  • "Gamma is NOT done to fit into 8 bits" For quite some time now that is the main reason for >1 gamma after monitors migrated from analog interfaces to digital ones. Most monitors allow programming their gamma. Since the large majority are 8 bits, with a smaller number supporting 10 bits, a gamma of 1.5 to 3 is essential to avoid banding in low luminance images. I sometimes set my monitor's gamma at 1.0 to verify the 10 bits/ch path is working as there are multiple things that can cause my setup to revert to 8 bits. Driver, App, and monitor all have to be set up correctly. – doug Jun 01 '19 at 15:08
  • @WayneF While you err on the 8 bit discussion, as Myndex discussed in some depth, you are quite correct that the vast majority of images displayed to people would look pretty awful if monitors didn't have a high gamma. Originally, this was to approximate CRT response. Nowdays it's compatibility when people aren't using color management. But it's also to prevent banding at low luminance which is a problem even with high end 10 bit displays though they work pretty well with 10 bit paths and gamma=1 for most images because the image noise dithers the image. – doug Jun 01 '19 at 15:31
0

TIF should have gamma. Any normal and viewable (usable) tonal image includes gamma correction. Tonal includes color (RGB or indexed) and Grayscale, but does not include Line art (bilevel, data is only 1 or 0).

Raw images do not (yet), gamma and white balance is postponed for later processing into RGB. Your TIF file was that later processing.

WayneF
  • 12,879
  • 1
  • 16
  • 30
0

Short answer: If you're looking at anything more than an almost black blob of nothingness, it's had gamma correction applied.

Michael C
  • 175,039
  • 10
  • 209
  • 561
  • Too dark, but shouldn't be all black. 255 linear encodes to 255 gamma (in this 0..1 scale, 1 to any exponent is still 1. Kinda clever, no clipping due to gamma). That unencoded 255 linear will decode back to 255 when viewed (not dark). 70% linear would be decoded to 135 instead of 179, but still above midpoint. 50% linear encodes to 187 gamma 2.2, but the unencoded 50% decodes to 22% when viewed, or to 55 in histogram. Dark, but not all black, except for the dark tones which really suffer. But there should also be brighter tones, just not fully bright. – WayneF Mar 06 '19 at 19:07
  • @WayneF "almost" does not equal "all." – Michael C Mar 06 '19 at 21:06
  • Doesn't equal black blob either. :) Using Photoshop Levels to multiply gamma by 0.45 (reciprocal of 2.2) to get 1.0, which is linear, it looks about like any average or typical underexposed photo. More than slight, it is dark, but still looks very correctable, very far from black. Looking at Windows background wallpaper images done that way, some images might not have any black in it. Moot point though, it is unpleasantly darker, and our images are expected to have gamma correction encoded into them. – WayneF Mar 07 '19 at 00:05