Content of RAW files?

[bjanes]

Interesting. So there are output formats that specify what gamma is used to encode the luminance information. Why is this the case? Since you mention JPEGs, perhaps this is due to its 8-bit format? Since JPEGs have been around for quite awhile, I imagine there is a historic CRT related angle to this?

However, I think you have specifically stated the sRGB color space requires information to be encoded using a gamma curve. Why is this the case? Does AdobeRGB have this same requirement? I am trying to separate the requirements of the output format from that of a the color space.

Bob

Bob,

Do your homework. Google is your friend.

www.color.org/srgb.pdf

Bill

[r010159]

Bob,

Do your homework. Google is your friend.

www.color.org/srgb.pdf

Bill

Thanks for the link Bill. After reading through such technical information like the chromaticity values for specific "anchor" color values, the temperature of the white point, color transfer functions, and the like, I have come up with a gamma of "2.2". I see this is also the value for AdobeRGB. Interesting.

At this point, I can only guess why this is the case. Both color spaces, ICC profiles, calibrated displays, and image formats like both TIFF and JPEG, work with the encoding of information using a specific gamma curve. I am beginning to suspect one reason this is done is to make for more efficient computations concerning luminance values. In such a treatment of luminance values, the response curve of the human eye can be numerically described in a linear fashion. This definitely can simplify computations.

So CRTs used gamma encoded information for a specific reason. Image file formats, in particular those using 8-bit values, used gamma for a different reason. Upon a read of an article on gamma correction,  I beginning to suspect another reason, which is for more efficient computation of luminance values in the context of human perception. But then, I will need to find how a gamma based calibrated display fits into this picture, since there is no CRT like response function involved. And, as one mentioned earlier, the luminance values are relinearized before display on a monitor.

I guess one step at a time. Boy, Knowing something about math helps!

Bob

PS. It appears that the connection color spaces like Lab uses unencoded luminance values. This makes sense.

[Peter_DL]

It is true that CRT displays had roughly an inverse 2.2 gamma tone response, but that's not why images are stored now with a non-linear gamma.  The main reason is for coding efficiency with 8-bit data.

Just to add this chart here, which shows that gamma-2.2-encoded data are roughly linear along a perceptual scale.
thus ensuring that ca. 50% of the 0-255 bandwidth are allocated to darker tones (darker than a perceived mid gray).
The gap here in the deep shadows is partly closed with the specific sRGB TRC, due to its reduced slope at the start.

Peter
--

[Simon Garrett]

So CRTs used gamma encoded information for a specific reason. Image file formats, in particular those using 8-bit values, used gamma for a different reason. Upon a read of an article on gamma correction,  I beginning to suspect another reason, which is for more efficient computation of luminance values in the context of human perception. But then, I will need to find how a gamma based calibrated display fits into this picture, since there is no CRT like response function involved. And, as one mentioned earlier, the luminance values are relinearized before display on a monitor.

I wouldn't say CRT's "used" gamma; that implies some conscious intention.  CRTs were fat, dumb and happy, and it just happened that they had a response roughly equivalent to an inverse gamma of 2.2.  It also just happens - entirely coincidentally - that our eyes have a perceptual response roughly equivalent to an inverse gamma of 2.2.  That is, our eyes are more sensitive to absolute changes in light at low light levels compared to the same absolute changes at high levels.  As a result, what appears to us as a mid-grey is actually not 50% of peak white, but somewhere around 12-15%. 

These days with colour management, gamma curves are largely irrelevant to the user.  Things happen under the hood that we don't need to bother about - provided colour management is working.  Most data encoded at 8-bits uses a 2.2 gamma TRC or similar, but that's for engineering purposes.  It enables data to be encoded in 8-bits rather than 10 or 11 bits that would be necessary with linear encoding.  Most processing programs (Lightroom, Photoshop etc) process image data in linear form (removing any non-linear TRC as part of the processing, then reapplying it afterwards).  That all happens behind the scenes, because it's usually easier to compute things with linear data.  Most programs display histograms with a 2.2 gamma applied (so the perceptual mid-grey appears at 50% rather than around 15%). 

IMHO much of the fretting about gamma curves relates to time gone by when we didn't have colour management, and we had to make sure that the end-to-end TRC was linear (even if we didn't know that was what we were doing!).  These days we use colour management - calibrated/profiled displays and printers, colour-managed software (which nearly all photo software is) - and it just works. 

As we're all saying, an entirely separate issue is applying tone curves for creative reasons, or (as part of raw conversion) to make the output-rendered image look perceptually more like the original scene. 

PS - edited to add: to my understanding, gamma based display calibration doesn't fit into this picture.  A display can be calibrated to any gamma provided you are using colour management.  Colour management applies the appropriate (opposite) curve to cancel out whatever the TRC of the display.  However, many displays have a native gamma of round about 1.5 to 2.5, so if you calibrate somewhere in this range it reduces the correction that has to be applied in LUTs (Look Up Tables) and it minimises the chances of visible banding. 

[D Fosse]

<no need to repeat everything>

That sums it all up very nicely.

The coincidence of CRT native response and the need for gamma encoding to maximize bit information content, has been described as "an incredible piece of engineering luck". It was handed to the early TV engineers on a silver platter.

And yes, between modern color management and high-bit processing, one could do away with gamma encoding altogether. But there are still all these 8-bit jpegs floating around, and plenty software without color management.

[Fine_Art]

Hi Bob

The main content of the raw file is of course the raw data which is a set of digital values (one value for each sensel) read from the A/D converter(s). This is typically 12 or 14 bit data. It is sometimes compressed.

Other raw file content includes metadata which has information on the camera and also on settings used by the camera for in-camera jpeg production. The raw file also contains one or more jpeg's which have somewhat smaller resolution than the sensor. This jpeg is often used for preview purposes (thumbnail display for example).

Raw processing involves the following steps

Decompression of data if necessary
Normalising (setting white and black points) and scaling the data to 16 bit
De-mosaicing
Setting White Balance
Adjusting colour to a standard colour space

The last step is done at least in some software such as ACR and Lightroom using camera profiles. These profiles also include a tone curve which is used to give the image more "pop". It is important I think to make the distinction between this tone curve and the standard gamma correction curve which is used for compensating for the non-linear characteristic of a display monitor. In most raw processors, this gamma correction curve is not applied to the image during processing, only for display purposes.

Dave

I interpret the question the same way as Dave. His is the first response that talks about the literal file contents.

I will add that most raw files are a compressed tiff type data list, with a wrapper (header) that has instructions for the particular camera values.

[r010159]

Thank you all very very much! All of you have been generous with your time and efforts to help me understand the make up and processing of RAW files.

Bob

PS: Sorry for all of the questions. There is so much for me to understand. I will do some additional googling on this topic to fill in sone of the remaining details.

[Guillermo Luijk]

I see too much focus on discussing the gamma issue when it's something quite irrelevant that needs no decisions made from the photographer.
Very quickly the RAW development process involves:


PURE RAW DEVELOPMENT

1. Decoding the RAW data (RGB values contained in the RAW file according to a propietary format), usually from a RGGB Bayer matrix.
2. Applying some linear corrections to the RAW data to prepare them for demosaicing (substracting the black point, adjusting the sat point to the max of the output scale)
3. White balance: in a more or less sophisticated way, WB is equivalent to an exposure adjustment (linear scaling) for each individual channel: R, G and B
4. Demosaicing: the missing RGB values are interpolated following a more or less sophisticated algorithm (AHD, Amaze,...). This part can be done before the White balance in some RAW developers.
5. Apply some shadow/highlight recovery, or inpaint strategies in RAW data clipped areas: these could be considered pp but since it is so mandatory to make critical decisions (specially about making the highlights compatible with the non-uniform RGB scaling WB means), any RAW developer, no matter how basic it is, has some abilities in this regard.
6. Depending on up to which degree the RAW developer listens to RAW metadata, other adjustments can be made to the image: clandestine exposure correction (baseline exposure), lens-dependant corrections (distortion, chromatic aberrations,...),...
7. Numerical conversion to a recognised/standard output colour profile (sRGB, Adobe RGB,...): means a more or less sophisticted matrix or LUT scaling adapted to every camera sensor. Calibrated camera profiling would mean taking the standard procedure one step further. This stage usually means applying the non-linear gamma scaling intrinsic to any chosen output profile (2,2 gamma for Adobe RGB, 1,8 gamma for ProPhoto RGB,...), which is quite irrelevant to the photographer.


IMAGE POST-PROCESSING

From the steps above, we would have a nearly standad neutral RAW development that should not differ too much in rendering whatever the software used (leaving aside metadata dependent corrections). But the resulting image would look flat, dull and lacking saturation and sharpness. Now is when the non-standard procedures take place that differ a lot from one software to another (this includes camera engines to build the output camera JPEG):

- Tone/contrast curve
- Satuation adjustments
- Noise reduction (probably ISO dependent)
- Sharpening (even if the user value is set to 0)


DCRAW is a very good learning tool to understand how the RAW development takes place. If you have some programming skills, looking at the source code is also a very good way to understand how it works (the very simple scale_colors() function performs steps 2 and 3 in a bunch of lines). This is how DCRAW responds to a custom RAW development request:

c:\dcraw>dcraw -v -w -o 2 -g 2.2 0 -H 2 -4 -T 1.ORF
[-w: camera WB, -o 2: Adobe RGB output, -g 2.2 0: standard 2.2 gamma curve, -H 2: neutral and preserving highlight strategy]
Loading Olympus E-P5 image from 1.ORF ... [loading and decoding RAW data]
Scaling with darkness 255, saturation 4095, and [linear scaling to output range]
multipliers 1.000000 0.444444 0.649306 0.444444 [linear scaling white balance]
AHD interpolation... [AHD demosaicing]
Blending highlights... [highlight strategy]
Converting to Adobe RGB (1998) colorspace... [standard colour profile conversion]
Writing data to 1.tiff ...


This is a simplified view of the process:

1. Pure RAW data
2. Linear neutral RAW development (camera WB, sRGB)
3. Same as 2 plus sRGB specific gamma curve
4. Camera JPEG obtained using tone curve and other adjustments



The translation from 3 to 4 corresponds to the following tone curve:



Regards

[ErikKaffehr]

Hi Jack,

I agree mostly but not fully.

Regarding 1) it is quite trough that it is an "objective"  rendering, but the mapping of colours and rendition of detail can differ between converters.

Regarding 2) there are differences between raw converters, too. My favourite one does some kind of locally adaptive tone mapping that I don't think can be reproduced at ease with a pixel editor like Photoshop.

Best regards
Erik

Hi Bob,

What most people consider 'raw converters' do can actually be divided into two macro functions for simplicity:

1) objective rendering of the raw file to the chosen standard color space (this is the raw 'conversion' part, it requires virtually no human input); and
2) arbitrary PP to make the image more pleasing to the eye of the artist (can be done in any editor, like Photoshop - choose the one with the tools and the workflow you like).

The first is quantitative and objective, the second qualitative and subjective.  99% of the adjustments the average photographer performs daily on their images during what they consider to be 'raw conversion' fall squarely into category 2) and can be performed just as effectively in one or more editors/plug-ins with no loss in IQ: just pass the image from one to the other as a 16-bit or floating point TIFF.  For instance: black/white levels, curves, highlight/shadow recovery, vibrance, clarity, sharpening etc.etc.etc are all basic editing functions.  'Raw converters' simply try to bring all typical adjustments in one place and make them faster/easier to use.

Jack