Luminous Landscape Forum
Raw & Post Processing, Printing => Capture One Q&A => Topic started by: sanfairyanne on November 05, 2013, 01:31:01 am
-
I'm a 5d2 user but as time goes by I am increasingly interested in what the larger resolution of MF digital backs can offer. There's many a question I could ask but one which I'm intrigued by is the advertised 16 color bit depth of the IQ260. I read an article stating that the Nikon D800 has a color bit depth of 25.3bits as seen in this article:
http://snapsort.com/learn/sensor/dxo-mark/color-depth
I also added the attached image from that site. I feel I'm missing something in this statement from the website:
Color depth refers to how many variations of color the camera can capture, it is expressed in bits, with large values like 24 bits being excellent, and small values like 16bits being poor
Please forgive me if this is a stupid question. Thanks in advance.
-
Hi,
What the IQ260 has is a 16 bit signal path, it has nothing to do with color depth. It is actually nonsense used as a marketing term. No one ever has demonstrated any advantage of 16 bit signal path over say 14-bit signal path on a CCD sensor, except perhaps astronimical sensors deep frozen with liquid nitrogen.
DxO measurements are something entirely different. You can find a description on the DxO site, I will try to post a link later.
If you are interested in IQ260, try to test it or rent one for a couple of days.
Best regards
Erik
I'm a 5d2 user but as time goes by I am increasingly interested in what the larger resolution of MF digital backs can offer. There's many a question I could ask but one which I'm intrigued by is the advertised 16 color bit depth of the IQ260. I read an article stating that the Nikon D800 has a color bit depth of 25.3bits as seen in this article:
http://snapsort.com/learn/sensor/dxo-mark/color-depth
I also added the attached image from that site. I feel I'm missing something in this statement from the website:
Color depth refers to how many variations of color the camera can capture, it is expressed in bits, with large values like 24 bits being excellent, and small values like 16bits being poor
Please forgive me if this is a stupid question. Thanks in advance.
-
Erik,
I'd appreciate the link if you have time, I Googled DXO as I'd never heard of the site before. Any Phase One is out of my price range, I just wanted to learn a bit about what the top kit offers because given time it will filter down to the more affordable kit. For instance perhaps Canon will bring out a MF camera next year.
-
Hi,
This link: http://www.dxomark.com/About/In-depth-measurements/Measurements/Color-sensitivity
It may not be really helpful.
Best regards
Erik
Erik,
I'd appreciate the link if you have time, I Googled DXO as I'd never heard of the site before. Any Phase One is out of my price range, I just wanted to learn a bit about what the top kit offers because given time it will filter down to the more affordable kit. For instance perhaps Canon will bring out a MF camera next year.
-
I have an additional question - I hope I am not hijacking the thread with this:
Do modern Digital cameras capture ALL visible colors and just compress them into the camera colorspace (e.g. like Adobe RGB with perceptual rendering intent) or to they clip?
If they do clip - what is known about the gamut they can capture?
-
Thanks Erik I will look at it in depth after work.
Kind Regards
-
Hi,
Camera sensors don't really have a color space. They collect all colors and convert into the channels, R, G, B. At this stage the camera does not clip. Each signal will by the integral of the QE (Quentum Efficiency) of the sensor multiplied by the spectral intensity of the subject. If the camera converts to JPEG it would convert to a color space, normally sRGB or Adobe RGB. The raw data is not affected by this.
Best regards
Erik
I have an additional question - I hope I am not hijacking the thread with this:
Do modern Digital cameras capture ALL visible colors and just compress them into the camera colorspace (e.g. like Adobe RGB with perceptual rendering intent) or to they clip?
If they do clip - what is known about the gamut they can capture?
-
Hi,
I don't think the lens I gave you gives much useful information. Here is some short information.
When you photograph something you will get a signal. You will also get some noise. Most of the noise is coming from light itself. Light comes in quanta, called photons. A pixel captures photons and converts them to electrons. A fairly normal pixel may hold something like 50000 electrons. You need 16 bits to count 50000 electrons. But you also have noise. Major sources are shot noise which is natural variation of photons, this is proportional to the square root of the number of photons. So if you had say 64 photons falling on a 100 pixels, the signal from the pixels would vary between 56 and 72 (not exactly, somewhat simplified), that really means that the last few bits are pretty meaningless.
Another form of noise is readout noise, this can be very load on modern CMOS sensors (like +/- 3 electrons) but quite a bit higher (like +/- 15 electrons) on the CCDs typically used in MFD. The shot noise is normally quite smooth while readout noise is more ugly (pepper salt type).
So the readout channel on a MFDB may be 16 bit but of those 16 bits 4 bits will be noise. The information is actually around 12 bits.
If you transfer color, there are three channels. So, theoretically an MFDB would be able to separate between 2**(3*12), that is 68 billion (US) colours. the real number is much lower, a more typical value may be something like 25 bits, that still means 33 million different colors.
The MFDB sensors are larger, so they capture more photons. So the noise from sensor can be lower than on smaller sensors even if the noise/are is higher.
Best regards
Erik
Thanks Erik I will look at it in depth after work.
Kind Regards
-
Do modern Digital cameras capture ALL visible colors
but then you have metameric failures
-
So - when the light is finally rasterized into RGB values in the RAW file - do these represent the whole visible spectrum?
The whole horseshoe?
So - is the compression of these colors into a colorspace finally done in the RAW conversion?
I mean - in the end these RGB values coming from the Digitizer somehow must be interpreted and clipped / compressed.
How exactly is that done?
-
Hi,
I cannot answer that. The sensor themselves are sensitive to both UV and IR, so they see a wider spectrum than the human eye. That is the reason the IR filter is needed.
The visible spectrum is regarded to go between 390 nm and 700 nm, and this is covered by a normal CGA, see figure from Dalsa below.
The spectral sensivity of the eye is here:
(http://www.normankoren.com/Human_spectral_sensitivity_small.jpg)
So I would say, the sensor sees the same colors the human eye does, but does not see them the same way.
So you do some mathematical transforms to convert from native colour space to say Lab and than you convert from Lab to a smaller color space.
Best answer I can give, without reading all the math. It is simple math, but you still need to understand it...
Best regards
Erik
So - when the light is finally rasterized into RGB values in the RAW file - do these represent the whole visible spectrum?
The whole horseshoe?
So - is the compression of these colors into a colorspace finally done in the RAW conversion?
I mean - in the end these RGB values coming from the Digitizer somehow must be interpreted and clipped / compressed.
How exactly is that done?
-
So I would say, the sensor sees the same colors the human eye does, but does not see them the same way.
So you do some mathematical transforms to convert from native colour space to say Lab and than you convert from Lab to a smaller color space.
Well - the math is not that overly complicated to me.
So the processing chain is:
Light Spectrum: The Light => Camera sensor sensel buckets: A potential ==> A/D Converter: RAW RGB values ==> (What comes here?) ==> TIFF or Jpeg with an assigned colorspace
In the (What comes here?) part somewhere is the RAW file, a camera profile and some conversion, but what boggles me is, what is the rationale how these conversions are done?
Once we have a tagged file everything is finished for postprocessing, but if we see all these colors in the horseshoe which are not represented by the colorspaces we use for processing or printing but can be seen by the camera ... what happens to these colors and how?/me scratches head
-
In the (What comes here?) part somewhere is the RAW file, a camera profile and some conversion, but what boggles me is, what is the rationale how these conversions are done?
Each raw converter has to make some assumption of source "color space" here to render into whatever RGB processing color space is to be used (in ACR that is ProPhoto RGB primaries).
-
Each raw converter has to make some assumption of source "color space" here to render into whatever RGB processing color space is to be used (in ACR that is ProPhoto RGB primaries).
Wouldn't it make sense to instantly invent a colorspace designed for the file depending on its color distribution?
Imagine an image with lots of reds and orange - the tip of the colorspace triangle should then be more to the right of the horseshoe,
and an image with lots of blues and greens would get a colorspace with the tip more to the left and so on?
Or is ProPhoto already so big, that it encompasses all yet printable colors?
-
Hi,
Yes, I think so.
It is possible to construct a color space with primaries outside the horseshoe diagram but those primaries don't exist. But the number of stimuli could be increased.
Best regards
Erik
Or is ProPhoto already so big, that it encompasses all yet printable colors?
-
Hi,
Yes, I think so.
It is possible to construct a color space with primaries outside the horseshoe diagram but those primaries don't exist. But the number of stimuli could be increased.
Best regards
Erik
Yes - it would be at the cost of coding efficiency having these abstract nonexistent colors and a lot of junk colors lying between them outside the horseshoe.
So the (hopefully last) question would be:
When the RAW file leaves the camera: Has the mapping of the RGB values to a usable colorspace already been done, or is it done in the raw developer?
-
Raw developer I think. But the color is essentially set by the CGA. The RGB values are integrals over spectrum of QE * subject spectrum. The RGB signals are then converted into normalized values and multiplied by a color transformation matrix. That matrix is a part of the raw file, I think. Lot of info in the raw file.
Best regards
Erik
Yes - it would be at the cost of coding efficiency having these abstract nonexistent colors and a lot of junk colors lying between them outside the horseshoe.
So the (hopefully last) question would be:
When the RAW file leaves the camera: Has the mapping of the RGB values to a usable colorspace already been done, or is it done in the raw developer?
-
Raw developer I think. But the color is essentially set by the CGA. The RGB values are integrals over spectrum of QE * subject spectrum. The RGB signals are then converted into normalized values and multiplied by a color transformation matrix. That matrix is a part of the raw file, I think. Lot of info in the raw file.
Best regards
Erik
That makes sense and would possibly explain why having differing camera profiles for differing jobs is a good idea.
-
Raw developer I think. But the color is essentially set by the CGA. The RGB values are integrals over spectrum of QE * subject spectrum. The RGB signals are then converted into normalized values and multiplied by a color transformation matrix. That matrix is a part of the raw file, I think. Lot of info in the raw file.
Yes. The camera might be seen as a set of 3 "bandpass filters" that each pass part of the spectrum.
When developing raw file (done inside the camera for in-camera JPEGs, in your computer raw developer otherwise), the developer basically have to map (or its knowledge of) this camera-specific response to some standard representation suitable for further editing and display or print.
The camera does not have very detailed information about the "visible spectrum", nor does it record its 3 channels in exactly the same way as a human does (I believe that there might be sligth inter-human differences as well). Thus, two colors that appear different in person, might be recorded as the exact same set of rgb values. Or two objects that appear to have the same color in person, might be recorded as two different sets of rgb values. Thus it is an approximate process where a lot of engineering and subjective effort can be spent (see Foveon sensors)
Selection of camera filters may present some challenges: finding the right materials for generating a given response might be non-trivial, given that you want to deposit small dots in the CFA on an assembly line at low cost, and for a camera that lasts 10 years or more. Also, having the "perfect" color response might counter the desire for low-noise luminance recordings. By sacrificing one, you might improve the other (Canon vs Sony might be relevant examples).
-h
-
Yes. The camera might be seen as a set of 3 "bandpass filters" that each pass part of the spectrum.
When developing raw file (done inside the camera for in-camera JPEGs, in your computer raw developer otherwise), the developer basically have to map (or its knowledge of) this camera-specific response to some standard representation suitable for further editing and display or print.
The camera does not have very detailed information about the "visible spectrum", nor does it record its 3 channels in exactly the same way as a human does (I believe that there might be sligth inter-human differences as well). Thus, two colors that appear different in person, might be recorded as the exact same set of rgb values. Or two objects that appear to have the same color in person, might be recorded as two different sets of rgb values. Thus it is an approximate process where a lot of engineering and subjective effort can be spent (see Foveon sensors)
Selection of camera filters may present some challenges: finding the right materials for generating a given response might be non-trivial, given that you want to deposit small dots in the CFA on an assembly line at low cost, and for a camera that lasts 10 years or more. Also, having the "perfect" color response might counter the desire for low-noise luminance recordings. By sacrificing one, you might improve the other (Canon vs Sony might be relevant examples).
-h
Yes - humans definitely differ - thats why they created the standard observer in the old days.
Its funny - I didn't manage to find any data about the spectral response of the camera channels - though it should be easy to create one for every camera by photographing a spectrally defined colorset and doing some math. (I think principal component analysis for every color channel should do the job).
-
Its funny - I didn't manage to find any data about the spectral response of the camera channels - though it should be easy to create one for every camera by photographing a spectrally defined colorset and doing some math. (I think principal component analysis for every color channel should do the job).
This seems to be one recording of the spectral response of the Canon 40D. There are many other hits on google, but I think it is going to be hard to compare them as long as details about recording conditions (and even y-axis) tends to be scarce.
(http://www.maxmax.com/images/Cameras/Technical/Canon_40D_Response_CurveB.jpg)
If you have a variable frequency monochromatic light source, there should be no need for PCA.
I have the Colorchecker passport. Do you know if its reflectance vs wavelength is defined anywhere? Anyways, I think you'd need a fairly large set of patches (and/or just the right kind of orthogonality) in order to get a detailed spectral response estimate?
-h
-
When the RAW file leaves the camera: Has the mapping of the RGB values to a usable colorspace already been done, or is it done in the raw developer?
In the raw developer (if you feed it raw).
-
If you have a variable frequency monochromatic light source, there should be no need for PCA.
This kind of laser is quite an expensive toy, though they do exist.
But knowing the Spectrum of your light source and the reflective spectrum of your patches you could work it out.
You'd also need to take the filtering done by your lens into account.
-
You'd also need to take the filtering done by your lens into account.
I have tried to make camera profiles using my various lenses, and found that it was not worth the effort for my applications and eyes.
Granted, a lens profile might be something simpler than a full spectral characterization of your camera.
Basically, I have one "shaded daylight" and one "flash" profile for each camera, and those seems to do the trick for me and my humble needs.
-h
-
Hi,
I would think that a simple white balance on a gray card takes care of color shift in lens. Where profiles are really needed is where light has noncontinuos spectrum that cannot be approximated by a black body spectrum.
Best regards
Erik
I have tried to make camera profiles using my various lenses, and found that it was not worth the effort for my applications and eyes.
Granted, a lens profile might be something simpler than a full spectral characterization of your camera.
Basically, I have one "shaded daylight" and one "flash" profile for each camera, and those seems to do the trick for me and my humble needs.
-h
-
I would think that a simple white balance on a gray card takes care of color shift in lens. Where profiles are really needed is where light has noncontinuos spectrum that cannot be approximated by a black body spectrum.
The most significant difference (I dare not say "gain" as color is a minefield) was switching from Adobe-supplied profiles to my own. The second largest difference was profiling different illuminants. The difference when profiling different lenses was too minute for me to observe anything worthwhile, thus I happily stopped doing that.
So what you are saying is that spectral properties of lenses ought to be "smooth"? That was my gut-feeling as well.
-h
-
Each raw converter has to make some assumption of source "color space" here to render into whatever RGB processing color space is to be used (in ACR that is ProPhoto RGB primaries).
to cieXYZ/D50 then to ProPhoto primaries
-
I would think that a simple white balance on a gray card takes care of color shift in lens. Where profiles are really needed is where light has noncontinuos spectrum that cannot be approximated by a black body spectrum.
for ACR/LR users Eric Chan said (one of many quotes from many years ago) :
"...So to answer the question of WB and it's relevance to building & using DNG profiles: in principle, the applicability of a profile with a given WB has to do with how close the spectrum of the scene illuminant (used to photograph your real image) is to the spectrum of the illuminant used to build the profile. The closer they are, the better the results. Many flavors of natural daylight are spectrally similar (weighted differently), so this is why a daylight profile tends to work well in many flavors of daylight regardless of the actual CCT (e.g., 4700 K thru 7500 K). So even if you built your own profile under real daylight that ended up being around 6200 K, you should not hesitate to use such a profile under other similar daylight conditions, even if the CCT values vary a lot. But if you end up using a very different type of light (e.g., a fluorescent tube) then you should effect quite different, possibly unpleasant results, even if the CCT measures the same (e.g., a 6000 K office fluorescent tube)..."
so profile building (using 24 patch target and Adobe PE) for natural illumination is a snake oil or placebo... if you don't like how Adobe renders - then just replace/modify the LUTs (or get rid of them altogether with dcptool) with Adobe PE(or QP Card software) w/o actually shooting a target.
-
Thanks for making that clear.
Best regards
Erik
to cieXYZ/D50 then to ProPhoto primaries
-
Thanks for making that clear.
Best regards
Erik
not me, that was again from Eric Chan.