If someone was to change the colour space of their image from AdobeRGB 98 to pro photo would the colour noise be more apparent and would this necessitate a stronger noise reduction in the chroma settings In a nut shell does a wider colour space mean a more noise in an image?TIA

I will try and explain it better My work flow up until now was to select Adobe RGB 98 in camera raw prior to processing After reading the benefits of using the pro photo setting in camera raw yesterday I noticed that a 1600 iso image looked more noisy than when it was set to Adobe RGB 98 Was I imagining this? IF not then when using neat image I would have to reduce noise more? Thus degrading the image more? Does a wider colour space mean more noise reduction? Or have I got it all wrong?TIA

Are you shooting Raw?

Yes Basically I am wondering about noise reduction in different colour spaces If a colour space has a bigger gamut does it need greater noise reductionTIA

Raw has no color space. You encode a rendering into a color space and hopefully, you can control as much noise reduction in the Raw rendering state as possible prior to encoding.

You DO want higher bit depth in wider gamut spaces, that's for sure.

No. Unless you do something silly like assigning ProPhoto to a sRGB JPEG. But that will cause major saturation overkill.

That statement is debatable. Look at the Adobe DNG Specifiation on page 47 where mapping from the camera color space to the CIE XYZ space is discussed. The conversion is done with a three by three matrix, just like a conversion from sRGB to ProPhotoRGB is done. If you look at the source code of DCRaw you can review the actual matrix coefficients and conversion code.

Apparently the folks at Adobe think that the camera has a color space.

Bill

Isn't this all about semantics?
The raw data as such don't have a color space in the sense that they have a meaning in terms of PCS, they're just values.
The matrix you describe acts as an input profile to map linearized camera values to PCS.

If the raw data were to have no meaning with respect to the PCS, then obviously it would not be possible to convert them to the PCS. Since they do have a relationship to the PCS, it is possible to convert from the camera space to CIE XYZ by a standard three by three matrix conversion. Here is an excerpt from the source code of DCRAW:

/*
Thanks to Adobe for providing these excellent CAM -> XYZ matrices!
*/
void CLASS adobe_coeff (char *make, char *model)
static const struct {
const char *prefix;
short black, trans[12];
{ "NIKON D200", 0,
{ 8367,-2248,-763,-8758,16447,2422,-1527,1550,8053 } },

As you can see, these values are a 3 by 3 matrix to convert from the Nikon D200 colorspace to CIE XYZ. Once that is accomplished, another transformation to the working space (e.g. Adobe RGB) can be performed. The details are described by Poynton. What is the difference?

As Bruce Fraser explained in Real World Photoshop CS2, a custom RGB space contains there elements: Gamma, White Point, and Primaries.

In the raw file some of these are implicit. The gamma is one, the white point is described by the white balance data in the raw file, and the primaries are described in the matrix. What is missing?

The spectral sensitivity of the chip.

Bruce's book points out that these chips are simply counting photons. There are colored filters over the matrix (we don't know anything about those colored filters). It is this reason I said the Raw file is Grayscale but I should probably have said something like the Raw file is essentially Grayscale.

Those matrix coefficients describe the spectral characteristics of the chip; again, without this information, it would not be possible to decode the raw file.

You state that a raw file is grayscale, but by the same token, as Bruce states on p. 119 of Real World PSCS2, "In Photoshop, files saved in the RGB mode typically uses a set of three 8 bit grayscale files..." [bold added for emphasis]. No essential difference here.

Let's quote Bruce on a more recent book (and then we have the Schewe update which I haven't seen yet):

Page 2 of RW camera Raw:



Further on page 3 he writes:

QUOTE

Getting back to your quote of Bruce's, its apples and oranges here. He's talking about an RGB file which of course is three Grayscale channels. That's not what he (or I) are talking about with respect to Raw. AFTER demoiscing, when the data is rendered it is in some RGB color space (in Camera Raw and LR, that's ProPhoto RGB linear encoded gamma) and then you can pick an output color space (an encoding color space). But long before this, your Raw data is Grayscale.

I would say that it is more like oranges and tangerines. Both raw and RGB are monochrome, but carry encoded color information. The typical Bayer CFA raw file has four components: green 1 , green 2, blue and red. An RGB file contains three components. What is the difference? You don't need to demosaic to view color information. If you decoded the four streams and viewed the result from a distance, the eye would blend the primaries into the proper colors.

So in essence, Bruce has stated in one publication that RGB consists of 3 monochrome components, and in another that raw has 4 monochrome components. I don't think that the principles of color theory have changed in the more current publication. Furthermore, what is your response to the Adobe DNG specification which refers to a camera color space? This may all be semantics, but the spaces are more similar than they are different. Three by three matrix transformations can be used on either.

So what's the color space of the raw data?

It is the native color space of the camera--in the quoted DCRaw case, that specified by the matrix values shown. In DCRaw, those are used to convert from camera to CIE XYZ. You can then use another 3 by 3 matrix conversion to your working space. Adobe DNG also describes a camera color space. How can you reasonably deny these facts? Did you look at the DNG specification?

While it may be spec as a 3x3 matrix, what the "camera color space is" is actually the identification of the camera's spectral properties at a given white point...and as such is NOT a "profile" in ICC parlance...so while a camera DOES have a spectral response (at a given white point) is doesn't have a "color space" as it relates to a working space and it's also not an input profile...so saying that a camera does not have a color space profile attached to it would be correct.

ICC or not, then why does Adobe refer to the Camera Color Space in the DNG specification? Someone at Adobe must consider it to be a color space. As mentioned above, it does have the three main elements of an ICC matrix color space (primaries, TRC, and white point), and it can be transformed to an ICC working space via a 3 by 3 matrix transform. If it looks like a duck, walks like a duck, and quacks like a duck, it may be duck or at least something pretty close. A document in aRGB may not have a color space tag attached to it, but one can be assigned.

It doesn't have a white point designation until AFTER conversion from the camera color (which is a more accurate way of describing what the raw file contains) to a "color space". All the camera color has is the chromaticities of the spectral response and the assumption of linear gamma. Without the designated white point (to be determined by the metadata tag or overridden by the processing software) it's not yet a complete "color space". Reading the spec is useful, but the terminology must be understood for what it means. This is the same limitation raw captures have when trying to apply input profiles (ala Capture One) to raw captures...since a raw capture doesn't yet have a complete set of chromaticities, gamma and white point, you can't really presume it has a profilable color color space.

And, returning to the OP question;


No...the noise in an image is dictated by the ISO settings in combination with the expansion of darker tones to lighter tone (lightening the shadows) such as would occur when moving the Exposure setting (or Brightness) to the plus values...

It does have white balance information, which DNG encodes as AsShotNeutral and as AsShotXY. Doesn't that count as white point designation?

You keep fishing for a raw file or DNG to have a "color space" as it is commonly associated with ICC style profiles and Photoshop working spaces. If you want to parse the words of the DNG spec and presume to attribute terms and their meanings, more power to ya, but it does a disservice to the industry to engage in a practice that will end up confusing people's understanding of raw linear captures and Photoshop working spaces and input profiles associated with scanners and cameras...

Raw captures do NOT have a "color space as it is defined by the ICC spec and associated with working color spaces in Photoshop". Raw captures are actually grayscale files whose color attributes are not yet assigned until the demosiacing process.

There, ya happy?

Ya know, sometimes you end up beating a dead horse bud...and the horse is beyond caring.
(and other people's eyes start to glaze over)

The consequences of using Pro Photo in the ACR conversion are:

1. some colors, which are not contained in aRGB nor in sRGB are now representable, particularly in the deep blue and red,

2. the resulting gamut is much, much larger than what your monitor can reproduce (already aRGB is larger).

This means, that you don't see everything as it is in the image, consequently what you see is not only the noise in the image, but the noise due to the lack of gamut coverage of the monitor. If this is something perceivable, depends on the actual image.

This thread reminds me the thread on the Adobe Camera Raw forum that was set to read only by the forum administrator because of abusive ad hominem attacks on the participants. Schewe's characteristic shouting and bullying is not unlike the tone of that thread.

First of all, no one stated that the native camera space corresponded to an ICC profile, so arguments along that line of reasoning are invalid. Then the argument is that raw files are grayscale and couldn't have a color profile. As Bruce Fraser stated, on p. 119 of Real World PSCS2, "In Photoshop, files saved in the RGB mode typically uses a set of three 8 bit grayscale files..." [bold added for emphasis]. Well, that argument is out.

Then it was stated that the camera data were not a space since there was no white point. Well, CIE XYZ has no white point either, but it is a color space even though it does not meet the ICC spec.

Chapter 6 of the Adobe DNG specification concerns converting from the Camera Color Space to the CIE XYZ Space. Adobe is pretty stupid to spend an entire chapter on something that does not exist. But then the mafia people know better, and they circle the wagons when challenged. If Schewe can't win his argument by reasoning, he resorts to bullying and shouting.

I'm sure that by this point no one is interested in pursuing this topic any further, but I just wanted to make a point. Furthermore, understanding of the camera color space helps us to understand the calibration procedure in ACR. We are modifying the 3 by 3 matrix values from the Adobe Camera Raw defaults to ones more descriptive of our own camera. These coefficients are used to convert the native camera color space to the internal color space of Camera Raw, and represent the Camera Raw Profile.

Any chance of someone answering my original question? In camera raw does setting Prophoto instead of AdobeRGB increase noise because there is a wider colour gamutTIA

Bob, your question has been answered.

No. It doesn't.

I answered your question as well in post #6 of this thread. Color space has no effect at all on visible noise levels, unless you do something retarded like manually assigning the wrong profile after conversion, which will not only affect visible noise levels, but also cause over or undersaturation. Short answer: NO.

The gamut of the camera is much larger, than sRGB or even aRGB. Consequently, when mapping, the original pixel values get closer to each other, the originally existing noise diminishes.

The gamut of ProPhoto is perhaps somewhat larger than the camera's gamut, and anyway much larger than aRGB, so the mapping yields larger spacing between the original pixel values than with aRGB, i.e. more noise.

However, all this is present only in 16-bit TIFF. What you see is far from that; the more colors of the larger gamut "are not there", for the monitor supports only 8bit sRGB, and you probably see noise, which is not in the image; that's what I tried to explain above.

In order to see the "true noise", you have to inspect the raw image in the camera's color space, i.e. w/o converting the colors (but then the colors are not "true", for you are viewing them on an sRGB monitor).

In order to test the noise hypothesis, I rendered the same raw file into sRGB and ProPhotoRGB and analyzed the noise response with Imatest Stepchart. The overall luminance noise is the same (0.38% and 0.36% respectively), but the resulting TRCs are different and the distribution of the noise is different along the TRC. I think that this has to do with the gamma of the spaces (sRGB is 2.2 and ProPhotoRGB is 1.8). The actual gamma of the converted files are 1/1.58 for the ProPhoto and 1/1.68 for the sRGB. If one converts the ProPhotoRGB file to sRGB and reanalyzes, then the noise characteristics are exactly the same.

Click to view attachment

Click to view attachment

Click to view attachment

Digital cameras don't have a color gamut, they have color mixing functions.

To even profile a camera, to get some idea of its so called gamut, you have to place a target of known color values in front of the sensor. That target does have a gamut, the gamut of the resulting profile can't be larger than the target, hence the problems here both profiling the camera and trying to define its so called gamut. Then we can discuss how this so called gamut is affected by the illuminant used to shoot the target as well as the dynamic range of whatever you now place in front of the camera or the role of the Raw converter in rendering the image. So, lets not even begin to try to discuss the gamut of a digital camera (because again, it doesn't have one).



Again, that's simply speculation and I'll add, the gamut of ProPhoto RGB contains colors that fall outside human vision (although digital cameras can clearly capture stuff outside human vision). But, you're using such differing terms and processes that the two just don't sync up.



And that camera color space would be what? We're talking Raw data again (essentially Grayscale data to get back another post here that's up to debate).

This is completely false, at least in relation to how visible the noise is in the image, whether on screen or in a print. Converting from one color space to another alters how the noise is encoded, but as long as all image colors are in-gamut, converting from one color space will have no effect on how noisy the image looks on-screen or printed, as long as you do so in 16-bit mode so that quantization errors are not an issue. Minor differences in noise measurements of the sRGB file versus ProPhoto or whatever cancel out exactly once you correctly account for the differences in gamut and TRC defined by each color space.

duplicate post deleted by maker

I was waiting for the mob to employ this tactic: falsis in unum, falsis in omnibus , which is used in legal arguments to discredit a witness. A digital camera does not have a gamut in the sense of a space with well defined boundaries. However, the dictionary definition is "an entire range or series <ran the gamut from praise to contempt>" and a digital camera does have a gamut in this general sense.

Rather than nit pick about peripheral issues (digital camera has no gamut, a raw file has no color space), it would be best to remain on topic and address the main issue rather than try to put down others and show one's own erudition. This is a forum where we are all trying to learn, not a court of law with an adversarial climate. The main thrust of the argument was false, as Jonathan pointed out.

Ironically, I never posted in that thread...so I guess Mr. Janes is trying to paint me with a brush of "similarity"...

"shouting and bullying"? Strikes me that THAT is an ad hominem attack...

Never the less, I thought I would show some images to help make my points. Here's a few images from RWCR CS3 showing some rarely seen real raw images:


The image above is a real raw image, processed but not demosiaced. It was processed through DNG Verifier to show what the image looks like when written to disk...


Here's the same image processed through Camera Raw.

So, what color space is the original grayscale raw image in? The actual raw image is indeed grayscale until the image is demosiaced...and not only is it grayscale, it's in linear gamma.

You see the tiny green rectangles? Here are some details from those areas...


The image above is taken from the original file processed through DNG Verifier then blown up in Photoshop to 3,200 % zoom. You can actually see the original Bayer array pixels. You'll note that the dark pixels in the area that is actually yellow shows the blue pixel photo sites.


This is the same area of pixels shown in the detail image above. The grayscale tones have now been interpolated into color information. It is this demosiacing interpolation that gives color information to the grayscale pixels.

So, again, in terms of the RAW file before demosiacing interpolation, what would be the "camera color space"? In actuality, it has no color space until the manner of demosiacing interpolation is determined and the tags regarding white point are provided and factored into the interpolation.

Even then those tags are subject to interpretation...what the original raw does have is a spectral response based on the properties of the Red, Green & Blue separation filters that are used to filter the white light to capture the RGB response properties, but that data is held in B&W until demosiacing.

So, ya still think that the original raw capture has a color space?

Very cool Jeff. Where does one get DNG Verifier? This is a great way to illustrate a Raw processed by not yet demosiaced.

No put down intended. The fact is, a digital camera doesn't have a color gamut and a Raw file doesn't have a color space. Some here don't consider this a nit pick.

It's part of the DNG SDK...and intended for geeks (Zalman had to teach me how to run it because you run it via command line).

:~)

OK, never mind. I'm not about to mess around with command lines! But, a very interesting illustration of the processing none the less.

The gamut is the amount (range) of reproducible colors. This has nothing to do with the question how it can be profiled.

To even profile a camera, to get some idea of its so called gamut, you have to place a target of known color values in front of the sensor

This is the description of how you would do it. Again, it has no role here.

Btw, the spectral responses of the filters define the gamut of the camera, but manufacturers don't publish this information. (Though one could measure it with suitable equipment.)



That camera color space would be that camera's specific color space. If you want a name to it, use the camera model, or in some cases the sensor "model" (sometimes the same sensor is used in different cameras).

And you define this gamut, from a Raw file how?

To even profile a camera, to get some idea of its so called gamut, you have to place a target of known color values in front of the sensor



And YOU would profile it how?

In light of Jeff's example above, what gamut does the image have processed but not demosiaced?

I don't know, I am not that business. However, some others are obviously doing that (and the manufacturers, who know the spectral response of the filters, certainly know the gamut of their own equipment).

Micheal Reichmann shows the color space of the Canon 20D in here. He even thanks Bruce Fraser and Jeff Schewe for their feedback and suggestions; the latter must have forgotten it already.



You are mixing up the gamut of the camera and of the scenery/actual image. The subject is the former.

Here is the surprize: pls display an RGB color image in PS and disable two of the three channels. Then pls post here, what you see.



Totally irrelevant.



The range of colors, which can be reproduced by those sensors.

The fact, that the raw data has to be processed before being displayed has no relevance. Try to display a Lab image on an RGB monitor without conversion, or even an RGB JPEG, which is kept in YCbCr form.

The raw data too can be dislayed in color without de-mosaicing, although the result is not as pleasing as after the de-mosaicing.

See the Channel view of the color checker. It is in TIF, so that one can see it magnified without JPEG artifacts. In 600% you can see the individual pixels.

(In this view every monitor pixel represents a green, red or blue filtered pixel of the sensor; the two other RGB channels are zero.)

You sir are the confused one. The gamut they show is based on ICC profiles built as I described by shooting a target (which has a fixed gamut). That doesn't mean the capture device is being fully defined by this profile because its not, because a digital camera doesn't have a gamut as I've tried to explain to you.

In a nutshell, a color mixing function, also called a color matching function, is a mathematical defined representation of a measured color based on three monochromatic RGB primaries that would duplicate the observed color of a measured wavelength. Until its mapped into a defined RGB space, it can’t have a color gamut.

Ah, but the raw capture is not a 3 channel image file...it's a grayscale (single channel) image file (which was the whole friggin' point of posting what the raw files actually looks like).

Through demosiacing, the pixels that represent the R, G, & B photo sites are used to interpolate the component RGB color files. See, it's a case of turning a grayscale file into a color file that is the whole point of a Bayer array sensor.

From the FAQ's on Munsell Color Science Laboratory:

Question:
"Digital image sensors (such as those used in digital cameras)use red, green, blue ink-based color filters to generate color. Do they therefore have a color gamut that limits the range of colors that they can detect? (255)"

Answer:
"Let's start with the short answer to your question; there is no such thing as a camera, or scanner, gamut. A gamut is defined as the range of colors that a given imaging device can display. To say that a camera had a gamut would be to imply that you could put a color in front of it that it could not possibly respond to. While it is certainly possible that two colors that are visually distinct might be mapped into the same color signals by a camera, that does not mean that the camera could not detect those colors. It just couldn't discriminate them. For example, a monochrome sensor will map all colors into a grayscale image and encode it as such. Certainly the encoding has a gamut (in this case a lightness range with no chroma information), but did the camera responded to all the colors put before it. It is the encoding that imposed the gamut. In the color world, encoding is based on some explicit or implied display. For example, sRGB is a description of a display and therefore defines a gamut (but only if the sRGB values are limited in range). If a camera encodes an image in sRGB, that doesn't mean that the range of colors the camera detected are only from within the sRGB display gamut, but it means the camera data have been transformed to best use that sRGB encoding. As long as a camera has three or more sensors that span the visual spectrum, then it will respond all the same stimuli as our visual system. Whether the camera can discriminate colors as well as the human visual system will depend on the encoding of the camera signals, quantitization, and the details of the camera responsivities. (To return to the black and white system, that camera encodes all the colors into a gray scale. They could then be displayed as any color within a given display, but many colors from the original scene would be mapped to the same values.)

Since there is no such thing as a gamut for an input device, then there is no way to compute it or calculate a figure of merit. Generally, the accuracy of color capture devices is assessed through the accuracy of the output values for known inputs in terms of color differences. Also, sensors are sometimes evaluate in terms of their ability to mimic human visual responses (and therefore be accurate) using quantities with names like colorimetric quality factor, that measure how close the camera responsivities are to linear transformations of the human color matching functions. Doing an internet search on "colorimetric quality factor" will lead you in the right direction."

LOL, that's good. Each channel of an RGB file is only a grayscale on its own.

Nothing differentiates the color channels, except their interpretation.

You can copy the content of the red channel of an RGB image over the green channel, and suddenly the image has different colors.

The channels of the raw images are greyscale on their own. Together they constitute a color image. The only real difference between raw and RGB channels is, that the "colors" of the raw channels are overlapping. However, this fact does not make the raw image a colorless one.

You are overstressing the role of de-mosaicing. Although it is essential for the reproduction of the original colors, it is not essential for having a color image.

Following images are another views of the raw data (from the same color checker as above, shot with a Nikon D200): no de-mosaicing occured, but now each color filter array is shown as a single pixel; the three RGB components are directly from the raw channels (the two green have been averaged):



and the same with white balancing:

Do you get it yet?

No, you STILL don't get it...a raw capture is only a single channel grayscale file. It is only through the demisaicing interpolation that the color data is extracted from the grayscale file and rendered as color data in a 3 channel file.

Note, the original un-demosiaced files that I posted were actually in a linear gamma, grayscale space that I converted to sRGB for the purpose of posting.



No, the raw file _IS_ a single channel grayscale file UNTILL demosiacing...you DON'T have ANY color in the single channel file WITHOUT demosiacing.

In the original, single channel grayscale file in linear gamma, each photo site is represented as a single pixel of either red, green or blue data from that photo site (ya gotta blow it up REAL BIG to see the individual pixels). There are 2x the number of green photo sites as red or blue (hence the Bayer array unless you are talking Foveon chips).

To better understand the demosiac process, see: Demosaicing

I can't believe that your reasoning is so very simplistic. If I take a TIFF and delete the blue and red channels, I don't see any green at all. All I see is monochrome. As Bruce Fraser has stated, an RGB file consists of three monochrome channels, so this is not surprising. But by your simplistic interpretation, there is no green in the image. If I view the file in a hex editor all I see are hex numbers. Gee, you have to view the file with a program that knows how to interpret the data.

BTW, you don't have to jump through hoops with some command line program to view undemosaiced files. You can use the freeware program Iris.

Here is a crop from a shot of a flower:

Click to view attachment

A closeup of the ACR conversion is on the left and the raw file as shown by iris. The red, blue, and green information is all there in the Bayer grid. The colors of the array can be viewed without demosaicing with the SPLIT_CFA command. Instead of being present on three layers, they are all in one layer in a grid pattern, but they are still there and separate.

Click to view attachment

Do you mean channels?

What application are you talking about with the "SPLIT_CFA command"?

Schewe, you are the one who is not getting it. With a Bayer array you can use a program such as Iris (do a google search) to separate the Bayer grid into four files representing red, blue, green1 and green2. No demosiacing is involved. The color information is distributed in the grid, whereas with a regular RBG file the color information is on three separate channels. You can not get color from a single gray scale file.

In your demonstration of the Bayer grid, if you painted in color on the grid according to the color of the filter, you would see a color image. Each pixel would have only one color, but if you viewed the image from a distance the colors would be blended by the eye.