You use Qt library. It is very easy to use QProcess wrapper to run exiftool (make sure you've closed raw file handle in Windows to allow access, LibRaw::recycle_datastream() do that, keeping all parsed data in memory).

We supply exiftool binary with our RawDigger software, exiftool's license permits this.

When adding additional metadata parse to libraw we need to support most major camera vendors (C,F,L,N,O,P,P,S,S). Unfortunately vendor specific metadata (makernotes) is not documented and may change in format from camera to camera (even from one firmware version to another).

So we support only metadata that is absolutely necessary for common photographic processing.

For your needs you may also use call to external exiftool program and parse output (command line like exiftool -cameratemperature -csv _81E0220.CR2 ). It is easy to implement and exiftool license is free to do that.

Thanks, I will have a look, this could solve my problem for now. Nonetheless it would be ideal to have this information from within Libraw. In the context of astrophotography, DSLRs get modified sometimes with an inconvenient external display linked to another inner temperature sensor (with extra cost) whereas this information could easily be displayed for monitoring temperature evolution of the electronics by using the existing sensor that throws this information in the raw file or exif data. This would make the management of dark files much sensible and easier. Indeed, sometimes we take a shot at the same temperature as some other night, for which we already have a dark file, or, knowing the two different temperature of two different dark files, we can interpolate a new dark file at the missing temperature, or we just want to characterise the temperature dependance of the noise. It's just a suggestion, but it would be a very nice feature for a future update, it will spare the trouble of adding yet another library to get this extra bit of information.

I didn't know about such tools to get EXIF info programmatically, apart from what Libraw does. Can you recommend one in either C or C++?

Thanks

Thank you :)

and checked: dcraw_emu -q 1 works fine with your sample

OK.

Glad to see that it will be fixed.

Thank you.

LibRaw 0.17.2 (official release from this site) do not have this bug (not crashes on VNG), but do not compile with gcc6.
If someone uses (broken) 3rd party patch - we're not responsible for that.

LibRaw 0.18-201610xx (i expect next public snapshot in october or so) will both compile by gcc6 and will do VNG :)

Current libraw 0.18 public snapshot (this is not release!) from https://github.com/LibRaw/LibRaw is the same as LibRaw 0.17.2: no patch, no bug, no gcc6 compile

And followup again.
Here is the patch: https://github.com/LibRaw/LibRaw/commit/eba7a66e23f2f62cc4c8115af8066f2d...

So, if in your copy of libraw/internal/dcraw_common.cpp
vng_interolate() code starts with:

  struct interpolate_terms {
    signed char y1, x1, y2, x2, weight;
    unsigned char grads;
  };

than your libraw copy is indeed patched by this wrong patch.
Do not use VNG (and use patched library), or do not use gcc6 (and use unpatched library), or wait for autumn LibRaw-0.18 public snapshot (or, may be, 0.18-release)

LibRaw 0.17 (and before) known to be not compilable by gcc6. So if you're using gcc6 and it builds OK, it means you use some modified source.

The patch proposed by community brokes 4-color processing in vng_interpolate. meanwhile, it looks like Debian community use this patch for debian repo: https://github.com/LibRaw/LibRaw/issues/56

(And, yes, they know that the patch is broken, see discussion in github issue thread)

could you please provide exact git command line to fetch exactly the branch you use?
Debian repo (tag system) is unknown for me, so I do not know what tag i need to fetch.

Most likely, debian people has used bad patch from libraw-0.18 (for gcc6 compatibility). This patch (circulating around internet) broke vng interpolation code (but makes libraw source compatible with gcc6)