optimisation/bug in convert_to_rgb() ?

I'm wondering if the code in dcraw_common in convert_to_rgb() is wrong...

#ifndef LIBRAW_LIBRARY_BUILD
raw_color |= colors == 1 || document_mode ||
output_color < 1 || output_color > 5;
#else
...

I thought it should be setting libraw_internal_data.internal_output_params.raw_color so that the convert_to_rgb_loop() function would not apply the matrix?

Also I wondered about adding an option to not compute the histogram in that function?

Thanks

Kevin

Forums: 

This code is under #ifndef

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).

-- Alex Tutubalin

Apologies I reversed the

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

raw_color is, indeed, to

raw_color is, indeed, to avoid color matrix multiplication in convert-to-rgb loop.
This flag is set not only in this ifdef, but in some other cases too (NikonScan files, Leaf HDR files)

-- Alex Tutubalin