As you can see in RAW data histograms, Green and Red are balanced perfectly (without any filters) in incadescent bulb light. You don't want to use any filters in this low-light condition, anyway.
Also, I don't think that 'gamut' is a good word in describing digital camera. Camera is sensitive to any visible light (to infrared - too), so camera gamut is equal (or broader) to human gamut.
We should describe camera behavior in terms of metamerism: some colors cannot be separated (i.e. same RGB(G) response for different colors)
This is a real dilemma - they could make two sensor types, one with narrow-bandpass colour filters, one with broad spectrum RGB. You would end up with a low ISO sensor offering maximum colour discrimination and Delta-E accuracy (but of course the potential for greater Delta-E errors if software conversion was not precisely matched to the transmission curves); and a high ISO sensor where the overlapping curves could reduce colour discrimination, relying on software to restore it.
I always felt that the RGB filters used on the KM7D/5D were narrower in band than the filters used on the same sensor by Nikon (D70 etc), allowing the lower ISO 100 setting and also giving the distinctive colour of the 7D/5D. I have also always thought that Canon's (early) RGB filters must be weak, helping reduce noise but giving a colour quality I never liked as much. The wide gamut captured by Canon models compared to the 7D/5D also points to this - narrow cut filters will, of course, limit the overall gamut but improve discrimination and accuracy within that gamut.
Did you mean green and blue are perfectly balanced in tungsten light, not green and red?
I have a large stock of ex-Minolta 85B (daylight to tungsten) conversion filters here, never been able to sell them. I gave away 200 40.5mm ones last week (40.5mm is not much use!). I may try the 85B in daylight, using the camera's tungsten preset, to see if it has some benefits.
Sure, pure CC30-40M (for different cameras) balances Green with Blue. Red channel remains half-stop underexposed.
Combination of something like СС30M plus CC15-20R should result in better channel balance in daylight. The cost is extra filter with extra glare (and one more slot in filter holder).
I'll try this combination when Moscow weather become more sunny :)
Filters on sensor is result of some compromise:
* For shooting in tungsten light (espessially, in 'home' bulbs, not high-temperature halogen ones) you need to lower sensitivity of red. If not, then skin tones will be overexposed. Look at the last chapter of my 'White balance problems' article ( http://www.libraw.org/articles/white-balance-in-digital-cameras.html ): green and red (without filters) are near-perfectly balanced under incadescent bulb.
* Also, there is 'High ISO race' now: last Canon/Nikon models have ISO 25600 sensitivity. To lower the signal/noise level, manufactures need to widen filter response curves. And, surely, color characteristics on Canon 5D-2 or Nikon D3 is much worse than on previous generation.
Hope, that 'high color quality' race will start sometime later.....
I realise that, but the blue channel will not be proportionately affected. A mix of CCR and CCM would be needed to equalise the balance, just wondered in view of the serious effect of red channel noise on blue skies whether CCR might not be a better option.
Some time ago (2-3 years) I did some tests using 80B filters for tungsten, and found that between 1 and 1.5 stops of highlight headroom was recovered by shooting with 80B (based on ACR conversions of the time, KM 7D). Iliah's findings show that maybe ACR was pre-boosting the red channel anyway. A different filter (not 80B) might have enabled equal channel gain in raw conversion. I worked in the 1990s with Leaf and other scanning backs, researching hot mirror filters and light balance filters to recover better colour information.
It surprises me that this kind of work (I'm just a photographer, my wife is a colour scientist) does not seem to have influenced the design of RGB filters for Bayer-type sensors. The sensor itself, unfiltered, is highly sensitive to red. But gradation in the red channel is determined by the blue component more than any other. The work of Dr Andrew Stevens in the early 1990s has also been ignored - he showed very effectively how only two coloured filters were required to produce full colour, not three. Andrew was a colour scientist with Kodak but I don't know where he is now. He was able to produce pseudo-isocolour from a panchromatic film and an orange filter, plus an exposure level - nothing more needed (two exposures)!
LibRaw is for software developers. Many users of digiKam, Krita and some other RAW processing software are happy with these programs (which, in turn, uses LibRaw via libkdcraw).
Anyway, LibRaw distribution includes several command-line tools. Take a look to half_mt utility which is similar to 'dcraw -h', but much faster in batch processing on multi-CPU/multicore machines
A magenta filter will crosstalk more than a red filter, and CC40R or 30R would be easily obtained. Have you tried to make up a filter pack which will equalize the highlight clip position for all three channels in daylight?
Second question - to what extent do you think the IR-cut filters used are attenuating the far end of the red response, and might this be in part responsible for the low red sensitivity?
Yes, It works now with LX3 files. For first time I am seeing my true raw as it should be seen.
I will update you once I have a decent UI that uses libraw and it's up on sourceforge.
I've tried LX3 samples from photographyblog and process them without any problems on LibRaw 0.6.1.
Anyway, there is some strange problems when processing Panasonic files (in my tests - files from FZ28) on multi-threaded LibRaw version, so I'll check it.
Hi There,
Thanks for the pointers. I am able to compile the code in VC++ 2008. Samples are also running fine.
I noticed in the list of cameras it says panasonic lx3 but the tiff conversion results in a file with only vertical line.
The same program works fine for Pentax K10D.
Is it because of dcraw only recently supported the LX3.
If so, will it be possible to reimport DCRaw latest version. It will be a while before new cameras will come out and this step may not be needed very soon again.
You can use digiKam DNG convertor as a reference. It uses both libraw and dng sdk.
Also, I'm not great VS2005/2008 guru. So, it is possible to provide Solution file, but I cannot be sure that it working. Makefile is much easier to test.
All CMake/Visual Studio/configure/automake and so on tools are scheduled to LibRaw 1.0. Too much things to do before
Thanks. I think not having good color is a secondary issue. The first problem is to inteface LibRaw with DNGSdk. If possible, could you provide some simple sample or write-up on how to interface LibRaw with DNG SDK.
Also, by any chance is it possible to provide a Visual Studio Solution for building LibRaw.
I looked around and even though DigiKam is very promising, but running KDE is not possible for everybody. Unfortunately, a lot of ppl are hooked on Windows.
Are you saying we are past that misunderstanding? My daily e-mails show direct opposite.
> he issue is that neither cameras not raw processing tools give a convenient method to see the (non white balanced) usage of the three raw sensor channels
The issue is not white balance only, but arbitrary statement of camera sensitivity as well. And channels are four, not three. Acting in presumption that G1=G2 is wrong.
> A solution needs to start outside the camera (and may be adopted, in time, in camera).
Real solution needs to start with the camera as we have less and less unprocessed data in what is commonly referred to as "raw output". Out of camera solutions are on many occasions just crunches as they can't take into account the modifications of data done in camera before the raw is recorded to a memory card.
So concretely, and irrespective of whether people have misunderstood ETTR in the past - the issue is that neither cameras not raw processing tools give a convenient method to see the (non white balanced) usage of the three raw sensor channels.
What can be done about this? A solution needs to start outside the camera (and may be adopted, in time, in camera).
> So how about posting a link to the images used for this article.
Those are thousands I discussed myself, and the point photographers were making was always "we are following ETTR", or, more specifically, often pointing to that article on Reichmann's site (and yes, his name is spelled with two "n" at the end). The images come from the everyday practice of pre-press, from different photosites, forums, etc. At some point in one pre-press bureau we were to arrange a practical shooting session to dispel the myth created by the phrase you quoted, "...bias your exposures so that the histogram is snugged up to the right, but not to the point that the highlights are blown." The idea that this note was written based on one image taken by one person is totally wrong.
The other problem with the ETTR as per LL approach is that it does not take into account how the camera actually meters, and how much negative compensation is already applied before displaying the histogram. For different cameras it is between 0.5 and 1 eV negative.
Lab is definitely not the best choice. On the other side, we need some widely recognized color space for image storage/exchange. From this point, Lab is better choice (RGB and CMYK are imperfect, other color spaces are uncommon). L axis of Lab is good enough.
AFAIK, there is no 'digitizable' perceptually uniform color spaces. Munsell scale is good, but there is no easy way to calculate (perceptually) intermediate color values.
Actually, I'm not asking to look at many underexposed images, only the image used in the writing of this article.
I see underexposed, overexposed and correctly exposed images all the time and rarely do people point me to Reichman's artcle. In my experience, on balance most people who discuss the concept of ETTR have never read Reichman's article and are restating second and third hand information.
So how aobut posting a link to the images used for this article. If the information and position stands up, then it can only help.
One thing that I would point out is that human vision is a tricky beast and it may be difficult to draw the right conclusions out of empirical results. There are many, many things going on at once... we can get a sense of that from the wide variety of visual illusions out there.
---
In the grand scheme of things, I think that the psychology of the end user also plays a huge role. e.g. in premium audio cable, there are 'snake oil' products out there where people buy them because their expectations about the price (expensive=good, etc.) trump their actual perception!!
When looking at a photograph, there are noticeable differences between the reproduced image and real life. e.g. not 3-D, dynamic range cannot reproduce specular highlights, artifacts, etc. etc. We can tell whether we just looked at a photograph or through a window. But for the most part, people forgive that and don't pay attention to the technical flaws/shortcomings.
I think if photographers want to make truly ""realistic"" photos, there is art involved in the photographer tweaking the controls manually to look right. Part of this is to capture the 'signal processing' done by our brain. And sometimes part of it is to aim for naturalism... where the image looks like what it should look like.
To clarify what I mean by naturalism... in audio, we expect gunshots to sound like what they sound like in the movies (they have a certain roar from the compression effects applied to them). Yet actual recordings of gunshots sound very different.
A good and interesting article in general. Interesting comparisons of different processors.
Noise reduction before debayering is clearly the way to go, especially if read noise can be estimated and removed from masked pixels at the same time.
Constructing a noise profile, per camera model and per ISO setting, would be ideal. (Commercial programs like Noise Ninja do this, for example).
I notice once again that ETTL is being described as ETTR, but that doesn't impact the main point of the article.
As you can see in RAW data histograms, Green and Red are balanced perfectly (without any filters) in incadescent bulb light. You don't want to use any filters in this low-light condition, anyway.
Also, I don't think that 'gamut' is a good word in describing digital camera. Camera is sensitive to any visible light (to infrared - too), so camera gamut is equal (or broader) to human gamut.
We should describe camera behavior in terms of metamerism: some colors cannot be separated (i.e. same RGB(G) response for different colors)
This is a real dilemma - they could make two sensor types, one with narrow-bandpass colour filters, one with broad spectrum RGB. You would end up with a low ISO sensor offering maximum colour discrimination and Delta-E accuracy (but of course the potential for greater Delta-E errors if software conversion was not precisely matched to the transmission curves); and a high ISO sensor where the overlapping curves could reduce colour discrimination, relying on software to restore it.
I always felt that the RGB filters used on the KM7D/5D were narrower in band than the filters used on the same sensor by Nikon (D70 etc), allowing the lower ISO 100 setting and also giving the distinctive colour of the 7D/5D. I have also always thought that Canon's (early) RGB filters must be weak, helping reduce noise but giving a colour quality I never liked as much. The wide gamut captured by Canon models compared to the 7D/5D also points to this - narrow cut filters will, of course, limit the overall gamut but improve discrimination and accuracy within that gamut.
Did you mean green and blue are perfectly balanced in tungsten light, not green and red?
I have a large stock of ex-Minolta 85B (daylight to tungsten) conversion filters here, never been able to sell them. I gave away 200 40.5mm ones last week (40.5mm is not much use!). I may try the 85B in daylight, using the camera's tungsten preset, to see if it has some benefits.
David
Sure, pure CC30-40M (for different cameras) balances Green with Blue. Red channel remains half-stop underexposed.
Combination of something like СС30M plus CC15-20R should result in better channel balance in daylight. The cost is extra filter with extra glare (and one more slot in filter holder).
I'll try this combination when Moscow weather become more sunny :)
Filters on sensor is result of some compromise:
* For shooting in tungsten light (espessially, in 'home' bulbs, not high-temperature halogen ones) you need to lower sensitivity of red. If not, then skin tones will be overexposed. Look at the last chapter of my 'White balance problems' article ( http://www.libraw.org/articles/white-balance-in-digital-cameras.html ): green and red (without filters) are near-perfectly balanced under incadescent bulb.
* Also, there is 'High ISO race' now: last Canon/Nikon models have ISO 25600 sensitivity. To lower the signal/noise level, manufactures need to widen filter response curves. And, surely, color characteristics on Canon 5D-2 or Nikon D3 is much worse than on previous generation.
Hope, that 'high color quality' race will start sometime later.....
I realise that, but the blue channel will not be proportionately affected. A mix of CCR and CCM would be needed to equalise the balance, just wondered in view of the serious effect of red channel noise on blue skies whether CCR might not be a better option.
Some time ago (2-3 years) I did some tests using 80B filters for tungsten, and found that between 1 and 1.5 stops of highlight headroom was recovered by shooting with 80B (based on ACR conversions of the time, KM 7D). Iliah's findings show that maybe ACR was pre-boosting the red channel anyway. A different filter (not 80B) might have enabled equal channel gain in raw conversion. I worked in the 1990s with Leaf and other scanning backs, researching hot mirror filters and light balance filters to recover better colour information.
It surprises me that this kind of work (I'm just a photographer, my wife is a colour scientist) does not seem to have influenced the design of RGB filters for Bayer-type sensors. The sensor itself, unfiltered, is highly sensitive to red. But gradation in the red channel is determined by the blue component more than any other. The work of Dr Andrew Stevens in the early 1990s has also been ignored - he showed very effectively how only two coloured filters were required to produce full colour, not three. Andrew was a colour scientist with Kodak but I don't know where he is now. He was able to produce pseudo-isocolour from a panchromatic film and an orange filter, plus an exposure level - nothing more needed (two exposures)!
David
LibRaw is for software developers. Many users of digiKam, Krita and some other RAW processing software are happy with these programs (which, in turn, uses LibRaw via libkdcraw).
Anyway, LibRaw distribution includes several command-line tools. Take a look to half_mt utility which is similar to 'dcraw -h', but much faster in batch processing on multi-CPU/multicore machines
Magenta is 'Minus Green filter', but Red is 'Minus Green and Minus Blue'.
In daylight situation CC30M-CC40M produces near perfect sensitivity balance on my cameras.
A magenta filter will crosstalk more than a red filter, and CC40R or 30R would be easily obtained. Have you tried to make up a filter pack which will equalize the highlight clip position for all three channels in daylight?
Second question - to what extent do you think the IR-cut filters used are attenuating the far end of the red response, and might this be in part responsible for the low red sensitivity?
Yes, It works now with LX3 files. For first time I am seeing my true raw as it should be seen.
I will update you once I have a decent UI that uses libraw and it's up on sourceforge.
Thanks,
We've found and fixed bug in Panasonic .RW2 files processing. This bug affects only thread-safe version of library.
Could you please test LibRaw 0.6.2 on your files?
I've tried LX3 samples from photographyblog and process them without any problems on LibRaw 0.6.1.
Anyway, there is some strange problems when processing Panasonic files (in my tests - files from FZ28) on multi-threaded LibRaw version, so I'll check it.
You also may check new LibRaw release (sorry, source code only): http://www.libraw.org/blog/libraw-062-beta1.html
To test with any samples, you can use the raw files from here.
http://www.photographyblog.com/reviews_panasonic_lumix_dmc_lx3_3.php
If you scroll down there are bunch of RW2 files.
Thanks,
Hi There,
Thanks for the pointers. I am able to compile the code in VC++ 2008. Samples are also running fine.
I noticed in the list of cameras it says panasonic lx3 but the tiff conversion results in a file with only vertical line.
The same program works fine for Pentax K10D.
Is it because of dcraw only recently supported the LX3.
If so, will it be possible to reimport DCRaw latest version. It will be a while before new cameras will come out and this step may not be needed very soon again.
Thanks,
Unfortunately, I've no Mac with Mac OS X Tiger. Will try to find VMWare image to test.
When is the article describing how to set UniWB into the camera going to be published? This is of great interest to me.
You can use digiKam DNG convertor as a reference. It uses both libraw and dng sdk.
Also, I'm not great VS2005/2008 guru. So, it is possible to provide Solution file, but I cannot be sure that it working. Makefile is much easier to test.
All CMake/Visual Studio/configure/automake and so on tools are scheduled to LibRaw 1.0. Too much things to do before
Thanks. I think not having good color is a secondary issue. The first problem is to inteface LibRaw with DNGSdk. If possible, could you provide some simple sample or write-up on how to interface LibRaw with DNG SDK.
Also, by any chance is it possible to provide a Visual Studio Solution for building LibRaw.
I looked around and even though DigiKam is very promising, but running KDE is not possible for everybody. Unfortunately, a lot of ppl are hooked on Windows.
Thanks for any help you can provide.
See below a thread about a stand alone version of digiKam DNG Converter tool running under Windows.
http://www.digikam.org/drupal/node/378#comment-17895
Gilles Caulier
> people have misunderstood ETTR in the past
Are you saying we are past that misunderstanding? My daily e-mails show direct opposite.
> he issue is that neither cameras not raw processing tools give a convenient method to see the (non white balanced) usage of the three raw sensor channels
The issue is not white balance only, but arbitrary statement of camera sensitivity as well. And channels are four, not three. Acting in presumption that G1=G2 is wrong.
> A solution needs to start outside the camera (and may be adopted, in time, in camera).
Real solution needs to start with the camera as we have less and less unprocessed data in what is commonly referred to as "raw output". Out of camera solutions are on many occasions just crunches as they can't take into account the modifications of data done in camera before the raw is recorded to a memory card.
So concretely, and irrespective of whether people have misunderstood ETTR in the past - the issue is that neither cameras not raw processing tools give a convenient method to see the (non white balanced) usage of the three raw sensor channels.
What can be done about this? A solution needs to start outside the camera (and may be adopted, in time, in camera).
> So how about posting a link to the images used for this article.
Those are thousands I discussed myself, and the point photographers were making was always "we are following ETTR", or, more specifically, often pointing to that article on Reichmann's site (and yes, his name is spelled with two "n" at the end). The images come from the everyday practice of pre-press, from different photosites, forums, etc. At some point in one pre-press bureau we were to arrange a practical shooting session to dispel the myth created by the phrase you quoted, "...bias your exposures so that the histogram is snugged up to the right, but not to the point that the highlights are blown." The idea that this note was written based on one image taken by one person is totally wrong.
The other problem with the ETTR as per LL approach is that it does not take into account how the camera actually meters, and how much negative compensation is already applied before displaying the histogram. For different cameras it is between 0.5 and 1 eV negative.
Dear Glenn, I'm afraid Lab was not designed to be perceptually uniform, but to be deltaE uniform.
Glenn,
Lab is definitely not the best choice. On the other side, we need some widely recognized color space for image storage/exchange. From this point, Lab is better choice (RGB and CMYK are imperfect, other color spaces are uncommon). L axis of Lab is good enough.
AFAIK, there is no 'digitizable' perceptually uniform color spaces. Munsell scale is good, but there is no easy way to calculate (perceptually) intermediate color values.
Actually, I'm not asking to look at many underexposed images, only the image used in the writing of this article.
I see underexposed, overexposed and correctly exposed images all the time and rarely do people point me to Reichman's artcle. In my experience, on balance most people who discuss the concept of ETTR have never read Reichman's article and are restating second and third hand information.
So how aobut posting a link to the images used for this article. If the information and position stands up, then it can only help.
Regards,
Peter
Interesting reading.
One thing that I would point out is that human vision is a tricky beast and it may be difficult to draw the right conclusions out of empirical results. There are many, many things going on at once... we can get a sense of that from the wide variety of visual illusions out there.
I've found myself that a lot of the theories out there are wrong... e.g.
http://colorcorrection.info/color-science/hermann-grid-illusion-nobody-k...
As far as building a RAW converter goes, some of the color models like LAB might not necessarily be what photographers want.
http://colorcorrection.info/color-science/is-lab-useful-for-color-correc...
---
In the grand scheme of things, I think that the psychology of the end user also plays a huge role. e.g. in premium audio cable, there are 'snake oil' products out there where people buy them because their expectations about the price (expensive=good, etc.) trump their actual perception!!
When looking at a photograph, there are noticeable differences between the reproduced image and real life. e.g. not 3-D, dynamic range cannot reproduce specular highlights, artifacts, etc. etc. We can tell whether we just looked at a photograph or through a window. But for the most part, people forgive that and don't pay attention to the technical flaws/shortcomings.
I think if photographers want to make truly ""realistic"" photos, there is art involved in the photographer tweaking the controls manually to look right. Part of this is to capture the 'signal processing' done by our brain. And sometimes part of it is to aim for naturalism... where the image looks like what it should look like.
To clarify what I mean by naturalism... in audio, we expect gunshots to sound like what they sound like in the movies (they have a certain roar from the compression effects applied to them). Yet actual recordings of gunshots sound very different.
Pages