The discussion will only make sense if specific problematic files are included.

At the moment, we do not have a single example of a file from Samsung on which RAW data would not be unpacked by LibRaw.

AFAIK, Samsung phones records more-or-less (*) normal DNG, so already supported

(*) some DNG files from latest Samsung devices contains incorrect thumnail data (while RAW data is OK)

Use open_file() or open_buffer() and check the return code.

LibRaw is dual-licensed (LGPL 2.1 and CDDL-1), I do not see any problems from our side to use LibRaw under the terms of one of these licenses.

as per update policy: https://www.libraw.org/#updatepolicy

Dear Alex,

thank you for your swift reply. OK, I understand. I mainly use MATLAB (R2022a) -which uses LibRaw- but encountered the issue of not being able to open GPR files. That is why I started to delve into the LibRaw *.exe files. So I will wait until the next MATLAB release (R2023a). Maybe they then support GoPro's GPR files.

As for metadata, I use Exiftool extensively but found the MATLAB implementation of getting RAW metadata (again using LibRaw) faster than my code (which also needs to call Exiftool). However, for a Nikon P6000 file, the CFA layout delivered by MATLAB is different from the one given in Exiftool. And since I also have RAWdigger and see that the individual channels are displayed correctly, I wondered where the error comes from. That was my reason to ask if there would be a LibRaw *.exe file to extract metadata.
If it would be a LibRaw error, then RAWdigger would display the channels wrongly, I guess. But also a MATLAB error seems strange as they use LibRaw.

If you want, I could send you the file. Many thanks for what you do and for spreading your knowledge!
Cheers

Tested (w/ full recompile for both 0.19 and 0.21) and unable to reproduce.

dcraw_process() is only a glue for other functions in processing pipeline, please narrow your search to specific function or code lines.

Yes, of course I understand the issue of partial support. But nevertheless it doesn't make sense to pass a raw to LibRaw for decoding when the camera's not supported. So while the camera list isn't perfect (and I do understand that), in the absence of any other means to make that determination, that's what I have to do.

Clearly if there's the possibility of a better solution that could be implemented in the future, I'd be very happy to use that.

All the best

So what is the preferred method of determining if the camera is supported if not that.

Thanks
David

To solve the issue of reading EXIF copyright data using the C-API, I added a simple function in libraw_c_api.c:

  DllDef int libraw_datastream_read(void *ifp, void *ptr, size_t size, size_t nmemb)
  {
    if (!ifp)
      return -1;
    return ((LibRaw_abstract_datastream *)ifp)->read(ptr, size, nmemb);
  }

Then from my application I can call that function from the exifparser callback installed using libraw_set_exifparser_handler.

Simple and easy.
Of course other similar functions may be added to call various LibRaw_abstract_datastream methods .

I wrote the code to install the callback and the callback gets called when a RAW file is read. Now, from the callback, when the wanted tag is seen, how to I call the datastream read method to read the tag value. The call back receive a pointer to LibRaw_abstract_datastream input stream. The question is how the datastream read method is called from the callback code which is [equivalent to] C code and as such has to use LibRaw C-API. I don't see anything in LibRaw C-API to use a datastream.