Luminous Landscape Forum
Raw & Post Processing, Printing => Digital Image Processing => Topic started by: r010159 on September 30, 2015, 10:45:32 pm
-
I apologize if this topic is in the wrong forum. I cannot find one strictly on technology. 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. I have heard of some terms like demosaicing. I understand this involves approximations. Then there is the application of a tonal curve that the application chooses to apply. There may be some noise reduction process considering that there are approximations being made.
My objective is to know the factors that result in one image from a RAW processor to be handled differently from that produced by another RAW processing program other than saturation, sharpening, and other functionality normally considered as a part of a photo editing program.
Bob
-
Its nonetheless a fair question.
Basically your question revolves mostly around the process of demosaicing.
This is part of the process of raw file conversion done in a raw converter.
In order to explain how demosaicing works a very quick and basic explanation of a digital camera sensor and how it works is needed:
Think of the light-gathering part of the sensor as a grid with a well that collects light in each grid component. Depending on how much light hits the well each sensel (sensor element) converts that physical light hitting the sensel into a charge which is ultimately recorded as a number. This is referred to as analog-to-digital conversion. (accept for now that this is not a detailed technical expose.)
Furthermore above the sensor is a colour filter that is a repeating structure of four filters each containing two green components and a red and blue element each. Each element of the filter overlies a single sensel. That means that light passing through the filter on the way to a particular sensel is flltered by colour - either green, red, or blue.
The sensels themselves have no idea what colour light is hitting them - they just record light in shades of gray - this is important.
The demosaicing process not only decodes the gray tones from each sensel but also interpolates the overall colour of the light to assign to that sensel by looking at light striking the sensels around them. Since the sensels around are filtered for different colour ultimately colour is assigned to each sensel by assigning values to each of the three primary colours e.g. R65 G55 B78.
Another part of raw conversion involves changing the contrast. Suffice to say for now that the original image is very flat with a gamma curve of 1.0. Generally the gamma curve applied is 2.2 which increases the contrast considerably to something a little more akin to how we see.
Each raw converter uses a different algorithm to achieve this entire process accounting for some of the subtle, and not so subtle differences, between raw converters.
My suggestion is to go and read a formal expose of raw conversion and demosaicing. I would find a link myself but I am bit pressed for time right now!
Go well!
Tony Jay
-
My objective is to know the factors that result in one image from a RAW processor to be handled differently from that produced by another RAW processing program other than saturation, sharpening, and other functionality normally considered as a part of a photo editing program.
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
-
Its nonetheless a fair question.
Basically your question revolves mostly around the process of demosaicing.
This is part of the process of raw file conversion done in a raw converter.
In order to explain how demosaicing works a very quick and basic explanation of a digital camera sensor and how it works is needed:
Think of the light-gathering part of the sensor as a grid with a well that collects light in each grid component. Depending on how much light hits the well each sensel (sensor element) converts that physical light hitting the sensel into a charge which is ultimately recorded as a number. This is referred to as analog-to-digital conversion. (accept for now that this is not a detailed technical expose.)
Furthermore above the sensor is a colour filter that is a repeating structure of four filters each containing two green components and a red and blue element each. Each element of the filter overlies a single sensel. That means that light passing through the filter on the way to a particular sensel is flltered by colour - either green, red, or blue.
The sensels themselves have no idea what colour light is hitting them - they just record light in shades of gray - this is important.
The demosaicing process not only decodes the gray tones from each sensel but also interpolates the overall colour of the light to assign to that sensel by looking at light striking the sensels around them. Since the sensels around are filtered for different colour ultimately colour is assigned to each sensel by assigning values to each of the three primary colours e.g. R65 G55 B78.
Another part of raw conversion involves changing the contrast. Suffice to say for now that the original image is very flat with a gamma curve of 1.0. Generally the gamma curve applied is 2.2 which increases the contrast considerably to something a little more akin to how we see.
Each raw converter uses a different algorithm to achieve this entire process accounting for some of the subtle, and not so subtle differences, between raw converters.
My suggestion is to go and read a formal expose of raw conversion and demosaicing. I would find a link myself but I am bit pressed for time right now!
Go well!
Tony Jay
Small addition: RGB values in a given colorspace!
-
https://en.wikipedia.org/wiki/Demosaicing
-
Small addition: RGB values in a given colorspace!
Correct!
Tony Jay
-
While there are differences in demosaicing, noise reduction and other signal processing aspects, the major part that causes differences in look between raw converters is the color profile and tone curve application, that is what takes place after the basic raw conversion has been made.
Even with the same linear color in the bottom, the type of tone curve makes a large difference. With RawTherapee you can experiment with several different types of tone curves and see how big difference in look that can make. With low saturation colors the differences are typically small, but with higher saturation colors you can get very big differences.
Then we have the tradition from the film days, that color should not be neutral and realistic but rather have some sort of "look", and this is interpreted way differently between manufacturers.
-
Another part of raw conversion involves changing the contrast. Suffice to say for now that the original image is very flat with a gamma curve of 1.0. Generally the gamma curve applied is 2.2 which increases the contrast considerably to something a little more akin to how we see.
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
-
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
Thanks for the input Bill.
I will look into this.
Tony Jay
-
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.
Good point, Bill. Luminance from the scene (either directly, through a window, or through capture+monitor) ideally behaves linearly: twice the 'light', twice the photons hitting our eyes. The human visual system will then perceive the arriving photons as it always does (non-linearly).
Jack
-
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.
Hi Bill,
While correct, it's important to also point out that many image manipulations, e.g. in Photoshop, are performed on gamma pre-compensated TIFF/JPEG input. That can result in color shifts when brightness and/or contrast are changed, because the linear relationship between R, G and B is 'broken' if the workingspace gamma is not linear.
But, for the OP, that's all after Raw conversion, which is a process based on linear (or linearized) gamma Raw data (usually in Bayer CFA format before it's demosaiced). After blackpoint subtraction, white balancing, and demosaicing, the postprocessing can begin (including the application of gamma pre-compensation).
Some Raw converters can also compensate for e.g. Chromatic Aberrations, before demosaicing, which will improve resolution because the RGB channels will be demosaiced while in registration/aligned.
Cheers,
Bart
-
as all (?) raw converters combine (as noted) "raw conversion" and "postprocessing" the question is where the "raw conversion" ends and "postprocessing" begins... two school of thoughts : (A) demosaicking is the end of the "raw conversion" and (B) any color transform to any formal color space is the end of the "raw conversion"
-
the question is where the "raw conversion" ends and "postprocessing" begins... two school of thoughts : (A) demosaicking is the end of the "raw conversion" and (B) any color transform to any formal color space is the end of the "raw conversion"
A good question with many answers. In my mind the raw 'conversion' part converts raw data to a standard format (e.g. a colorimetric RGB color space like sRGB) that can be understood and made more pleasing through subsequent use of any available PP tool. So I would suggest that raw conversion includes all steps that need direct access to the raw data but stops as soon as the image is demosaiced and rendered into the working color space. There are no sliders necessary in raw conversion, just inputs needed to describe the scene, the hardware and the output color space: white balance, color profile (or matrix, absent one of torger's) and desired color space. Additionally some lens/camera setup information could be useful for CA correction and low-level noise reduction.
dcraw for instance is in my opinion such a 'just' raw converter.
Jack
-
There are no sliders necessary in raw conversion, just inputs needed to describe the scene, the hardware and the output color space: white balance, color profile (or matrix, absent one of torger's) and desired color space. Additionally some lens/camera setup information could be useful for CA correction and low-level noise reduction.
WB means sliders... NR & possible sharpening means again sliders... even CA can.
also some converters do apply curves before demosaicking...
however if you 1) take Adobe's workflow and 2) join the school of thought that demosaicking is the end of the raw conversion, then indeed ACR/LR are simply purely post-processing tools __UI wise__ (the only exception is the process version drop down control that shall affect things happening at least during demosaicking process).
-
Additionally some lens/camera setup information could be useful for CA correction and low-level noise reduction.
dcraw for instance is in my opinion such a 'just' raw converter.
Jack
Yes, very little mention of additional exif info. RAW files might contain proprietary information that the manufacturers RAW-converter might use to better reflect in camera settings or apply lens corrections.
-
WB means sliders... NR & possible sharpening means again sliders... even CA can.
also some converters do apply curves before demosaicking...
Fair enough, although really all you typically need is to know a little scene information, such as whether the capture was taken in the sun, the shade, cloudy. WB Sliders are a bonus and most people do not touch them.
Low level NR requires no sliders, just camera setup info (this has nothing to do with the noise reduction performed by most raw 'converters'). Sharpening is performed on rendered data in pretty well all raw converters, as far as I know.
No curves before demosaicing, though ideally a generic curve is already part of the color profile, per torger. Just select the scene type: Landscape, Portrait, Neutral, Standard (where have I seen those labels before?:-)
Jack
-
Low level NR requires no sliders, just camera setup info (this has nothing to do with the noise reduction performed by most raw 'converters'). Sharpening is performed on rendered data in pretty well all raw converters, as far as I know.
if you consider yourself as belonging to a school of thought that considers raw conversion ending with color transform then some raw converter can in fact do both regular NR and sharpening prior to that color transform for some reasons.
No curves before demosaicing
you then probably not familiar with RPP raw converter ?
-
WB Sliders are a bonus and most people do not touch them.
but they will be still present in UI regardless...
-
but they will be still present in UI regardless...
Not necessarily: dcraw does not have any sliders and I would argue that WB sliders in raw converters are all about pleasing tones as opposed to accurate ones: the former is PP, the latter is raw conversion.
Jack
-
Not necessarily: dcraw does not have any sliders
sure, as it is a command line tool - that is by defintion... however it can accept arbitrary multipliers for WB
and I would argue that WB sliders in raw converters are all about pleasing tones as opposed to accurate ones: the former is PP, the latter is raw conversion.
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
-
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
-
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 -> ...)
-
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
-
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.
-
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
-
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
-
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.
-
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
-
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
-
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
-
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.
-
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
--
-
Demosaicing also makes a statistical guess about the contribution to brightness of the red and blue, and this guess is only about 85% accurate.
-
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
-
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
-
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
-
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.
-
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
-
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
--
-
[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
-
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
-
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.
-
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
--
-
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.
-
<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.
-
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.
-
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.
-
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
(http://www.guillermoluijk.com/misc/procesoraw.jpg)
The translation from 3 to 4 corresponds to the following tone curve:
(http://www.guillermoluijk.com/misc/curva.png)
Regards
-
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