Canon Makernotes is, sure, array of binary data pointed by 0x927c EXIF tag.
The problem with Canon is camera specific makernotes, so you'll need to process every variant
(Canon CameraInfo1D Tags, Canon CameraInfo1DmkII Tags, etc, etc,etc)
For different vendors you'll need to add more vendors processing.
Exiftool already do this camera/vendor specific processing.
I got some more information on this through the Exiftool documentation, as Exiv2 does not yet support this parameter (under discussion with the Exiv2's author). ideally I would like to avoid using Perl-based Exiftool.
Going first here: http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/index.html (with explanation on how to decypher what follows)
and clicking on Canon, you end up with the tag list, with adresses written in hex.
Then at 0x0004, clicking on “Canon ShotInfo Tags” brings you down to a so called 2-byte-offseted “index2” at number 12 (and I have no idea what that means), where you’ll find the little bugger “CameraTemperature”.
With this information, I have to find out how to read that out either from the raw file, getting my hands dirty, or through the Exiv2 API, if it allows it knowing the exact locations in the makernote...
Feel free to advise, although i understand this not Libraw's concern.
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.
Ok, I understand that it would cumbersome to maintain such feature. I will give it a try to either exiv2 or exiftool. The problem with using a command line output is that it would make me digress a bit from my software intended design. So far I manage to have things work in Windows, Mac and Linux without any hassle but dealing with exiftool command line will break things out of my software, and maybe forcing the user to install exiftool too?...
exiv2 seems to allow to keep things more internal.
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.
Since 1.5 year I started developing yet another software for astrophotography called "LightDrops". It's still a modest project but I hope it will grow. It's hosted in Github for now: https://github.com/raphaelattie/LightDrops
I'm not a professional software developer, but a solar physicist and astronomer who learned programming on the job. In this project I am being helped by a professional software developer who has taught me the basic principles of software development, just enough to get me started with this project. I aim at uniting simplicity, scientific precision and efficiency, which are often mutually exclusive in our realm. Libraw is essential in the development of this software and I thank the development team for making it available. Don't hesitate to share ideas for this project, should you have any.
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.
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
The most important thing I do not want is that the patched library is released on a long term support system.
But it seems ok for that because Ubuntu 16.04 is using 0.17.1. However, next Ubuntu will have this problem I think: https://launchpad.net/ubuntu/yakkety/+source/libraw because they apparently use same sources than testing.
0.18 should fix it ? If yes no problem for me, I will wait. But users with Ubuntu 16.10 will probably crash, except if someone patch the 0.17.2 to fix the bug. So after that we can ask to Ubuntu dev's team to fix the package.
Use Dropbox, or google drive or any other file sharing service.
https://github.com/LibRaw/LibRaw/issues/76
Canon Makernotes is, sure, array of binary data pointed by 0x927c EXIF tag.
The problem with Canon is camera specific makernotes, so you'll need to process every variant
(Canon CameraInfo1D Tags, Canon CameraInfo1DmkII Tags, etc, etc,etc)
For different vendors you'll need to add more vendors processing.
Exiftool already do this camera/vendor specific processing.
I got some more information on this through the Exiftool documentation, as Exiv2 does not yet support this parameter (under discussion with the Exiv2's author). ideally I would like to avoid using Perl-based Exiftool.
Going first here: http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/index.html (with explanation on how to decypher what follows)
and clicking on Canon, you end up with the tag list, with adresses written in hex.
Then at 0x0004, clicking on “Canon ShotInfo Tags” brings you down to a so called 2-byte-offseted “index2” at number 12 (and I have no idea what that means), where you’ll find the little bugger “CameraTemperature”.
With this information, I have to find out how to read that out either from the raw file, getting my hands dirty, or through the Exiv2 API, if it allows it knowing the exact locations in the makernote...
Feel free to advise, although i understand this not Libraw's concern.
Hello,
we are using libraw in our software: http://free-astro.org/index.php/Siril as RAW images are often used in astrophotography.
logo: https://free-astro.org/svn/siril/trunk/pixmaps/siril_logo.svg
Thanks for this library.
Cheers,
You may implement own datastream (e.g. based on LibRaw_bigfile_datastream which uses FILE* I/O) and own open_wfile() method.
I found std::filebuf usage later. So, it looks like there is no easy way to handle Unicode paths in mingw64 builds :(.
Windows binaries are available from exiftool site: http://www.sno.phy.queensu.ca/~phil/exiftool/
Mac and linux 'binaries' are just perl scripts (with lot of perl libraries). In RawDigger/Mac we store this script/libs in app resource folder.
Great! If I can provide the binary, it's fine then. I never used QProcess, but I'll find out. Thanks Alex!
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.
Ok, I understand that it would cumbersome to maintain such feature. I will give it a try to either exiv2 or exiftool. The problem with using a command line output is that it would make me digress a bit from my software intended design. So far I manage to have things work in Windows, Mac and Linux without any hassle but dealing with exiftool command line will break things out of my software, and maybe forcing the user to install exiftool too?...
exiv2 seems to allow to keep things more internal.
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.
Hi,
Since 1.5 year I started developing yet another software for astrophotography called "LightDrops". It's still a modest project but I hope it will grow. It's hosted in Github for now: https://github.com/raphaelattie/LightDrops
I'm not a professional software developer, but a solar physicist and astronomer who learned programming on the job. In this project I am being helped by a professional software developer who has taught me the basic principles of software development, just enough to get me started with this project. I aim at uniting simplicity, scientific precision and efficiency, which are often mutually exclusive in our realm. Libraw is essential in the development of this software and I thank the development team for making it available. Don't hesitate to share ideas for this project, should you have any.
Thanks
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.
there is exiv2 library: http://www.exiv2.org/
Also, you may install own exif parser callback to be called on each EXIF tag.
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
There is no special data field/parsing code for this data in libraw.
For cameras with temperature data stored in EXIF fields (panasonic/leica, for example) you may install own EXIF parser callback to get this data.
Thank you :)
0.17.2 updated too: https://github.com/LibRaw/LibRaw/commit/c3bf29831d6a1eec969391d1a41f2e76...
and checked: dcraw_emu -q 1 works fine with your sample
And here it is: https://github.com/LibRaw/LibRaw/commit/8a8723b0da66f8d858d93c23f2aeda26...
It is against 'already patched' version
OK.
Glad to see that it will be fixed.
Thank you.
Sorry, current public snapshot contains this broken patch. To be reverted today
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
Thank you so much for your answer.
The most important thing I do not want is that the patched library is released on a long term support system.
But it seems ok for that because Ubuntu 16.04 is using 0.17.1. However, next Ubuntu will have this problem I think: https://launchpad.net/ubuntu/yakkety/+source/libraw because they apparently use same sources than testing.
0.18 should fix it ? If yes no problem for me, I will wait. But users with Ubuntu 16.10 will probably crash, except if someone patch the 0.17.2 to fix the bug. So after that we can ask to Ubuntu dev's team to fix the package.
Thanks again
Pages