Content of RAW files?

[Bart_van_der_Wolf]

you then probably not familiar with RPP raw converter ?

Since I'm not on a MAC platform, I'm for one not familiar with the inner workings of RPP (a MAC program that uses floating point math).

The only mention of non-linearity I can see mentioned is in combination with:

Linear and compressed exposure compensations - another very sensitive step, should use high precision math to preserve shadows and highlights and it is almost impossible to make it properly during post-processing in Photoshop. Compressed compensation allows to preserve highlights in more film-like style instead of clipping used in traditional linear exposure compensation.

There is no mention of that being done before demosaicing, and that's probably because it makes little sense to make things more difficult than necessary. It's much easier to do on already demosaiced data.

But maybe you are referring to something else?

Cheers,
Bart

[AlterEgo]

Since I'm not on a MAC platform, I'm for one not familiar with the inner workings of RPP (a MAC program that uses floating point math).

RPP is not a MAC product, it's an OSX product and as such it runs in OSX, that can be run in VmWare (for example) on PC/Win... so does Iridient btw... at least till they start using GPU accelleration.

There is no mention of that being done before demosaicing

that's because you really, really need to read the actual support forum = http://raw-rpp.livejournal.com/6180.html?thread=105252#t105252  ("...В RPP кривые накладываются до демозаики после баланса белого..." = ... -> WB -> curves -> demosaick -> ...)

[Bart_van_der_Wolf]

RPP is not a MAC product, it's an OSX product[...]

I see.

that's because you really, really need to read the actual support forum = http://raw-rpp.livejournal.com/6180.html?thread=105252#t105252  ("...В RPP кривые накладываются до демозаики после баланса белого..." = ... -> WB -> curves -> demosaick -> ...)

I then probably need to dig even deeper in sometimes poorly translated Russian (not my native tongue), than that short fragment has to offer. I see no reason to de-linearize linear exposure data before demosaicing, unless it is to suppress halo artifacts that will be created by overly aggressive (e.g. Lanczos windowed Sinc with a large support) interpolation/demosaicing.

Cheers,
Bart

[AlterEgo]

I see no reason to de-linearize linear exposure data before demosaicing, unless it is to suppress halo artifacts that will be created by overly aggressive (e.g. Lanczos windowed Sinc with a large support) interpolation/demosaicing.

the school of thought was/is that as much as possible has to be done with per-channel raw data before demosaicking... you can ask Iliah Borg about that (I mean the reasoning), but the fact is that at least one implementation exists.

[Dave Ellis]

I am interesting in finding out what makes up a RAW file. Also, I would like some idea about how this information is processed to produce the final result. Bob

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

[Jack Hogan]

sure, as it is a command line tool - that is by defintion... however it can accept arbitrary multipliers for WB

WB can do both - when you aim for a pleasing result and when you aim for precise reproduction... the mere fact that 99.99% of users may allegedly not use WB sliders at all and think that WB is for a pleasing result still does not change the fact... this is not a vote, even 1 example counts to the contrary, so no point to argue

There is no such thing as a precise reproduction when using sliders.  But I agree that now we are discussing semantics and that there is no point in arguing about that.

Jack

[AlterEgo]

There is no such thing as a precise reproduction when using sliders.

as for precise - that depends on what you are reproducing and your tolerances (granted we build profile for a measured illumination and measured subject materials, etc, etc)... when I am using a raw converter to do a raw conversion I still have to use some WB... using "sliders" indirectly through saved values in a drop down list and by calculating the values through WB picker does not change that.

[r010159]

Tony, you have provided a nice summary of demosaicing, but I take exception to your statements regarding gamma. When gamma encoding is accomplished, one applies a 1/2.2 power function to the data. When the image is output to the screen, a 2.2 power function is applied, undoing the 1/2.2 transform and restoring linearity.

This figure from Poynton's gamma FAQ illustrates the process. The contrast for a given input value is the slope of the curve. At low input values, slope is greater than one, indicating greater contrast in the shadows. At higher input values, the slope is less than unity, indicating reduced contrast.

Regards,

Bill

Isn't the use of gamma to enable a person to view the image closer to the way it looked to the observer?

Lets say you have a buffer of luminosity values that relates to some part of the image. Luminocity in this way is represented in a linear fashion. When the luminosity represented by these values double, so does the value itself. But this may not be the way the human eye would perceive it. In order adjust for this, a luminosity curve is applied, where a given value of gamma represents a different curve.

Now, is the above description at all correct? If this is the case, why would the linear scale be reproduced when luminosity is displayed on the monitor? For that matter, isn't the monito calibrated with a gamma value in mind?

By the way, I am right now looking into the references provided so far about gamma.

Bob

[Jack Hogan]

Isn't the use of gamma to enable a person to view the image closer to the way it looked to the observer?

That's a widely shared misunderstanding.  The human visual system responds to linear Luminance that hits the eyes non-linearly, independently of where it comes from.

Picture this: You are sitting in a hotel room in the dolomites looking at the beautiful mountain scenery through a 40", landscape oriented window.  Next to the window there is a 40" state of the art TV showing a picture of the exact same scene captured from your position.  Does gamma need to be applied to light coming through the window in order for you to see it properly, or does luminance hitting your eyes need to be related linearly to that from the scene?

Jack

[hjulenissen]

Isn't the use of gamma to enable a person to view the image closer to the way it looked to the observer?

Gamma used to be about making CRT televisions cheaper by moving circuitry that compensated for the CRT intrinsic behaviour out of 1 million television sets and into 1 tv camera. Great economics.

Gamma currently is about distributing small, approximately additive errors (noise, quantization, lossy coding) in a approximately perceptually uniform way. By inserting gamma/inverse gamma before/after, you can encode video/images at a certain quality using 8 bits. To do the same lineary, you might need, say, 12 bits.

JPEG coding needs gamma in order to reach the compression performance it has today.


Now, there is some talk about modifying end-to-end gamma for certain viewing conditions (e.g. moving a film toned for dark cinemas to a brightly lit electronics store) over at Poynton, but I never really grasped that part.

-h

[Simon Garrett]

Isn't the use of gamma to enable a person to view the image closer to the way it looked to the observer?

Adding to what hjulenissen said, the end-to-end gamma of a system is 1 (i.e. no gamma).  Our eyes have a non-linear response, but the same eyes see the original scene as the reproduced scene.  If the reproduced scene is to look the same as the original scene, then overall there must be no tone curve applied. 

One might apply a tone curve for creative reasons, of course. 

[Peter_DL]

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

there is a nice flow chart here:
http://simon.tindemans.eu/essays/scenereferredworkflow

Peter
--

[Lundberg02]

Demosaicing also makes a statistical guess about the contribution to brightness of the red and blue, and this guess is only about 85% accurate.

[r010159]

Adding to what hjulenissen said, the end-to-end gamma of a system is 1 (i.e. no gamma).  Our eyes have a non-linear response, but the same eyes see the original scene as the reproduced scene.  If the reproduced scene is to look the same as the original scene, then overall there must be no tone curve applied. 

One might apply a tone curve for creative reasons, of course.

Is applying a gamma curve part of the processing of a RAW file? If this is the case, why is it done? Does this permit certain types of calculation of luminosity values to be easier to perform? WRT previous posts, I understand that the luminosity information needs to be relinearized before display on the monitor. For that matter, why is a monitor calibrated to a specific gamma?

Bob




Bob Graham

[Dave Ellis]

Is applying a gamma curve part of the processing of a RAW file? If this is the case, why is it done? Does this permit certain types of calculation of luminosity values to be easier to perform? WRT previous posts, I understand that the luminosity information needs to be relinearized before display on the monitor. For that matter, why is a monitor calibrated to a specific gamma?

Bob

Bob the use of displays with a gamma characteristic is historical and goes back to the use of cathode ray tubes in TV sets as mentioned above in -h's post. When personal computers came along, cathode ray tubes were again used for display purposes. These days with LCD displays, gamma could be dispensed with and displays linearized. The problem is all those millions of jpegs out there that have gamma encoding embedded. There would be huge compatibility issues if we were to suddenly change.

Most raw processors use "linear gamma" when processing images but when these images go into an editor like Photoshop they have a gamma curve applied. There is an advantage with this when you convert from 16 bit to an 8 bit jpeg as you end up with more samples down the bottom end of the tonal range which should help prevent banding. But I'm not sure this is much of an issue really anymore when you are starting from 16 bit.

There is often a tone curve applied in raw processors that resembles a gamma curve but this is mainly to make the image look better. Without this curve, the images tend to look rather flat. But this is quite separate from gamma correction and has nothing to do with correcting for the non-linearity of the eye. The reference in Peter_DL's post above refers to such a curve as part of the creative side of processing.

Dave

[r010159]

I now am understanding what you are saying. There is a historical perspective with respect to the use of gamma with older displays. This part I already understood. I just did not understand why gamma is continued to be used. So there are allot of stored images that were displayed with CRTs. So LCD displays continued to be calibrated with respect to gamma. I imagine once the switch is made to linearize displays, all of those image files will not display properly. So this means the images considered worthwhike by someone will be converted to a linear representation of luminance. This is kind of like the COBOL business application programming language. I think it will be around forever. LOL

I see where gamma can be used in PS to preserve enough information that can be used to prevent banding. But I think since most images used for photographic purposes are 16-bit, then like you said this may have become a much less an issue. So PS converts images using gamma. Interesting!

Based on a couple previous posts, I thought the application of a gamma curve was part of RAW file processing. One mentioned it as a way to create a more pleasing version of the image, what I thought was a type of reconstruction based on the non-linear properties of the eye. Now I understand this part is not valid, and what is actually being referred to is the tonal curve applied to the image, which has nothing to do with gamma. This part is chosen by the specific RAW image processing software.

As an aside, I think some RAW processing software not only applies their own tonal curve, but perform further manipulation to make the resulting image more pleasant to the eye, kind of like what some refer to as making the image "pop".  This can include a subtle color saturation, a bit of sharpening, and other image "enhancement" functions. I guess this is one way a RAW processing software, like Capture One, can differentiate itself from other RAW processors, like LR. It has that "look" that appeals to many. I assume these image "enhancement" "features" can be disabled? Perhaps they cannot be completely disabled?

Bob

[Simon Garrett]

I now am understanding what you are saying. There is a historical perspective with respect to the use of gamma with older displays. This part I already understood. I just did not understand why gamma is continued to be used. So there are allot of stored images that were displayed with CRTs. So LCD displays continued to be calibrated with respect to gamma. I imagine once the switch is made to linearize displays, all of those image files will not display properly. So this means the images considered worthwhike by someone will be converted to a linear representation of luminance. This is kind of like the COBOL business application programming language. I think it will be around forever. LOL

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. 

With colour management, it doesn't matter what tone curve is applied (apart from banding issues with 8-bit data).  Colour management ensures that the data is mapped to the appropriate colour space and tone curve for each stage in the process.  The tone curve in the stored data should be transparent to the user. 

I see where gamma can be used in PS to preserve enough information that can be used to prevent banding. But I think since most images used for photographic purposes are 16-bit, then like you said this may have become a much less an issue. So PS converts images using gamma. Interesting!

Based on a couple previous posts, I thought the application of a gamma curve was part of RAW file processing. One mentioned it as a way to create a more pleasing version of the image, what I thought was a type of reconstruction based on the non-linear properties of the eye. Now I understand this part is not valid, and what is actually being referred to is the tonal curve applied to the image, which has nothing to do with gamma. This part is chosen by the specific RAW image processing software.

Remember that there are (at least) two reasons for applying a tone response curve (TRC).  If the output of the raw processor is being stored in a format that requires a TRC, then the raw processor will apply it.  For exmaple, if the output is to be an sRGB jpeg, then the raw processor has to apply sRGB's TRC.  This is roughly 2.2 gamma, but differs a bit at the black end.  This is just colour management: converting to the colour space and TRC required by the output format. 

A separate issue is applying any TRC required for what one might call creative processes.  For examle, ACR and Lightroom typically have a range of camera profiles such as "Standard", "Neutral", "Landscape" and so on, each of which has a different TRC function. 

As an aside, I think some RAW processing software not only applies their own tonal curve, but perform further manipulation to make the resulting image more pleasant to the eye, kind of like what some refer to as making the image "pop".  This can include a subtle color saturation, a bit of sharpening, and other image "enhancement" functions. I guess this is one way a RAW processing software, like Capture One, can differentiate itself from other RAW processors, like LR. It has that "look" that appeals to many. I assume these image "enhancement" "features" can be disabled? Perhaps they cannot be completely disabled?

Bob

There's much debate (here and elsewhere) about the idea of a completely neutral raw processor.  My own (inexpert) understanding is that a completely flat rendition from a scene-rendered raw image to an output-rendered jpeg or tif will produce an unrealistic and flat image.  To make it look comparable to the original screen, it will generally require some TRC to be applied.  However, the nature of the TRC needed to create a pleasing rendition - one that looks perceptually the same as the original scene - is a matter of judgement.  There is probably no such thing as an objectively accurate rendition of the original scene.  Hence the enormous scope for argument about which raw processor is "better" at accurate rendering of the original scene and colour.

[bjanes]

There's much debate (here and elsewhere) about the idea of a completely neutral raw processor.  My own (inexpert) understanding is that a completely flat rendition from a scene-rendered raw image to an output-rendered jpeg or tif will produce an unrealistic and flat image.  To make it look comparable to the original screen, it will generally require some TRC to be applied.  However, the nature of the TRC needed to create a pleasing rendition - one that looks perceptually the same as the original scene - is a matter of judgement.  There is probably no such thing as an objectively accurate rendition of the original scene.  Hence the enormous scope for argument about which raw processor is "better" at accurate rendering of the original scene and colour.

It is true that if one encodes a high dynamic range scene linearly, tone mapping will be necessary to display the image on a low dynamic range device or on a print. With the low dynamic range output device, merely setting the black and white points will result in a very flat image. However, if the dynamic range of the output device is equal to the DR of the scene referred image, one can output the image directly to the device without any tone mapping. In the case of Jack Hogan's example of viewing a high dynamic range scene from a window and also from an adjacent high dynamic range monitor, there needs to be a 1:1 correspondence of the scene and image luminances if one desires a match.

Regards,

Bill

[Peter_DL]

  I think some RAW processing software not only applies their own tonal curve, but perform further manipulation to make the resulting image more pleasant to the eye, kind of like what some refer to as making the image "pop".  This can include a subtle color saturation, a bit of sharpening, and other image "enhancement" functions. I guess this is one way a RAW processing software, like Capture One, can differentiate itself from other RAW processors, like LR. It has that "look" that appeals to many.

Also camera manufacturers are quite proud of it:
http://www.cyberscholar.com/canon/camera/ctl/mod_index.html?currMod=3&currSec=3&currPage=1

Peter
--

[r010159]

[snip]

Remember that there are (at least) two reasons for applying a tone response curve (TRC).  If the output of the raw processor is being stored in a format that requires a TRC, then the raw processor will apply it.  For exmaple, if the output is to be an sRGB jpeg, then the raw processor has to apply sRGB's TRC.  This is roughly 2.2 gamma, but differs a bit at the black end.  This is just colour management: converting to the colour space and TRC required by the output format. 

A separate issue is applying any TRC required for what one might call creative processes.  For examle, ACR and Lightroom typically have a range of camera profiles such as "Standard", "Neutral", "Landscape" and so on, each of which has a different TRC function. 

[snip]

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