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.
The options are: use Auto White balance in NX (White Balance: Set Colour Temperature: New WB: Calculate automatically) as a first step and adjust from there; use click/drag grey white balancing method (White Balance: Set Grey Point); select the type of light in the scene and adjust colour temperature (for example - White Balance: Set Colour Temperature: New WB: Daylight: Cloudy); take a separate shot with custom white balance and copy in NX white balance from it to the shots taken with UniWB.
Hi, Having set my D3 up with UniWB. How do I then correctly process in NX2 the images capatured with UniWB so I get an image with visually appropriate White balance? Txs Mike
> Is there much image degradation if I were to use a gel (rather than glass filter) over my lens? I happened to settled upon a Roscoe Pink (4830) for my D80. After evaluating a sample set of Roscoe swatches alongside UniWB. I found that the Pink resulted in the least amount of Red and Blue WB adjustment for the D80 with flash as the light source.
When using flash as the only light source I always place the filter in front of the flash, not in front of the lens. This way no image degradation occurs.
If I need to use colour gel filters outdoors then I prefer Lee filters. When used with a deep compendium they cause image degradation on par with a regular protection filter.
LibRaw is based on dcraw sources. In turn, dcraw uses RGB-XYZ tables from Adobe (DNG converter? Or camera raw?). So, do not expect to get good color on digikam/LibRaw until dcraw and-or Adobe converter arrives
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.
The options are: use Auto White balance in NX (White Balance: Set Colour Temperature: New WB: Calculate automatically) as a first step and adjust from there; use click/drag grey white balancing method (White Balance: Set Grey Point); select the type of light in the scene and adjust colour temperature (for example - White Balance: Set Colour Temperature: New WB: Daylight: Cloudy); take a separate shot with custom white balance and copy in NX white balance from it to the shots taken with UniWB.
Hi, Having set my D3 up with UniWB. How do I then correctly process in NX2 the images capatured with UniWB so I get an image with visually appropriate White balance? Txs Mike
half_mt is just a simple(!) sample.
Anyway, to be fixed in next release
If one of the threads in half_mt encounters an error processing a file it quits but never restarts. Remaining threads, however, continue to function.
> Is there much image degradation if I were to use a gel (rather than glass filter) over my lens? I happened to settled upon a Roscoe Pink (4830) for my D80. After evaluating a sample set of Roscoe swatches alongside UniWB. I found that the Pink resulted in the least amount of Red and Blue WB adjustment for the D80 with flash as the light source.
When using flash as the only light source I always place the filter in front of the flash, not in front of the lens. This way no image degradation occurs.
If I need to use colour gel filters outdoors then I prefer Lee filters. When used with a deep compendium they cause image degradation on par with a regular protection filter.
LibRaw is based on dcraw sources. In turn, dcraw uses RGB-XYZ tables from Adobe (DNG converter? Or camera raw?). So, do not expect to get good color on digikam/LibRaw until dcraw and-or Adobe converter arrives
Pages