Exif read/write on HDR images
it would be nice if exiv2 could read/write information on HDR image file formats. Both RadianceHDR (.pic, .hdr) and OpenExr (.exr) seem to support a kind of custom data to store along with the image.
The use case for such a feature would be to store camera information from the original raw/jpeg files into the created hdr file. In such a way it would be possible to open the Hdr file and still have all exif information, which then could be stored into the newly created tonemapped (jpeg) image.Additional information:
- Radiance HDR - http://paulbourke.net/dataformats/pic/
- OpenEXR Technical Intro - http://www.openexr.com/TechnicalIntroduction.pdf
Luminance HDR Team
Updated by Robin Mills over 7 years ago
- Status changed from New to Assigned
- Assignee set to Robin Mills
- Target version set to 1.0
I agree. This is a very good idea.
Last summer we had a GSoC (Google Summer of Code) student work on the video code and he did a very good job. We've proposed two projects this year and one of them is to provide support for more formats. We didn't list HDR as a goal, because nobody on the Exiv2 team mentioned it! http://community.kde.org/GSoC/2013/Ideas#Project:_Video_Metadata_Support_Improvements
I'll assign this issue to me and perhaps it'll be dealt with this summer.
I'm the project mentor for our other proposal (to make Exiv2 "Cloud Ready"). However I'll assign this issue to myself for now, however the intention is to find a volunteer.
Thank you for suggesting this. It's always nice to hear from you.
Updated by Tobias E. over 4 years ago
darktable and GIMP support EXIF+XMP in EXR files by using a non-standard tag. IPTC could be added the same way, it's just not done at the moment. It would be great if this was made into the "standard" way to add metadata to EXR files.
You can see the sample code here:
and shared by both the blob type: https://github.com/darktable-org/darktable/blob/master/src/common/imageio_exr.hh
Updated by Alan Pater over 4 years ago
Tobias E. wrote:
darktable and GIMP support EXIF+XMP in EXR files
Perhaps they could be convinced to take on the task of adding this support to exiv2? As they both use exiv2 and already have knowledge of the openEXR format, would that not be better then everyone reinventing the wheel in possibly incompatible ways?
by using a non-standard tag.
That sounds dangerous.
IPTC could be added the same way, it's just not done at the moment.
Sure, why not?
It would be great if this was made into the "standard" way to add metadata to EXR files.
If it is already a defacto standard, it could be supported. If not, a proper standard could be developed, agreed upon and documented.
Updated by Robin Mills over 2 years ago
- Status changed from Assigned to New
- Target version changed from 0.28 to 1.0
No progress has been made on this. In May, we had a team meeting at my home in England. We discussed v0.27 (later this year) and v0.28 (2019). HDR wasn't discussed.
I'm sure you can appreciate that the team is small (3 active contributors) and there are many requests. We cannot undertake every request. Last July, the Linux security people began fuzzing our code and pushed their demands to the top of our priority. Their unexpected arrival has consumed about 1000 hours of effort in the last 9 months. In addition, we have made build/test enhancements, modernisation of the code to C++11 and many other requests. These new features will appear in v0.27 and v0.28.
In some ways, there's only one way for anybody to be certain of getting a feature implemented and that's to volunteer. However that's not to say that we are lazy or ignore requests. Daniel brought up this topic a few years ago. He also requested stronger CMake support. I've put more than 200 hours into CMake. Luis joined Team Exiv2 in 2017 and has also put lots of effort into CMake. Daniel wasn't alone in requesting CMake and that project has been done.
Regrettably, without a volunteer to deal with HDR, I don't know when this can be achieved. I've been hoping to retire from Exiv2 for at least a year (I was 67 in January). I'm going to unassign myself from this request and set the target to v1.0. That doesn't mean "never", it means "eventually".