For most of the cameras I've tried, I either get values like 0.6 or 600 (which I divide by 1000).
However, I have a DNG where I get: INFO: cam_mul 0.001000 1127039.874999 0.004999 0
Raw Therapee seems to load the file just fine though. And so does IrfanView.
Any ideas what's wrong, or what I should do?
Just to use daylight or auto
Use daylight or auto multipliers if camera WB looks wrong (as in this case). As a general rule, red/blue multipliers should be in 0.05..20.0 (or may be less) range after normalization (green one set to 1.0)
BTW, could you please share this DNG (e.g. send link to info@libraw.org if you do not want to share it public) for detailed examination?
-- Alex Tutubalin @LibRaw LLC
Sure, I will send it. But
Sure, I will send it. But actually, I know what the problem is, I just remembered. The camera is a Canon SD980 running CHDK, and I helped porting that CHDK version (at the time this camera was using a newer API set, so CHDK didn't work on it, it needed quite a bit of reverse engineering). And the port might have had some stuff missing.
The interesting thing is that all programs I tried worked fine with it, so I guess they had some detection for invalid Wb settings, and calculated their own.
So probably the DNG is not too useful for you, as only my camera is affected by it (all my other RAWs from other CHDK cameras are OK). But if you still want it, I can send it to you.
Yes, we collect any 'strange'
Yes, we collect any 'strange' DNG/RAW files to make sure LibRaw works fine even in corner cases :)
-- Alex Tutubalin @LibRaw LLC
Ok, I sent it :) I hope you
Ok, I sent it :) I hope you got it, since it's a large-ish file :)
Let me know if you find anything wrong with it :)
Got it, thanks
Got it, thanks
Yes, AsShot white balance is broken in DNG tags:
| 25) AsShotNeutral = inf 8.872800664e-007 200 (1000/0 1000/1127039858 1000/5)
LibRaw by default uses daylight WB (calculated from ColorMatrix* DNG tags), so it works ok. If camera WB is specified explicitly (params.use_camera_wb = 1), than image becomes wrong (as expected).
Looks like we need additional check for camera WB range and fallback to Auto if camera wb looks corrupted.
Thank you for the sample.
-- Alex Tutubalin @LibRaw LLC
I am glad it helped :)
I am glad it helped :)
While I am at it, to not open a new thread, would it be possible to expose to C the debayering functions? Maybe I missed something, but I don't think they are exported in C.
Could not understand what
Could not understand what part of debayer code you want to export (to C-API?).
LibRaw's debayer code uses lot of internals (image[] array, CFA pattern, etc) and not intended to be used alone.
-- Alex Tutubalin @LibRaw LLC
Well, it is my understanding
Well, it is my understanding that LibRaw can export fully debayered TIFFs, and that there are various debayering algorithms built in (and some that can be added separately).
I am not sure how the internals work, but it would be very useful if either image[] array was fully populated or there was some other array with the proper RGB values.
I tried implementing a few debayering algorithms in my project, but then eventually gave up (I wasn't getting the results I wanted) and just used the quarter of the resolution debayering method, since that should be enough for my project (a program used for making timelapse videos, where any photo 12MP or bigger can yield enough information for a 1920x1080 movie frame).
LibRaw's goal is to provide
LibRaw's goal is to provide access to raw image data either in source form (LibRaw::open_file/unpack) or in processed (LibRaw::dcraw_process())
There is no intention to expose internal sub-functions, this is orthogonal to library purpose.
-- Alex Tutubalin @LibRaw LLC
That makes sense, thanks for
That makes sense, thanks for answering :)
Bad cam_mul values issue
Bad cam_mul values issue finally fixed in 0.19-stable branch (preparing 0.19-beta2): https://github.com/LibRaw/LibRaw/commit/d4420a4dac0d1f232629f7f163fb59d7...
-- Alex Tutubalin @LibRaw LLC