Luminous Landscape Forum
Equipment & Techniques => Medium Format / Film / Digital Backs – and Large Sensor Photography => Topic started by: bjanes on December 27, 2010, 10:20:23 am
-
In his recent review of new firmware for the Leica S2, Mark Dubovoy noted that the histogram is now based on the raw data and is not derived from a JPEG preview. Many have been requesting this for years, but thus far, only Leica has listened to its customers. Does the S2 also have RGB histograms based on the raw data and not referred to a relatively narrow space such as AdobeRGB or sRGB?
Regards,
Bill
-
Many have been requesting this for years, but thus far, only Leica has listened to its customers.
Not just Leica :-P. Phase/Leaf.
One of the benefits of not having in-camera JPGs is you can't base your histogram off of them :-).
-
Not just Leica :-P. Phase/Leaf.
however the histogram is Gamma corrected. Gamma 1.8 (with Phase)... as Capture One is based on Gamma 1.8.
I am finding a Gamma corrected histogram very practical anyway... actually for me it's not so important if the histo on the camera is Gamma corrected or not... it's much more important that the RAW software shows the same histo as the camera for the respective capture (and C1 shows the same histo, at least with Phase backs).
-
How is White Balance handled in these "raw" histograms?
Cheers,
Bernard
-
however the histogram is Gamma corrected. Gamma 1.8 (with Phase)... as Capture One is based on Gamma 1.8.
I am finding a Gamma corrected histogram very practical anyway... actually for me it's not so important if the histo on the camera is Gamma corrected or not... it's much more important that the RAW software shows the same histo as the camera for the respective capture (and C1 shows the same histo, at least with Phase backs).
Gamma encoding is desirable for all but purists, or else everything occurs on the left. Even better IMHO would be a log base 2 encoding, since we photographers tend to think f/stops. For proper ETTR exposure, it is imperative that there is no headroom safety factor for the highlights.
Regards,
Bill
-
How is White Balance handled in these "raw" histograms?
Hopefully, WB would not be peformed and the raw channels are merely displayed. As long as no channel clipping takes place, one can white balance using multipliers less than 1.0 if needed to prevent clipping.
Regards,
Bill
-
How is White Balance handled in these "raw" histograms?
WB is reflected in the histogram.
For proper ETTR exposure, it is imperative that there is no headroom safety factor for the highlights.
there is no headroom... exposure warning is first shown on overexposure... so at RGB levels above 255.
we photographers tend to think f/stops
Caputre One provides an additional histogram to display exposure evaluation (as opposed to the histogram that shows the values of your adjusted capture incl. levels, curves, color edits, whatever...). The scale of the exposure evaluation also shows f-stops (see attachment). The histogram on the digibacks do not show these indications... however you can use Capture One's indications as reference. If you are really anal you could also draw the scale on the back's LCD with a permanent marker ;-)
Hopefully, WB would not be peformed and the raw channels are merely displayed. As long as no channel clipping takes place, one can white balance using multipliers less than 1.0 if needed to prevent clipping.
Sounds cumbersome. Why not just set the correct WB while shooting? Or at least a preset that comes close (tungsten, daylight etc.). This way the histogram is "WYSIWYG" (so to speak).
I can understand that it may be annoying for you that your camera doesn't show a useful histogram and that your RAW software doesn't show the same histogram as your camera. But these limitations do not apply to all systems... obviously.
-
I have a Sanho HyperDrive Album which has been the subject matter of other threads in this forum, including one I initiated myself. One of its attributes is to enable one to examine one's RAW output in the field, by transferring a RAW image from the camera to the Album via the memory card. The Album does contain a histogram. The discussion in this thread has prompted me to query the Sanho technical staff to determine whether the histogram depicted in the Album for a RAW file is genuinely that of the RAW file and not of the accompanying JPEG image. The reply I just received is: "If you decode the image file in RAW, the histogram represents what's in the RAW file." I don't know how much use this is to anyone else, but I thought I'd pass it along.
-
Why not just set the correct WB while shooting? Or at least a preset that comes close (tungsten, daylight etc.). This way the histogram is "WYSIWYG" (so to speak).
Because the the application of WB distorts the histogram (it amplifies some channels more than others), and it doesn't help to see if there is raw clipping (and where).
If a channel blows because of WB application but is not blown in the raw capture, it's easy to deal with in processing.
If the raw data is blown, you lost...
-
Because the the application of WB distorts the histogram (it amplifies some channels more than others), and it doesn't help to see if there is raw clipping (and where).
If a channel blows because of WB application but is not blown in the raw capture, it's easy to deal with in processing.
If the raw data is blown, you lost...
again, that might apply to your system as your RAW software doesn't show the same as the LCD on your camera. If you are working with a Phase back & C1 the clipping shown on the camera's histogram and C1's histogram is absolutely consistent (I guess it's the same with Leaf + Hasselblad). This is why it makes sense to adjust the WB when shooting.
Sure you can shoot for instance with a too cold WB to avoid color clipping in the red chanel... but when you alter the WB in the RAW software clipping in the red chanel will be introduced. So what did you gain?
-
Hopefully, WB would not be peformed and the raw channels are merely displayed. As long as no channel clipping takes place, one can white balance using multipliers less than 1.0 if needed to prevent clipping.
Sounds cumbersome. Why not just set the correct WB while shooting? Or at least a preset that comes close (tungsten, daylight etc.). This way the histogram is "WYSIWYG" (so to speak).
I can understand that it may be annoying for you that your camera doesn't show a useful histogram and that your RAW software doesn't show the same histogram as your camera. But these limitations do not apply to all systems... obviously.
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.
Camera histogram:
(http://bjanes.smugmug.com/Photography/ETTR2/12Camera/1140452208_omgUp-O.png)
ACR histogram with Exposure -0.5 baseline correction:
(http://bjanes.smugmug.com/Photography/ETTR2/ACR12defaultExpMinusHalf/1140452150_EQSd8-O.png)
Photoshop luminosity histogram:
(http://bjanes.smugmug.com/Photography/ETTR2/PhotoshopLuminosity12/1140469560_UJrpj-O.png)
PhotoshopRGB composite histogram:
(http://bjanes.smugmug.com/Photography/ETTR2/PhotoshopColorHisto/1140469591_wgiAJ-O.png)
Rawnalize histogram showing the raw data without any white balance:
(http://bjanes.smugmug.com/Photography/ETTR2/012Photobola/1140448854_7WfaD-O.png)
Examination of the raw file in Rawnalize shows that the green and red channels are short of clipping. However, the WB multiplier for the green channel is 1.0 and that for the red channel is 1.7 as shown by Rawnalize. When white balance is applied, the red channel will be clipped, whereas it is intact in the raw file. One could decrease exposure in the camera so that the red is not clipped during normal white balance with a red multiplier of 1.7. However, a better approach is to use multipliers all less than one so that no white balance clipping can occur and one can get a better signal:noise. One can do this directly in DCRAW, but in ACR one would decrease the exposure.
To obtain a better evaluation of the RGB channels in the raw file, many Nikon users load a special White Balance into the camera, so that white multipliers of 1 are used for all channels (UniWB). A related ploy regarding WB is to place a magenta filter over the camera lens to hold back some of the green light and obtain a better balance between the channels. This can easily add a half stop to the DR. With older cameras with a limited DR, this was advantageous, but it is probably not worthwhile with current state of the art cameras.
Regards,
Bill
P.S.
In the example shown, it was not possible to eliminate red clipping by any reasonable decrease in exposure, becuase 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.
-
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
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.
Again, those workarounds might be great for you as you use tools that do not show consistant histograms.
Therefore it's also quite understandable that you try to find a workaround.
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.
-
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.
Again, those workarounds might be great for you as you use tools that do not show consistant histograms.
Therefore it's also quite understandable that you try to find a workaround.
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.
But arent you mixing source representation with target representation?
The camera sensor clips when the camera sensor clips, no matter WB. Sensor clipping is something we usually want to avoid or limit.
If any transforms or gains are applied to the image before a histogram is calculated it is harder to "calculate back" how close to sensor clipping we are.
If you have saved a good exposure to file, it is a trivial operation for offline editing programs to do calculations in floating point or increased integer precision so that WB can be done without clipping and with negligible loss of precision.
-h
-
Examination of the raw file in Rawnalize shows that the green and red channels are short of clipping. However, the WB multiplier for the green channel is 1.0 and that for the red channel is 1.7 as shown by Rawnalize. When white balance is applied, the red channel will be clipped, whereas it is intact in the raw file. One could decrease exposure in the camera so that the red is not clipped during normal white balance with a red multiplier of 1.7. However, a better approach is to use multipliers all less than one so that no white balance clipping can occur and one can get a better signal:noise. One can do this directly in DCRAW, but in ACR one would decrease the exposure.
P.S.
In the example shown, it was not possible to eliminate red clipping by any reasonable decrease in exposure, becuase 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.
As you point out at the end of the message, the red clipping is not due to wrong exposure, but an out of color gamut in the AdobeRGB color space. IMO the best approach is to use the ProphotoRGB color space before any exposure correction.
The histogram from Rawnalize show luminosity values for each channel, so one can determine if there was saturation at the sensor level, but does not give information about saturation, since the data hasn't been converted yet to a color space.
In any case, reducing exposure in the raw converter should not add noise. Doing it at exposure time will reduce signal to noise ratio.
Just a comment about using multipliers lower than 1 for white balance: This works fine as long as there are no blown out channels, otherwise it could produce color cast in those areas
-
But arent you mixing source representation with target representation?
I don't know... possibly.The camera sensor clips when the camera sensor clips, no matter WB. Sensor clipping is something we usually want to avoid or limit.
correct.If any transforms or gains are applied to the image before a histogram is calculated it is harder to "calculate back" how close to sensor clipping we are.
but why would I want to "calcuate back"? As you said: when the sensor clips it clips (so we stop down). The situation that the sensor is actually not clipping but the histogram yet shows clipping (due to a conversion into a color space such like AdobeRGB or sRGB) simply does not exist on a Phase back. At least not as long as you white balance while shooting. You could produce "fake"-clipping in the histogram although there is no sensor-clipping when you set a completely wrong WB while shooting (as demonstrated above).
This is why I said "WYSIWYG"... when you set WB accurately while shooting (so that no further WB adjustment is needed in post) you can effectively see how far you can increase exposure when shooting.
-
The problem with WB being reflected in the in-camera histogram is that it can lead you to believe that a channel is clipped when in fact it is not.
The other problem is that there may be other color conversions in play (e.g., a transformation from the camera primaries to standard primaries, like sRGB / Adobe RGB).
Bill has a good example with the yellow flower. Many cameras (especially recent Canon models) have a much weaker red channel compared to the green channel. Even when photographing a red rose under bright outdoor conditions, the native green channel will clip first, before the red. Using white-balanced camera histograms, with possible additional color conversions on top of it, make it very difficult to predict how to optimize the exposure.
The fact that WB has to be applied at some point (e.g., during raw conversion) is completely separate from the idea of an in-camera histogram that helps the user optimize exposure (e.g., by maximizing signal-to-noise).
-
The problem with WB being reflected in the in-camera histogram is that it can lead you to believe that a channel is clipped when in fact it is not.
not on a Phase One back (I guess: not on any MFD back)... only if the WB set when shooting is way off.
The other problem is that there may be other color conversions in play (e.g., a transformation from the camera primaries to standard primaries, like sRGB / Adobe RGB).
not on a MFD back.
The fact that WB has to be applied at some point (e.g., during raw conversion) is completely separate from the idea of an in-camera histogram that helps the user optimize exposure (e.g., by maximizing signal-to-noise).
see my last post.
-
Tho_mas
Are you claiming that WB affects Raw data in MFD back? It is not metadata?
-
Tho_mas
Are you claiming that WB affects Raw data in MFD back? It is not metadata?
no. WB affects the histogram... not the actual RAW data.
but as the histogram is built off of the actual RAW data and is only altered by gamma (to be more precise: a gamma 1.8 default color space that corresponds to the default color space in Capture One) and WB it's exactly what you see in the RAW software. (Of course only if you set the correct settings in the RAW software.) Therefore a WB while shooting is not counterproductive ... quite the opposite: it helps to expose as much as possible without clipping (at a given WB).
-
While I agree that you method reduce the amount of time spent in post processing, the fact is that what you describe is not a "raw histogram"
Gamma does not define a color space and it affects the middle values but not the extreme values, so if you are after the clipping point, it will make no difference
A raw histogram shows only the luminance level in the channels, there is no info about color saturation. It is only when you convert to a color space when a non clipped sensor channel may result in a clipped channel because of saturation in the output color space. As long as the original luminosity value is not clipped, you can adjust in post processing (of course, it will be time consuming)
-
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
-
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 (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.
(http://djjoofa.com/data/images/adobe_prophoto_rgb.gif)
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
-
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?
-
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
-
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
-
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.
-
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
-
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.
-
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
-
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:
(http://www6.pic-upload.de/30.12.10/1zwpmhoq7zii.jpg)
This is what happens in color conversions:
(http://www6.pic-upload.de/30.12.10/3ozvthhv8ia6.jpg)
-
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
-
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
-
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.
-
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 (http://www.cybercom.net/~dcoffin/dcraw/) does support some Phase One backs. Guillermo Luijk (http://www.guillermoluijk.com/tutorial/dcraw/index_en.htm) 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
-
DCRaw (http://www.cybercom.net/~dcoffin/dcraw/) does support some Phase One backs. Guillermo Luijk (http://www.guillermoluijk.com/tutorial/dcraw/index_en.htm) 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...
-
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
-
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
-
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...
-
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
-
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...
-
tho_mas, I believe even the Phase backs' LCD histograms would display the red channel as clipping in the example I described, even if the WB is dead-on. (I am reasonably certain of this, at least with a P65+, having tried this specific test myself.) It is true that the raw data itself for the red channel may not be clipped, but the point I am making is that the LCD feedback shows that it is ... thereby making it impossible for the photographer to know in the field whether or not it actually is.
The usual advice is to reduce the exposure until the LCD histograms do not indicate clipping. Unfortunately, this usually then results in an underexposure by a stop or more. In this context, by "underexposure" I mean that the photographer could have increasing exposure (e.g., by increasing the exposure time) by 1 or more stops, without clipping any raw data.
-
tho_mas, I believe even the Phase backs' LCD histograms would display the red channel as clipping in the example I described, even if the WB is dead-on. (I am reasonably certain of this, at least with a P65+, having tried this specific test myself.) It is true that the raw data itself for the red channel may not be clipped, but the point I am making is that the LCD feedback shows that it is ... thereby making it impossible for the photographer to know in the field whether or not it actually is.
The usual advice is to reduce the exposure until the LCD histograms do not indicate clipping. Unfortunately, this usually then results in an underexposure by a stop or more. In this context, by "underexposure" I mean that the photographer could have increasing exposure (e.g., by increasing the exposure time) by 1 or more stops, without clipping any raw data.
Eric, I understand all that.
My question is: what do you do afterwards (in post) with your "accurately" exposed capture (i.e. the one that shows clipping only the LCD but not in the raw chanels)? How do you white balance it without introducing clipping?
-
Eric, I understand all that.
My question is: what do you do afterwards (in post) with your "accurately" exposed capture (i.e. the one that shows clipping only the LCD but not in the raw chanels)? How do you white balance it without introducing clipping?
You will have to adjust exposure and/or brigthness. If it is a color outside of output color space then maybe vibrance or saturation
If the raw converter used white balance coefficients less than 1, then there would be no clipping, but blown out areas could get a color cast.
-
Eric, I understand all that.
My question is: what do you do afterwards (in post) with your "accurately" exposed capture (i.e. the one that shows clipping only the LCD but not in the raw chanels)? How do you white balance it without introducing clipping?
The sensor/camera is the limitation in many aspects. It seems to make sense (from a pedantic, numbers-oriented perpective) to make sure that the sensor works at its optimal, then worry about processing later on.
No matter how good exposure/WB is out in the field, you might (I sure do) want to adjust them later on. Doing curves/levels or pretty much anything else could also alter (reduce) the output channel peaks (even image scaling could in principle have some effect). In that case, you could get something (slightly better SNR) "for free". If not, you could always reduce exposure and have similar results to what you have today.
-h
-
no, sorry... I never look at those DxO charts :-)
Tho_mas, you seem remarkably resistant to reasoning and scientific data, and perhaps you should pay attention to such authoritative sources as DXO and Eric Chan.
The DXO charts show how ISO is handled by some Phase One backs. The P40+ and the P60+ rate the sensor 1 stop below nominal, and apparently make up for this with the tone curve applied by the camera or the raw converter. As Eric stated, if you expose so that the histogram is at clipping, you have effectively underexposed by one f/stop. That gives you highlight headroom and protection from blown highlights in the raw file, but shadow performance will suffer.
The P45+ does not alter the amplifier gain, and handles ISO totally in the raw converter or camera. If you expose at a given f/stop and shutter speed at ISO 100 or ISO 800, the results in the raw file will be the same with this camera. Hasselblad also handles ISO in this fashion. ISO is merely appended as metadata with the Hasselblad backs. With some current dSLRs such as the Nikon D7000, one can either set ISO on the camera or use exposure in the raw converter and expose everything at base ISO. This is possible, since read noise does not vary with ISO on this camera.
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...
Your system does appear to give an appropriate pixel value for gray cards. However, you don't know what saturation is obtained by the sensor and how much exposure compensation has been applied by the camera or raw converter. The actual reflectivity of the card does not matter if you meter from the card: you will get the same result for a white card, a gray card, or a nearly black card. The exposure meter merely reads luminance. It can't differentiate a dark card illuminated in strong light from a gray card illuminated by weaker light.
You can either keep your head in the sand or learn :D
Regards,
Bill
-
I think I should start to shoot flowers or so... I think I have never seen clipping in colors, only in highlights. And when there is clipping in highlights I sure stop down.
If I would discover clipping in colors on the LCD-histogram I would most likely ignore it as I can deal with such a clipping in the Color Editor later on...
-
The actual reflectivity of the card does not matter if you meter from the card:
I didn't measure the card, I did measure the light (so with the white calotte).
When you use the BC greycard for metering you have to compensate 1/2 stop.
You can either keep your head in the sand or learn :D
;)
-
Bill, I think Phase rate their sensors *above* its measured rating ... otherwise clipping would be a cert.
As for ISO, they may not change anything but metadata, but they may include some additional calibration data for use at higher ISO.
Edmund
-
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
Let me elaborate a little here. The above mentioned applies to standard white points of D50 for ProPhoto RGB and D65 for Adobe RGB, and I think this corresponds to the first image in tho_mas' message above where profiles are shown. However, if the direction of primaries are kept the same, but the white points are changed, which means that the magnitude of unit stimulus changes, then the following situation emerges:
Fraction of unit stimulus blue ProPhoto RGB primary needed to match unit stimulus blue Adobe RGB primary:
(1) Adobe RGB white point=D65, PropPhoto RGB white point=D50, Fraction needed=1.2
(2) Adobe RGB white point=D65, PropPhoto RGB white point=D65, Fraction needed=0.91
(3) Adobe RGB white point=D50, PropPhoto RGB white point=D50, Fraction needed=0.88
(4) Adobe RGB white point=D50, PropPhoto RGB white point=D65, Fraction needed=0.67
So, except (1) other modes offer a scenario where no clipping needs to happen. However, (1) is the standard mode of specification of white points for both Adobe and ProPhoto RGB, and this does seem to clip. I think either (2) or (3) correspond to the second image shown by tho_mas in the above message.
Sincerely,
Joofa
-
Eric, I understand all that.
My question is: what do you do afterwards (in post) with your "accurately" exposed capture (i.e. the one that shows clipping only the LCD but not in the raw chanels)? How do you white balance it without introducing clipping?
Reviving an older thread (was traveling last week and offline ...)
Generally, the image looks too bright on input, so I just reduce the exposure. Since the raw channels were not clipped, no data is lost during this process.
The resulting image will have less noise than had I captured an image with a shorter exposure.
-
Reviving an older thread (was traveling last week and offline ...)
Generally, the image looks too bright on input, so I just reduce the exposure. Since the raw channels were not clipped, no data is lost during this process.
The resulting image will have less noise than had I captured an image with a shorter exposure.
Hi Eric,
So I assume Exposure correction is effectively applied before Whitebalance in ACR, correct?
Cheers,
Bart