Isn't that what you told me to do in your previous comment?

So I tried compiling by running "nmake /DLIBRAW_BUILDLIB -f Makefile.msvc" but it said "NMAKE: fatal error U1065: invalid option 'W' Stop."
I'm probably putting that flag in the wrong spot, but I tried to hack around it by swapping the dllimport and dllexport in libraw_types.h, so that it uses dllexport if I don't define that flag, which is what I'm trying to do anyway.
Doing that, I start compiling by running "nmake -f Makefile.msvc" but I get a bunch of errors (it won't let me post all of them because it thinks it's spam, but they all generally look like the following):

libraw_datastream.obj : error LNK2019: unresolved external symbol "__declspec(dl
limport) const LibRaw_windows_datastream::`vftable'" (__imp_??_7LibRaw_windows_d
atastream@@6B@) referenced in function "public: __thiscall LibRaw_windows_datast
ream::LibRaw_windows_datastream(void *)" (??0LibRaw_windows_datastream@@QAE@PAX@
Z)
libraw_c_api.obj : error LNK2019: unresolved external symbol "__declspec(dllimpo
rt) public: int __thiscall LibRaw::COLOR(int,int)" (__imp_?COLOR@LibRaw@@QAEHHH@
Z) referenced in function _libraw_COLOR
demosaic_packs.obj : error LNK2001: unresolved external symbol "__declspec(dllim
port) public: int __thiscall LibRaw::COLOR(int,int)" (__imp_?COLOR@LibRaw@@QAEHH
H@Z)
bin\libraw.dll : fatal error LNK1120: 29 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0
\VC\BIN\cl.EXE"' : return code '0x2'

That should say I've added a #include < libraw.h > without the spaces but I guess it thought I was trying to add some kind of HTML tag

Thank you, that's very helpful. I'll go with LibRaw's sensor-size and ActiveArea then.

I actually care mostly about the DefaultCrop since that's what the users sees. I guess Adobe reads the final size from the MakerNotes (e.g., Sony has a FullImageSize tag) and then probably centers it in the ActiveArea. Will see if I can extract some of those with libexiv2.

To make it more complicated, there are also ImageWidth/Height Exif tags at least for Canon/Sony, which seem to also include user settings like 16:9 crop. Adobe (in DNG 1.4) interestingly translates that to DefaultUserCrop, which means the DNG includes 4 nested crops (sensor size, active area, default crop, default user crop)...

Solved, now I'm able to get the exact match.
Thank you!

To turn it off, use '-c 0' switch of dcraw_emu (or set imgdata.params.adjust_maximum_thr to 0.0).

Simple test:

$ ./bin/dcraw_emu -h -c 0 ~/temp/camera04_01.CR2
$~/dcr926/dcraw -h ~/temp/camera04_01.CR2
$ md5 ~/temp/camera04_01.*ppm
MD5 (/home/lexa/temp/camera04_01.CR2.ppm) = 6bc70a092bb0096bd75d1f9ef54714b4
MD5 (/home/lexa/temp/camera04_01.ppm) = 6bc70a092bb0096bd75d1f9ef54714b4

Apologies I reversed the ifdef in my head, I should have pasted the else branch, it too sets the same variable, which appears to be part of the context of dcraw rather than the LibRaw code which is testing in convert_to_rgb_loop the value in the libraw_internal_data.internal_output_params.raw_color. I had imagined the intent was to avoid the matrix multiply when the matrix is unity.

Re subclassing - fine with me I'm probably going to combine that and some other code into a single pass over the memory as easy wins in performance.

Thanks for your efforts in producing the library much easier to use than the dcraw code direct.

Kevin

This code is under #ifndef LIBRAW_LIBRARY_BUILD, so it is not compiled into LibRaw (because LibRaw is compiled with LIBRAW_LIBRARY_BUILD defined).
LibRaw's code snippet is mostly the same, but without document_mode into account. And it is not wrong.

Histogram: LibRaw calls convert_to_rgb_loop() virtual function. If you do not need histogram calculation, you may provide your own convert_to_rgb_loop() in derived class. The histogram is needed for automatic brightness correction (if used).

I am doing a project about raw file processing.I do not know how to use C++ to write source code to modifies some parameters of RAW file . I have thought about the question for days. Can you give me some suggestion about it.
Thank you!

use imageProcessor.imgdata.params.no_auto_bright=1 before processing;

http://www.libraw.org/docs/API-datastruct-eng.html#libraw_output_params_t

Could you please explain your problem in more details?

There are two phases on raw processing:
- raw data decoding (decompressing)
- and postprocessing (black subtraction, white balance, demosaic, color conversion)

For Canon files, decoding is relatively slow, thanks for huffman compression used. RawSpeed is faster than LibRaw for these files (but you can use RawSpeed indirectly via LibRaw).

Postprocessing speed varies from method to method. For timelapse (e.g. video output in 1080p?) you don't need full resolution, so 'half' demosaic may be used.

The LibRaw's benchmark is 'samples/postprocessing-benchmark.cpp' which is included in LibRaw since v0.15