I try's the sample applications and you are right that all is working.

The problem is that the sample applications are not setting any params. As soon as you add my param list the output colors are also washed out.

I am using the following params to speed up decoding of x-trans files (For Canon/Nikon it doesn't matter). Without those parameters the encoding is much slower. But if I set only one parameter the color are washed out independently which parameter I set:
use_camera_wb$set(params$slice, 0);
use_auto_wb$set(params$slice, 0);
output_tiff$set(params$slice, 0);
half_size$set(params$slice, 0);
user_qual$set(params$slice, 0);

EOS R5 (released in 2020) and R3 (released in 2021) are different cameras.

R3 will be supported in the next public version (snapshot or beta/release, whatever come first)

This patch: https://github.com/LibRaw/LibRaw/commit/b31fa58eea272c4ba67ccdbd527f329a...

Exposes adjust_maximum_thr to the C-API

Hi Alex,

with dcraw_emu using -M -o 0 -c 0 -j -W -q 1 -4 -T as arguments, both TIFF images converted from CR3 now look equally bright, and the two TIFF images converted from the corresponding DNG files also look equally bright. However, the TIFF images converted from CR3 and DNG differ in brightness. Is this by design?

I'm now trying to figure out how to use it programmatically. The parameter adjust_maximum_thr seems not to be accessible from the libraw_set_... API. I'm using C# with InteropServices. I think I can write such method and amend it to libraw; or better maybe you should consider the addition of this method (something like libraw_set_maximum_threshold).

I already used in my program:

```
libraw_set_no_auto_bright(handler, 1);
libraw_set_bright(handler, 1.0f);

```
so I expected no automatic brightness adjustment anyway.

Thanks, LelliD

We never publish files that are sent to us without explicit permission.

Please use any file sharing service (e.g. WeTransfer/free option) and send the link to info@libraw.org

We do not provide precompiled snapshot versions. Please contact vendor of your software to re-compile it with newer libraw.

Yes (if you do not use earlier github snapshots)

As a result, you use very untested (and not supported) code path :)

Followup:
I do not have msys2/mingw/similar tools installed, so not tested.

MS Visual Studio (community) is free, so it makes sense to use native vendor compiler for Win32

Oh thank you.

If you fix it, you'll make me happy.
Thanks for your feedback

Please, let me know.
Cheers,

OK thanks for your kindness.
But with libraw_open_wfile

I get:

undefined reference to `libraw_open_wfile'

because in the LibRaw code there is

#if defined(_WIN32) && !defined(__MINGW32__) && defined(_MSC_VER) &&           \
    (_MSC_VER > 1310)
  int libraw_open_wfile(libraw_data_t *lr, const wchar_t *file)
  {
    if (!lr)
      return EINVAL;
    LibRaw *ip = (LibRaw *)lr->parent_class;
    return ip->open_file(file);
  }

So it can't work under msys2.