To be precise, this is data for last (largest) preview, which is incomplete too.

raw section is completely not present in file (because of truncation)

Although most functions in LibRaw/internal/dcraw_common.cpp looks like untaltered dcraw.c code, this is not completely true.
Data layout in LibRaw is different and old (dcraw's) variables are #define-d in internal/var_defines.h

You may try this approach:
1) Subclass LibRaw:

class MyLibRaw: public LibRaw....

2) Implement own dcraw_process() (with different function name) and build it using dcraw/libraw functions (pre_interpolate(), scale_colors(), etc)

Both FastStone and IrfanView shows embedded JPEG file. This part of image is correct.

Meanwhile, the file is exactly the same in contents (of JPEG preview) as file at rawsamples.ch. Why do you think this file is correct?

Understood.

Thanks Alex. Looking forward to playing around with this as I'm working on a project that needed support for filtering images by the usual metadata fields. Much appreciated.

Yeah, the OpenImageIO implementation doesn't offer too much flexibility, but that's understandable. Maybe for RAW files it makes sense for me to just call libraw directly.

This code path is being using while importing a large number of images into a database, so it will only ever need the metadata. Later on, when the image needs to be decoded and presented to the user, an entirely different code path is taking so the issues with adjust_sizes_info_only() shouldn't really be a problem. I'll make that call after open_file() when loading metadata but I'll make it after unpack() when preparing the image for presentation.

This is fantastic, thank you.

Alex,

Thanks for the quick reply. If you take a look at the implementation in OpenImageIO you'll see that they call unpack() immediately after calling open_file():

https://github.com/OpenImageIO/oiio/blob/master/src/raw.imageio/rawinput...

From your comments above, it sounds like I could start reading the metadata immediately after open_file() and not call unpack() at all. Lower down, on line 285, there's a comment that indicates where the metadata reading code begins:

https://github.com/OpenImageIO/oiio/blob/master/src/raw.imageio/rawinput...

Is all of that code "safe" to call after only calling open_file()? Will valid values, if present, be correctly read? The last call to read_tiff_metadata() looks like it's just using standard OpenImageIO routines to read a TIFF header, I assume that would be OK as well?

Thanks again!

Followup:

if you need to free file handle w/o releasing metadata, there is recycle_datastream() call, this call will close file handle and nothing more.

Looks like rawpy incompleteness.

For X-Trans sensors (imgdata.idata.filters == 9), color pattern is contained in
imgdata.idata.xtrans (6x6 array, indexed by row%6,col%6, row and col are relative to visible area)
and in
imgdata.idata.xtrans_abs (same as above, but row/col are relative to full sensor)

The patch works. Thanks!

Here is the patch:

diff --git a/dcraw/dcraw.c b/dcraw/dcraw.c
index fb78663..87915d9 100644
--- a/dcraw/dcraw.c
+++ b/dcraw/dcraw.c
@@ -2768,7 +2768,7 @@ void CLASS unpacked_load_raw()
while (1 << ++bits < maximum)
;
read_shorts(raw_image, raw_width * raw_height);
- if (maximum < 0xffff)
+ if (maximum < 0xffff || load_flags)
for (row = 0; row < raw_height; row++)
{
#ifdef LIBRAW_LIBRARY_BUILD
diff --git a/internal/dcraw_common.cpp b/internal/dcraw_common.cpp
index 168a095..d8e22e6 100644
--- a/internal/dcraw_common.cpp
+++ b/internal/dcraw_common.cpp
@@ -2472,7 +2472,7 @@ void CLASS unpacked_load_raw()
while (1 << ++bits < maximum)
;
read_shorts(raw_image, raw_width * raw_height);
- if (maximum < 0xffff)
+ if (maximum < 0xffff || load_flags)
for (row = 0; row < raw_height; row++)
{
#ifdef LIBRAW_LIBRARY_BUILD

> LibRaw 0.19 says that the black level is 205 and white level is 4095

This part is as it should be, the camera is 12-bit.