I don't see why not to check demosaicking first. And while I appreciate your intent, no, I can't assume anything about anybody. I always prefer to know the exact goal, and to start with discussing the setup.
Merely quoting from the 5-years-old question: " I'd like to use this image for sensor testing purposes, and the object is pure B&W." - without knowing the exact setup, the best we can do is suggest things to try. Trying out what quality you get from the "scale BW" approach I outlined only costs about 5 minutes to write and check. Trying out an alternative "convert to HSV and use the V channel" (or Lab or whatever) approach costs another 5-10 minutes. So after half an hour you know what's best :-)
No need to discuss the necessity of demosaicing at all, I just wanted to share a possible approach to the actual problem described. I fully agree that in most scenarios you will want to go RGB->Gray. However, the thread opener was talking about "sensor checking", so I feel comfortable to assume that he knows what he is doing ...
IMO a good thing is to start with stating the purpose. Without that, and without an estimate of the allowed error, nothing can be done. For sensor characterization having light spectrum changing across the scene is a matter of concern. Exact experimental setup and flat field are the first order of business. Before that, any discussion of the need in demosaicking is premature.With decent setup demosaicking can be skipped, but the lightness error introduced by demosaicking is typically less than 2 dE.
I agree - you can always get a hue introduced from lighting conditions, lens CA etc. No doubt!
Yet, the answer to the specific question really should have been "within your specific setup, you can actually skip the color interpolation / demosaicing step".
I say this because no matter how good your interpolation process (demosaic) is, it is an interpolation after all, it "guesses" (mathematically calculates) values that aren't really there. With the specific, narrow use case of shooting BW objects (ideally in controlled lighting conditions), you would most likely get a better BW result by skipping the color interpolation.
(I have done this and can say from experience that it does give you more fine detail than any RGB interpolation I have tried ;) )
Since the question was actually about black and white objects, the - otherwise correct! - caveat of images possibly having color patches in them does not apply.
The question should instead be answered with: Libraw currently does not have such a function and due to its generalistic approach never will have, yet building a solution is rather easy and straight forward: If you know that your objects are reliably black and white anyway, just shoot a gray image, read out the channel differences (i.e. the "scaling" introduced by the color filters) and re-multiply with the appropriate scales.
Thanks for your reply Alex and happy to read that this is not normal.
My CPU is Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz (4 CPUs), ~2.6GHz
I will try to compile your samples to see if I get the same result. At the moment, I just tried to use LibRaw by adding source code (internal, src and libraw folders) directly to my project, then builded it in release. The project is a C++/CLR dll that I call in C#, may be there is something that prevent optimizations. I will check and let you know :)
No, this is not normal (for unpack):
Simple test: - add return 0 to simple_dcraw.cpp test just before dcraw_process() called (so, only unpack)
$ time ./bin/simple_dcraw ~/CR2/IMG_0058.CR2 (this is Canon 6D MarkII image, 24Mpix)
time: real 0m1,310s
test computer: Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz , 8GB RAM.
void CLASS cam_xyz_coeff(float _rgb_cam[3][4], double cam_xyz[4][3])
{
double cam_rgb[4][3], inverse[4][3], num;
int i, j, k;
for (i = 0; i < colors; i++) /* Multiply out XYZ colorspace */
for (j = 0; j < 3; j++)
for (cam_rgb[i][j] = k = 0; k < 3; k++)
cam_rgb[i][j] += cam_xyz[i][k] * xyz_rgb[k][j];
for (i = 0; i < colors; i++)
{ /* Normalize cam_rgb so that */
for (num = j = 0; j < 3; j++) /* cam_rgb * (1,1,1) is (1,1,1,1) */
num += cam_rgb[i][j];
if (num > 0.00001)
{
for (j = 0; j < 3; j++)
cam_rgb[i][j] /= num;
pre_mul[i] = 1 / num;
}
I don't see why not to check demosaicking first. And while I appreciate your intent, no, I can't assume anything about anybody. I always prefer to know the exact goal, and to start with discussing the setup.
I do agree :)
Merely quoting from the 5-years-old question: " I'd like to use this image for sensor testing purposes, and the object is pure B&W." - without knowing the exact setup, the best we can do is suggest things to try. Trying out what quality you get from the "scale BW" approach I outlined only costs about 5 minutes to write and check. Trying out an alternative "convert to HSV and use the V channel" (or Lab or whatever) approach costs another 5-10 minutes. So after half an hour you know what's best :-)
No need to discuss the necessity of demosaicing at all, I just wanted to share a possible approach to the actual problem described. I fully agree that in most scenarios you will want to go RGB->Gray. However, the thread opener was talking about "sensor checking", so I feel comfortable to assume that he knows what he is doing ...
Mact
IMO a good thing is to start with stating the purpose. Without that, and without an estimate of the allowed error, nothing can be done. For sensor characterization having light spectrum changing across the scene is a matter of concern. Exact experimental setup and flat field are the first order of business. Before that, any discussion of the need in demosaicking is premature.With decent setup demosaicking can be skipped, but the lightness error introduced by demosaicking is typically less than 2 dE.
I agree - you can always get a hue introduced from lighting conditions, lens CA etc. No doubt!
Yet, the answer to the specific question really should have been "within your specific setup, you can actually skip the color interpolation / demosaicing step".
I say this because no matter how good your interpolation process (demosaic) is, it is an interpolation after all, it "guesses" (mathematically calculates) values that aren't really there. With the specific, narrow use case of shooting BW objects (ideally in controlled lighting conditions), you would most likely get a better BW result by skipping the color interpolation.
(I have done this and can say from experience that it does give you more fine detail than any RGB interpolation I have tried ;) )
Mact
Since the light "colour" uniformity is not that simple of an issue, having b/w objects doesn't guarantee the image taken is uniformly b/w.
Since the question was actually about black and white objects, the - otherwise correct! - caveat of images possibly having color patches in them does not apply.
The question should instead be answered with: Libraw currently does not have such a function and due to its generalistic approach never will have, yet building a solution is rather easy and straight forward: If you know that your objects are reliably black and white anyway, just shoot a gray image, read out the channel differences (i.e. the "scaling" introduced by the color filters) and re-multiply with the appropriate scales.
Mact
Drupal messed up the code, sorry for that - I thought I double-checked. If you are having problems understanding the pseudocode, let me know, please!
Mact
Thanks for your reply Alex and happy to read that this is not normal.
My CPU is Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz (4 CPUs), ~2.6GHz
I will try to compile your samples to see if I get the same result. At the moment, I just tried to use LibRaw by adding source code (internal, src and libraw folders) directly to my project, then builded it in release. The project is a C++/CLR dll that I call in C#, may be there is something that prevent optimizations. I will check and let you know :)
No, this is not normal (for unpack):
Simple test: - add return 0 to simple_dcraw.cpp test just before dcraw_process() called (so, only unpack)
$ time ./bin/simple_dcraw ~/CR2/IMG_0058.CR2 (this is Canon 6D MarkII image, 24Mpix)
time: real 0m1,310s
test computer: Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz , 8GB RAM.
What is your 'Intel i7' CPU, what specific model?
The sum of the two calls unpack()+dcraw_process().
unpack() is about 8-10s (11 sec for a 24mp DNG) and dcraw_process() is around 8-10s too.
except for a raw file from Sony a6500 where unpack() take only 0.4 sec. May be uncompressed pixel data?
Are the timing normal? Are there any tips to reduce the loading time?
Thank you.
What do you measure, is it unpack() or unpack()+dcraw_process()?
Fujifilm XF10 is not in LibRaw 0.19 supported camera list: https://www.libraw.org/supported-cameras
It is supported in current public snapshot (https://www.libraw.org/supported-cameras-snapshot-201903 ), please upgrade to it.
We plan to release new public snapshot this Fall.
It is takes time to test/check new decoders/new formats in every aspect.
thank you. not sure how I missed it.
guess because that sample is not included in solution file...
openbayer_sample.cpp is in samples folder
open_bayer() is still in libraw_cxx.cpp (line 1147 and below)
Pls make sure you use LibRaw 0.19, not older version.
I use 0.19.5-Win32
What LibRaw version you use?
I dont see sample open_bayer or LibRaw::open_bayer function. was it removed?
https://www.libraw.org/comment/5233#comment-5233
Hi there,
Would you please tell me if there is a plan to support the new-release Canon 90D and Canon CR3 RAW format on Windows 10?
Thanks,
Xinyi
Sorry, I misunderstood your first answer. I have everything working correctly now.
Once again, thanks for your help.
Amanda
yes
So this code:
void CLASS cam_xyz_coeff(float _rgb_cam[3][4], double cam_xyz[4][3])
{
double cam_rgb[4][3], inverse[4][3], num;
int i, j, k;
for (i = 0; i < colors; i++) /* Multiply out XYZ colorspace */
for (j = 0; j < 3; j++)
for (cam_rgb[i][j] = k = 0; k < 3; k++)
cam_rgb[i][j] += cam_xyz[i][k] * xyz_rgb[k][j];
for (i = 0; i < colors; i++)
{ /* Normalize cam_rgb so that */
for (num = j = 0; j < 3; j++) /* cam_rgb * (1,1,1) is (1,1,1,1) */
num += cam_rgb[i][j];
if (num > 0.00001)
{
for (j = 0; j < 3; j++)
cam_rgb[i][j] /= num;
pre_mul[i] = 1 / num;
}
These code sections are derived from dcraw, so this question was already answered here https://www.libraw.org/comment/5427#comment-5427
I'll repeat the direct link for your comfort: https://ninedegreesbelow.com/files/dcraw-c-code-annotated-code.html
You may specify any value in user_mul
Pages