Finally, a raw histogram?

[tho_mas]

what you describe is not a "raw histogram"

I didn't say it's a "raw-histogram". I just explained how the histogram works as opposed to histograms on DSLRs where color conversion to AdobeRGB or sRGB comes into play.
see my reply #14: http://www.luminous-landscape.com/forum/index.php?topic=49859.msg411514#msg411514

[joofa]

Saturation clipping was occuring during rendering into the relatively narrow Adobe RGB space, which is the widest space available on this camera. One could eliminate such clipping through the use of ProPhoRGB.

A problem with a 2D representation of gamut, such as the one from Wikipedia below, is that it does not show the effect of the third dimension of the color space. Hence, while in a 2D plot the gamut of Adobe RGB might be contained in the gamut of ProPhoto RGB, indicating that it might have wider gamut as shown in the link below:

http://upload.wikimedia.org/wikipedia/commons/3/37/Colorspace.png

However, when the third dimension is taken into account it appears that around the blue region the gamut of ProPhoto RGB falls short of Adobe RGB as shown in the image below - i.e., there might be colors that clip for unit stimulus blue primary of ProPhotoRGB but are within the unit stimulus of Adobe RGB.



I did the calculation for the above image quickly so I have to double check that is indeed the case.

Hence, it appears that the most leeway is in the area closer to red, followed by green. Around blue the reverse might happen.

Joofa

[fdisilvestro]

there might be colors that clip for unit stimulus blue primary of ProPhotoRGB but are within the unit stimulus of Adobe RGB

Sorry if I don't follow you on this, but wouldn't it imply that the blue primary of ProphotoRGB would be visible? Or that there are invisible colors in AdobeRGB?

[fdisilvestro]

I didn't say it's a "raw-histogram". I just explained how the histogram works as opposed to histograms on DSLRs where color conversion to AdobeRGB or sRGB comes into play.
see my reply #14: http://www.luminous-landscape.com/forum/index.php?topic=49859.msg411514#msg411514

Ok, I understand what you mean, and I suppose C1 defalut color space is very large (Prophoto?).

Anyway, you may still encounter the case where the histogram shows clipping while the sensor is not, as in the case of ETTR. Only a raw histogram will show sensor clipping

[joofa]

Sorry if I don't follow you on this, but wouldn't it imply that the blue primary of ProphotoRGB would be visible? Or that there are invisible colors in AdobeRGB?

Sorry for confusion with the language here. Normally the white point is defined as that color which is obtained by adding unit stimulus of the 3 primaries (say RGB) after normalization. Hence, a "gamut" can be constructed for all colors that fall within this normalized set of primaries. A color can be outside this gamut if either (1) at least one of the primaries is used with a negative coefficient, which is not the case we are considering here, or (2) it needs more than the unit stimulus of at least one primary.

In the image I plotted the normalized unit stimulus primaries for each of the six primaries, 3 of Adobe RGB and 3 of ProPhoto RGB. It must be noted that unit stimulus length is not the same among primaries, in general. The length of unit Adobe blue primary stimulus turns out to be longer than ProPhoto unit blue stimulus. Which means that, if my calculation is right, then some colors can be around an area in blue which can fall within the gamut of Adobe RGB but outside the gamut of ProPhoto RGB.

Joofa

[tho_mas]

if my calculation is right, then some colors can be around an area in blue which can fall within the gamut of Adobe RGB but outside the gamut of ProPhoto RGB.

you have to equalize the whitepoint of the profiles. Yor findings are based on an abs.col D65 AdobeRGB and an abs.col D50 ProPhotoRGB. But the white points are totally irrelvant here. ProPhoto easily covers all colors contained in AdobeRGB.

[joofa]

you have to equalize the whitepoint of the profiles. Yor findings are based on an abs.col D65 AdobeRGB and an abs.col D50 ProPhotoRGB. But the white points are totally irrelvant here.

I don't think that the white points are irrelevant. These color spaces are 3-dimensional. And we already have a set of 3 vectors, i.e., RGBs. In a 3D space any 4th vector would be linearly dependent and not needed, - standard definition of the dimensionality of a finite dimensional space. Then why do we need the 4th vector (white point) in an otherwise 3D space? Think about it.

ProPhoto easily covers all colors contained in AdobeRGB.

I said I need to check my calculation. But based upon what I have right now it appears to be otherwise. But I shall double check.

Sincerely,

Joofa

[tho_mas]

I don't think that the white points are irrelevant.

matrix profiles in conjunction with current CMMs are limited to rel.col conversions... i.e. when the target profile is matrix based the only rendering intend available is re.col.
Create an AdobeRGB image in Photoshop with high saturated blues and set ProPhoto as proof color with color warning enabled. No clipping.
Change your color prefs to abs.col ... still no clipping.
So in terms of "real world color management" the white points are really irrelevant in this case.

[joofa]

matrix profiles in conjunction with current CMMs are limited to rel.col conversions... i.e. when the target profile is matrix based the only rendering intend available is re.col.
Create an AdobeRGB image in Photoshop with high saturated blues and set ProPhoto as proof color with color warning enabled. No clipping.
Change your color prefs to abs.col ... still no clipping.
So in terms of "real world color management" the white points are really irrelevant in this case.

Hi,

Lets not muddy the water by bringing in stuff such as profiles, rendering intents, photoshop, image creation, etc. The RGB primaries coordinates and their associated white points for both Adobe RGB and ProPhoto RGB are available on Wikipedia. You can start from there and verify what is going on here.

Joofa

[tho_mas]

The RGB primaries coordinates and their associated white points for both Adobe RGB and ProPhoto RGB are available on Wikipedia. You can start from there and verify what is going on here.

verify what? These things are also available as real profiles in real applications.
This is the shape of the profiles (abscol to D50; Adobe = white)... but this is just the shape of the profiles, totally independed from any real application:


This is what happens in color conversions:

[joofa]

verify what?

Verify, by producing a diagram similar to what I presented.

These things are also available as real profiles in real applications.

Yes.

This is the shape of the profiles (abscol to D50; Adobe = white)... but this is just the shape of the profiles, totally independed from any real application:

This is what happens in color conversions:
[Images Snipped]

See, I don't think you are getting what I am trying to say here. I think your lab graphs are the gamut displayed using all positive coefficients including those greater than 1 in original normalized space. Recall I said that we are considering unit stimulus here. So that would mean that for some colors Adobe RGB blue primary will be less than (normalized) 1, but the ProPhoto RGB blue primary is a little more than 1. If a color processing is such that it clips at 1, then it will clip it here.

Joofa

[bjanes]

sorry to disagree... the camera histogram shows clipping only in the red chanel and no clipping in the green chanel whereas ACR also shows heavy clipping in the green chanel.

Please read my post again:

"My camera (Nikon D3) does show a reasonable histogram and this histogram is very similar to that of ACR when one uses the necessary BaselineExposure correction of -0.5 in ACR. However, at times is is useful to look at the raw data without white balance. A good example is this yellow flower: the histogram with an ETTR exposure is shown in the ACR preview, when rendering into Adobe RGB, which was the space set in the camera and used for the JPEG preview and histograms. The histograms of the file as rendered into Photoshop by ACR are also show. The luminance histogram looks fine, but is heavily weighted towards the green so that the red and blue channels have little effect. The green in the RGB histogram is fine, but the red is clipped. Yellow, of course, contains red and green."

But on a Phase back such an issue simply does not exist. So I am looking at the "problem" from the other side...
You have to white balance the image at some point anyway... either when shooting or afterwards in the RAW software.
Attached 3 screenshots (from a Phase back). The 3 histos show exactly what the camera histo would show if you'd set the respective WB while shooting.
1.) white balanced (looking only at this crop you could even increase exposure by 1/3 or 2/3 stops).
2.) wrong WB 2000K - heavy clipping in the blue chanel.
3.) wrong WB 8000K - no clipping but due to the red chanel you wouldn't increase exposure here.

Now, as the white balanced histogram on the camera shows exactly the same as the histogram in the RAW software, it's pretty clear that white balancing while shooting is preferable with this system - you simply can see the real final outcome right on the camera LCD.
If you want so: it's consistent "out of the box" and this is why I couldn't care less about a "raw-raw"-histogram. The P1/C1-approach simply works... in terms of practicability.

You apparently do not understand white balance from raw. A phase one has WB multipliers just like Nikons and Canons. Values for the P65+ are shown from the DXO measurements. If the red or blue channels are close to clipping in the Phase One raw file, they will be clipped when the WB multipliers are applied, either in camera or in the raw converter. Your your histograms are apparently showing the values after WB either in the camera or in your raw converter. Nikon Capture behaves the same way as the camera histogram. Show me the values in the raw file.

Regards,

Bill

[tho_mas]

your histograms are apparently showing the values after WB either in the camera or in your raw converter.

yes, the histograms of course show the values after WB. All I wanted to point out is that I already see the exact same values when shooting (as there is no conversion to AdobeRGB or sRGB involved). Therefore white balancing while shooting helps to exposue as much as possible for a given WB (that I would apply in the RAW software anyway). That's all.
So again: Why would I know the real "raw" chanels? How ... or better: where can I make use of them? Do I need one of those awkward software tools? How can I profit from the real "raw" chanels in Capture One?

Show me the values in the raw file.

I can't. Rawnalyze doesn't support the respective files.

[bjanes]

yes, the histograms of course show the values after WB. All I wanted to point out is that I already see the exact same values when shooting (as there is no conversion to AdobeRGB or sRGB involved). Therefore white balancing while shooting helps to exposue as much as possible for a given WB (that I would apply in the RAW software anyway). That's all.

The derivation of the histogram of the Phase One backs is not available to me. Since it is white balanced, it obviously is not a true raw histogram. Is the histogram calculated before or after demosaicing and is it scene referred or output referred? Someone mentioned that it is gamma 1.8. Perhaps the histogram is derived after rendering into ProPhotoRGB. In that case, one would likely not encounter saturation clipping from rendering into a space that is too small to accommodate the camera space.

So again: Why would I know the real "raw" chanels? How ... or better: where can I make use of them? Do I need one of those awkward software tools? How can I profit from the real "raw" chanels in Capture One?

I can't. Rawnalyze doesn't support the respective files.

Knowledge of the status of the channels in raw file of the Phase One back would help in the same way as with the example for the Nikon. Apparently, the Phase backs do not have saturation clipping to any significant degree, but like any sensor they do have luminance clipping. The fact that the histograms on the camera and the raw converter are the same, tell nothing about the highlight headroom that Phase One uses. Does the histogram show clipping at the exact point where it occurs in the sensor? The only way to determine this is to look at the raw file and determine the sensor saturation at the point where the histogram shows clipping.

No, but DCRaw does support some Phase One backs. Guillermo Luijk has an excellent tutorial on DCRaw and he does cover white balance using normal WB coefficients as well as those that all are less than 1.0 that avoid clipping of raw channels during WB.

Regards,

Bill

[tho_mas]

DCRaw does support some Phase One backs. Guillermo Luijk has an excellent tutorial on DCRaw and he does cover white balance using normal WB coefficients as well as those that all are less than 1.0 that avoid clipping of raw channels during WB.

in other words: it would require to throw away all the usefull features Capture One provides and instead use an awakward software just to gain what... an increase of exposure by 1/3 or 1/2 stops under some lighting conditions?
Doesn't sound very profitable to me...

[hjulenissen]

why would I want to "calcuate back"?

Usually when you want to do something (exposure, filling the tires of your car...) you want to observe the primary issue (raw exposure, tire pressure...) directly, not some secondary measure that might correlate ok.

No matter how good your in-field WB setting is, if you ever edit your images besides cropping you would likely get some (possibly insignificant) gain from doing perfect raw exposures. It is simply the most sensible way to exploit the limitations of the sensor (unless the scene force you to underexpose). The hypothetical benefit may well be too small for you to mess with a good workflow, but that does not make it a less valid wish-list feature for cameras (be it crop or MF)

-k

[bjanes]

in other words: it would require to throw away all the usefull features Capture One provides and instead use an awakward software just to gain what... an increase of exposure by 1/3 or 1/2 stops under some lighting conditions?
Doesn't sound very profitable to me...

I certainly was not suggesting that you should use DCRaw for your routine work, but it is a powerful analytical tool. How much highlight headroom does your Phase back allow? Look at the DXO measurements shown in the graph. When set for an ISO of 100, the measured ISO of the P65+ is only 44. This means that if you expose according to the meter, the image will be underexposed by one stop. I take this to mean that the camera allows one stop of highlight headroom. The camera and the raw converter adjust for this in the tone curve so that the image appears normally exposed and a mid gray would be centered in the histogram shown by the camera or raw converter, but the raw histogram would show the actual exposure. These considerations are critical in ETTR.

Regards,

Bill

[tho_mas]

The hypothetical benefit may well be too small for you to mess with a good workflow, but that does not make it a less valid wish-list feature for cameras (be it crop or MF)

I appreciate your comments.
I've once tested in how far a color conversion filter on the lens improves things when shooting with tungsten light (2800K). A KB15 filter if I remember correctly...
The "improvement" re WB over shooting without the filter was 1/3 stop (or maybe 1/2). Couldn't care less.
But the filter decreased the lens performance...

[hjulenissen]

I certainly was not suggesting that you should use DCRaw for your routine work, but it is a powerful analytical tool. How much highlight headroom does your Phase back allow? Look at the DXO measurements shown in the graph. When set for an ISO of 100, the measured ISO of the P65+ is only 44. This means that if you expose according to the meter, the image will be underexposed by one stop. I take this to mean that the camera allows one stop of highlight headroom. The camera and the raw converter adjust for this in the tone curve so that the image appears normally exposed and a mid gray would be centered in the histogram shown by the camera or raw converter, but the raw histogram would show the actual exposure. These considerations are critical in ETTR.

Regards,

Bill

How much headroom would be needed anyways to account for inaccuracies in shutter, aperture, sensor/electronics drift in clipping point (temperature dependent?) etc? Is it perhaps wise of manufaturers to "hide" the true clipping point from users so they have some margin of error?

-h

[tho_mas]

Look at the DXO measurements shown in the graph

no, sorry... I never look at those DxO charts :-)

When set for an ISO of 100, the measured ISO of the P65+ is only 44. This means that if you expose according to the meter, the image will be underexposed by one stop

I can't replicate those values with my P45 and P21+.
I've just shot a BasICColor Grey card (see attachments).
My meter showed 30''/f4 for ISO50 (60''/f4 for ISO100 on the P21+).
Unlike other grey cards the BasICColor card reflects 25% grey (see attachment).
The respective Lab value is L*60.

Now, these are the shots from the P45 and P21+ without any adjusments made in Capture One (only WB); processed to TIF and opened in Photoshop.
Well, if you look at the Info palette in Photoshop I would say my meter works as supposed to... and so do the digibacks.
I don't use the meter anyway (at least rarely)... I mostly expose short of clipping highlights.

Don't know if this clarifies something with regard to DxO charts... it's simply just the outcome based on light metering and C1 processing...