If I set "use_auto_wb" to 1, how can I retrieve the final set of white balance coefficients that is calculated by "libraw"? also, if I use "greybox" method to calculate the white balance coefficients, is there a variable through which I can get the final values?
WB selection logic is in scale_colors() (this call will print multipliers if compiled with DCRAW_VERBOSE defined.
You may copy-paste this logic to your own call, or, if you do not use all possible ways to set WB coeffs, you may simplify it.
RawSpeed master has transferred from Klaus Post to darktable team.
There are a *lot* of changes in this version, in particular it requires modern C++ and current version does not compile with MS Visual Studio (I have not tried, but developers says it).
This branch not tested by LibRaw team and there is no any timeframe for that ('later this year or next year').
So, you may try to use this version with LibRaw on you own risk. Most likely, you'll need to change something (in RawSpeed or in LibRaw or in both). Patches for LibRaw are welcome.
Hi,
I tested the new ACES Primaries implementation (in dcraw).
Looks like you are using the AP1 primaries rather than the AP0.
ACES is defined to use AP0 primaries for image exchange.
It should do so:
LibRaw_memmgr raises exception (LIBRAW_EXCEPTION_ALLOC) if malloc/calloc/realloc fails.
This exception is caught on upper level and error code returned.
This will broke if you compile LibRaw without C++ exceptions support (or if C++ exceptions are broken in your compiler/runtime)
After studying this problem a little more in detail, I noticed that the dcraw result failed if there was some memory fragmentation on the device. This seems to occur earlier with libraw then with dcraw (maybe because some additional allocations are made?). May it would be still possible to report clearer error when dcraw failed because of memory restrictions?
So the -c is used for something else in Libraw. I am not successful in adding (VB Net 2015) a reference to LibRaw Dll
It just refuses to add it. I was not able to register it in Windows. So I am way off base Do I need anything more than the DLL? I wonder if there is anyone around who has actually done this. Just a bit of help would be good
Do I need to add anything more than the Dll My program finds and runs all the version emu, simple, etc but it wil lnt
pipe to memory
Help please
Its my lack of C (I am 80 and once used assembly language but not much C)
I can't tell right now, the device in question was running an armv7 binaries. I couldn't reproduce the issue on an other device with arm 64 bit binary, but this device also had more memory. I'll try what happens if I run it on android with a x86 binary and report back.
[Edit]: On a x64 device I couldn't reproduce the same behaviour with the same image size, so it's possible that on arm are some other limits may exists. However, since I ported dcraw on arm previously and it works fine on the same device, I guess it has to do with some changes in libraw. May we can debug this, but I have no experience in debugging native code on android, the only way I'm aware of is doing logs in some lines.
Hmm, do you have any idea where I could start finding out what's causing this problem? dcraw is returning 0 but width+height are zero. May it's possible to fix it in future versions, that woud be great.
But if an error occurred, dcraw shouldn't return 0, or does it still continue and does not throw an exception which leads to a different result code? Because the dcraw call returns 0 which seems strange.
if recycle() was called somewhere due to error, it will zero imgdata.sizes structure.
Also, dcraw_make_mem_image do not call CHECK_ORDER_* macros to check is processing stage correct or not (to be fixed sometimes).
Hi,
If I set "use_auto_wb" to 1, how can I retrieve the final set of white balance coefficients that is calculated by "libraw"? also, if I use "greybox" method to calculate the white balance coefficients, is there a variable through which I can get the final values?
Thanks a lot,
Mio
WB selection logic is in scale_colors() (this call will print multipliers if compiled with DCRAW_VERBOSE defined.
You may copy-paste this logic to your own call, or, if you do not use all possible ways to set WB coeffs, you may simplify it.
RawSpeed master has transferred from Klaus Post to darktable team.
There are a *lot* of changes in this version, in particular it requires modern C++ and current version does not compile with MS Visual Studio (I have not tried, but developers says it).
This branch not tested by LibRaw team and there is no any timeframe for that ('later this year or next year').
So, you may try to use this version with LibRaw on you own risk. Most likely, you'll need to change something (in RawSpeed or in LibRaw or in both). Patches for LibRaw are welcome.
Is this still the case? Should we still use the Rawspeed master branch instead of the develop branch?
The master branch hasn't been updated since 2014. The development branch was last updated in 11/2016.
Also...are you using
https://github.com/klauspost/rawspeed or
https://github.com/darktable-org/rawspeed ?
standard sequence for file processing:
open_file();
unpack();
dcraw_process();
dcraw_make_mem_image();
Hello Alex,
thanks a lot that is perfectly fine! I just wasn't aware of that method. Thanks a lot!
Regards
Torsten
This list updates so frequently, so we opted not publish this list, because it will require too frequent updates.
Actual camera list is available via LibRaw::cameraCount() and LibRaw::cameraList() calls ( https://www.libraw.org/docs/API-CXX.html#cameraList )
Also, samples/simple_dcraw will print total count if started w/o params, and will print the list if started with -L key
Thanks a lot, issue confirmed
well I am not familiar with the code base. Just wanted to leave this here. Basically, the aces target space has the wrong primaries.
You should use:
// RGB = ACES: 0.7347,0.2653 0.0,1.0 0.0001,-0.0770
// White = D60: 0.32168,0.33767
but it seems that you are using
// RGB = ACESwork: 0.713,0.293,0.165,0.83,0.128,0.044
// White = D60: 0.32168,0.33767
hope this helps
Could you please suggest a patch to fix it (for dcraw, if you're not familiar with LibRaw source)
Hi,
I tested the new ACES Primaries implementation (in dcraw).
Looks like you are using the AP1 primaries rather than the AP0.
ACES is defined to use AP0 primaries for image exchange.
Hope that makes sense.
best
Daniele
It should do so:
LibRaw_memmgr raises exception (LIBRAW_EXCEPTION_ALLOC) if malloc/calloc/realloc fails.
This exception is caught on upper level and error code returned.
This will broke if you compile LibRaw without C++ exceptions support (or if C++ exceptions are broken in your compiler/runtime)
After studying this problem a little more in detail, I noticed that the dcraw result failed if there was some memory fragmentation on the device. This seems to occur earlier with libraw then with dcraw (maybe because some additional allocations are made?). May it would be still possible to report clearer error when dcraw failed because of memory restrictions?
Regard Torsten
So the -c is used for something else in Libraw. I am not successful in adding (VB Net 2015) a reference to LibRaw Dll
It just refuses to add it. I was not able to register it in Windows. So I am way off base Do I need anything more than the DLL? I wonder if there is anyone around who has actually done this. Just a bit of help would be good
Do I need to add anything more than the Dll My program finds and runs all the version emu, simple, etc but it wil lnt
pipe to memory
Help please
Its my lack of C (I am 80 and once used assembly language but not much C)
user_sat is documented way to change maximum with guarantee you do not break anything
(for example, if you'll change maximum value after open_file(), but before unpack() it can result into data error exceptions/warnings).
Thanks a lot. This is clear now. I can change the maximum. Just I can't imagine why and where it can be needed.
user_sat is used to set sensor saturation (max possible) value. It is not related to HSL space
LibRaw (library) provides dcraw_make_mem_image() call, it should be accessible via VB.
.dll is provided with Win32 builds
I can't tell right now, the device in question was running an armv7 binaries. I couldn't reproduce the issue on an other device with arm 64 bit binary, but this device also had more memory. I'll try what happens if I run it on android with a x86 binary and report back.
[Edit]: On a x64 device I couldn't reproduce the same behaviour with the same image size, so it's possible that on arm are some other limits may exists. However, since I ported dcraw on arm previously and it works fine on the same device, I guess it has to do with some changes in libraw. May we can debug this, but I have no experience in debugging native code on android, the only way I'm aware of is doing logs in some lines.
Regards Torsten
Is the problem persists under x86, or it is Android-specific?
If I'll able to reproduce it under my common build environment (Windows, OS X, or FreeBSD) it will ease problem fix. Sorry, no Android tools on hands.
Hmm, do you have any idea where I could start finding out what's causing this problem? dcraw is returning 0 but width+height are zero. May it's possible to fix it in future versions, that woud be great.
Regards
Torste
Yes, it should not return 0
But if an error occurred, dcraw shouldn't return 0, or does it still continue and does not throw an exception which leads to a different result code? Because the dcraw call returns 0 which seems strange.
Followup:
if recycle() was called somewhere due to error, it will zero imgdata.sizes structure.
Also, dcraw_make_mem_image do not call CHECK_ORDER_* macros to check is processing stage correct or not (to be fixed sometimes).
Yes, sizes.width/height are set on open_file() stage.
Also, files with height or width less than 22 should be rejected on this stage (identify()'s function tail)
Pages