https://www.libraw.org/docs/API-datastruct-eng.html#libraw_rawdata_t

I've tried all the options that could make a difference, but there are not that many options in the Librarian when compiling LibRaw as a static lib.

I've settled to compile LibRaw with Ox instead O2 and that works just fine. Maybe it's a tick slower than it could, but I think it's fine.

Do you have a big spam problem? The post form always tells me to take more time filling the form. Maybe I type too fast ;-)

Tried the linker option. No change.
This is not available for libraries (I link LibRaw as a static lib). But setting the options in my DLL which links to LibRaw made no change.

I've also played with string pooling and the other options that differ (https://learn.microsoft.com/en-us/cpp/build/reference/o1-o2-minimize-siz...) between Optimization (Speed) which works and Maximize Optimization (Speed) which does not work. Without any success.

I'll stick to /Ox /Ob2 /Oi /Ot for now.

I've tried that. No change :-(
Visual Studio 2022 17.8.1

I've also disabled the optimization for the get_decoder_info() function and even for the declarations for vc5_dng_load_raw_placeholder() and jxl_dng_load_raw_placeholder() in the header.
Did a full rebuild of LibRaw each time, just in case.
No change in the name returned!

I then moved the call to get_decoder_info into a separate function in my code (returns true if the options should be added) and wrapped that in optimize off / on.
Same result. Still returned the wrong name.

I think this is something really strange with Maximum Optimization that somehow rolls things together on a more global level. Normal Optimization works, so I'll use that for now. Until you maybe change the code to work around this somehow.

Looks interesting.

In fact, both functions have the same body:

void LibRaw::vc5_dng_load_raw_placeholder()
{
    // placeholder only, real decoding implemented in GPR SDK
    throw LIBRAW_EXCEPTION_UNSUPPORTED_FORMAT;
}
void LibRaw::jxl_dng_load_raw_placeholder()
{
  // placeholder only, real decoding implemented in DNG SDK
  throw LIBRAW_EXCEPTION_UNSUPPORTED_FORMAT;
}

Looks like Visual studio detects this, compiles as single function, so
else if (load_raw == &LibRaw::vc5_dng_load_raw_placeholder)
and
else if (load_raw == &LibRaw::jxl_dng_load_raw_placeholder)
Are both true....

Looks like
1) these functions should be separated in additional code unit
2) All optimizations should be disabled at least for common compilers (gcc, clang, visual studio).

LibRaw::open_bayer() is what you're probably looking for.

I've got this working, following your instructions.
I call:

libraw_decoder_info_t dinfo;
plraw->get_decoder_info(&dinfo);

and compare the dinfo->name with "jxl_dng_load_raw_placeholder()" and "vc5_dng_load_raw_placeholder()", as you suggested (I hope I understood you correctly).

And this works very well for the problem image. In the debug built.

When I switch to the release built (Visual C++ 2022), the dinfo->name returned is "lossy_dng_load_raw()" for some reason I don't understand yet. I will prepare a release build with debug symbols so I can trace into this. The preprocessor defines etc. the same for both builds.

When I also set the new opcode flags when "lossy_dng_load_raw()" is returned in dinfo->name, the image looks good in the release build too.

Any idea?

Sure, these flags are documented in actual documentation provided with LibRaw 202403-snapshot: https://github.com/LibRaw/LibRaw/blob/master/doc/API-datastruct.html#L12...

This site documentation section contains release docs.

We'll probably make these flags (or similar ones) set by default in the next snapshot/release because JPEG-XL compressed DNGs becomes very common.

Thank you for the file sample.

Here is processing results: https://www.dropbox.com/scl/fi/ooqcaseziap0vwo5ario4/2023-11-11-003-Pano...

dcraw_emu command line used for that:

dcraw_emu -dngsdk -R 3145728 -T 2023-11-11 003-Pano.dng

Technical details:

1. The image is linearized via OpcodeList2 tag value; For similar images use of OpcodeList3 is also possible (probably depends on Adobe software version used).
2. By default, only OpcodeList1 tag is processed by LibRaw
3. To enable OpcodeList2/3 processing LIBRAW_RAWOPTIONS_DNG_STAGE2_IFPRESENT/LIBRAW_RAWOPTIONS_DNG_STAGE3_IFPRESENT flags should be added to imgdata.rawparams.options
4. This translates into numeric value of (1<<20)|(1<<21) so 3145728

This is not perfect solution if one do not want to apply OpcodeList2/3 for all DNG files containing these tags.

To improve it: query decoder used via LibRaw::get_decoder_info() and set the flags only for jxl_dng_load_raw_placeholder() and/or lossy_dng_load_raw() decoders.

You (probably) may receive tag values you want via exif callback: https://www.libraw.org/docs/API-datastruct-eng.html#libraw_callbacks_t and https://www.libraw.org/docs/API-CXX.html#exif

As mentioned on the this site homepage/LibRaw project description:

Additionally, the LibRaw library offers some basic RAW conversion, intended for cases when such conversion is not the main function of the LibRaw-using application (for example: a viewer for 500+ graphic file formats, including RAW). These methods are inherited from the Dave Coffin’s dcraw.c utility (see below the “Project history” section); their further development is not currently planned

LibRaw RAW postprocessing (sample code) do not apply any custom aspect ratio change, although you may implement your own on processed image.

It is usually pointless to discuss problems in processing a file without having the file itself

This library is in C++, i have done all of my work in python. Is there any other alternative?

I have tried rawpy it doesn’t support .raw images from above mentioned camera