After a lot of trials and errors by following your instructions above, I've finally managed to compile RawSpeed into a library and recompiled libraw to use it.
I can see a speedup of 2x with Canon CR2 files, but not so much for NEF, and I think there is no support for X-Trans.
1) You need to compile rawspeed as a library (this is not a problem, just make library from object files)
2) You may need to patch RawSpeed using provided patches (in LibRaw's rawspeed folder)
to provide Dll export (for Windows/DLL) and rawspeed_get_number_of_processor_cores() call
3) You may used qmake .pro file (provided with LibRaw's patches) to build RawSpeed.a/.dll
Thanks for doing this! Good job, both Alexey and LibRaw team!
This is great news, but Apple still hasn't added support for compressed .RAF files. How do I incorporate this support into Apple's raw.plist? Or is that not possible, and I have to rely on third party apps to support compressed .RAF files?
Hi Alex,
We're preforming some noise suppression prior to passing the raw buffer into the demosaicing chain, so yes, we have raw pixel values in the neighborhood of 0.
Falka, As the guy who sat in the office next to yours, i figured i'd come on and say thank you for your help this summer!
On a more technical note, taking a closer look at the imagery generated utilizing DHT, we found some artifacts in near-nodata (CFA ~= 0) regions of an image (or if you just hack off the bottom end prior to passing it into DHT). I believe these are just integer wrap-arounds.
lexa, we'll be sure to look into compiling with OpenMP!
I am very sorry if you felt weary of our conversations. As I said, I have difficulty in clarifying dcraw’s raw processing, and its key seems to be scaling at last. Given scaling is the setting of white level as you said, how are the values between black and white levels then converted to the 16 working bit ? Is there any rule of the conversion as adobe describes in the specification of DNG ? https://wwwimages.adobe.com/content/dam/Adobe/en/products/photoshop/pdfs...
Hi lexa
>dcraw's scale_colors() does
> - black subtraction
> - white balance
> - and data scaling (looks like it is 'setting of white level' in your terms?)
>in one action.
In your wording, scaling of dcraw looks like "mapping DN values so as to fit to the 16 working bit". Is it ?
If you think it strange, lets join them together in the name of black level application. For me, setting was fixing and a state before implementation. In this regard, I had forgotten to note another element of white level implementation.
Could you please provide sample DNG to look into it?
if rawspeed has decoded the file, this bit is turned on:
imgdata.process_warnings |= LIBRAW_WARN_RAWSPEED_PROCESSED;
(this is not warning, just info)
After a lot of trials and errors by following your instructions above, I've finally managed to compile RawSpeed into a library and recompiled libraw to use it.
I can see a speedup of 2x with Canon CR2 files, but not so much for NEF, and I think there is no support for X-Trans.
Although README.RawSpeed.txt does not look fresh, RawSpeed master branch was not updated from 2014 too.
Can you update the file README.RawSpeed.txt? It is out of date and I've been trying all weekend using the instructions there without success.
Compiling RawSpeed to a library is a problem, because there is no makefile or configure file. I'm trying to do this under macOS.
Slightly more details are here: https://github.com/LibRaw/LibRaw/blob/master/README.RawSpeed.txt
1) You need to compile rawspeed as a library (this is not a problem, just make library from object files)
2) You may need to patch RawSpeed using provided patches (in LibRaw's rawspeed folder)
to provide Dll export (for Windows/DLL) and rawspeed_get_number_of_processor_cores() call
3) You may used qmake .pro file (provided with LibRaw's patches) to build RawSpeed.a/.dll
Thank you.
libraw.h does not contains string 'CreateLibraw', may be it something C# specific?
There are a lot of libraw_set_... calls in C api, that calls will set params in imgdata.params array
I do not think it is possible. So, only 3rd party apps may help (like our FastRawViewer, for example)
Thanks for doing this! Good job, both Alexey and LibRaw team!
This is great news, but Apple still hasn't added support for compressed .RAF files. How do I incorporate this support into Apple's raw.plist? Or is that not possible, and I have to rely on third party apps to support compressed .RAF files?
Thanks in advance.
David
Hi Alex,
We're preforming some noise suppression prior to passing the raw buffer into the demosaicing chain, so yes, we have raw pixel values in the neighborhood of 0.
sorry, could not understand what is 'CFA ~=' (CFA is color filter array, it is constant over the image). Is it really 'data values ~= 0' ?
Falka, As the guy who sat in the office next to yours, i figured i'd come on and say thank you for your help this summer!
On a more technical note, taking a closer look at the imagery generated utilizing DHT, we found some artifacts in near-nodata (CFA ~= 0) regions of an image (or if you just hack off the bottom end prior to passing it into DHT). I believe these are just integer wrap-arounds.
lexa, we'll be sure to look into compiling with OpenMP!
Thank you!
Sorry, API documentation is incomplete for COLOR() call and needs to be updated.
the row,col parameters you feed to COLOR() call should be relative to image visible area, not full sensor area.
So, the intended use is (pseudocode, there is no raw_image call!)
for(row = 0; row < height; row++) for(col = 0; col < width; col++) { color = COLOR(row,col); data[... ][color] = raw_image(row+top_margin, col+left_margin); }For most cameras this does not matter because top_margin,left_margin are multiple of 2, but both 60D and 1Ds2 use odd top_margin.
Thanks for your response. I'm gonna dig it for a while, though I am not a programmer but only a user. Best,
dcraw.c is self-documented (in computer code). The function you need to analyze is scale_colors()
I am very sorry if you felt weary of our conversations. As I said, I have difficulty in clarifying dcraw’s raw processing, and its key seems to be scaling at last. Given scaling is the setting of white level as you said, how are the values between black and white levels then converted to the 16 working bit ? Is there any rule of the conversion as adobe describes in the specification of DNG ? https://wwwimages.adobe.com/content/dam/Adobe/en/products/photoshop/pdfs...
Also, dcraw.c is very well documented (in C language :) and annotated (see links above).
It is very hard to translate from "C" to human language if all terms are not very well defined before.
Sorry, I'm really tired of this discussion.
Yes. Or no. I do not know is my 'data scaling' is the same of your 'mapping to fit'. The problem is with the terms, as usual.
Hi lexa
>dcraw's scale_colors() does
> - black subtraction
> - white balance
> - and data scaling (looks like it is 'setting of white level' in your terms?)
>in one action.
In your wording, scaling of dcraw looks like "mapping DN values so as to fit to the 16 working bit". Is it ?
Hope, this is my last answer in this thread.
dcraw's scale_colors() does
- black subtraction
- white balance
- and data scaling (looks like it is 'setting of white level' in your terms?)
in one action.
If you think it strange, lets join them together in the name of black level application. For me, setting was fixing and a state before implementation. In this regard, I had forgotten to note another element of white level implementation.
Still unable to understand what is 'setting of black level' if 'subtraction of black level values' is a separate step.
Pages