I’ve gone back and forth about the whole exif enchilada, but I’ve found I really only need the essential exposure/focal length information carried forward. If I want to pick at the image exif-wise, I just open the raw; I put in a exiftool-based dialog box for that purpose.
Edit: Oh, TIFFs vex that approach; the libtiff-supported metadata is not camera-oriented.
I guess your problem is coming from the thumbnail(s) in the RAW file. I had to deal with the same problem in photoflow, and came up with a pretty simple solution with EXIV2. You can check the lines of code starting from here.
I, uh, finally got around to implementing this exif cleanup from darktable, but it seems like when I write exif data to a TIFF it still ends up having 4 subimages of some sort.
Unlike before, where the first image was the good one and the other three weren’t, now the first two both contain the full image, the third one is a corrupt thumbnail (below), and the fourth simply crashes GIMP.
At this point I’m not sure what to do besides disable TIFF exif writing again. The TIFFs crash Photoshop, which is obviously not desirable behavior.
There is also a line in dt saying you cannot write metadata via Exiv2 to an open TIFF file, you have to close it first and do it in a second pass. Or rather, you cannot write to a multi-page file, so you have to close after the first page, then add Exif, then append other pages.
Back to exiv2, my understanding of its operation is that you build a data structure with the tags you want, then you apply that data structure to the image file with code that looks like this:
After digging into the whole metadata thing a couple of years ago, I decided to rely on the raw file as the canonical source for all data related to the capture, and store only exposure information, if that, in my renditions. I used the various image libraries’ metadata writing functions, although jpeg and png required supplementary support to organize the tags in the IFDs.
The one bit of crucial metadata in my little world is the processing toolchain that describes how the rendition is produced from the source (raw) file, and I currently store that in EXIF:ImageDescription. One day I’ll explore using the XMP tags, but that’s a low priority right now.
I fiddled a bit with exiv2 in considering it for the upcoming rawproc 1.0. The main challenge was replacing or complementing all use of my image data C++ map structure, which also gets stuff like libraw-collected information and things I use internally. I’ll probably revisit when I resume consideration of how to embed the toolchain…
Ah, a to-do I’d forgotten about. I’m fairly certain liftoff has a way to write rationals, will try to look it up, seems we have internet at cabin-in-the-woods now…
I’d let L48-L58 be handled by exiv2 as well, you only need the libtiff lines above to define the image content/format before writing out the buffers.
As for what is “minimal” (and wether it goes into Exif.Image/IFD0 vs Exif.Photo/ExifIFD), just check Tables 17 and 18 in the Exif spec for what is mandatory.
Back from cabin-in-the-woods, where the internet proved to be another kind of dodgy…
Inspecting my code brought forth recall of the original development journey. I remember now thinking, “nice, libtiff doesn’t require formatting a rational”, so I just let it save my internal float value thinking it would handle the dirty work. Bad assumption…
Thinking about your original problem, based on my present understanding of exiv2 it now seems you were using the Exiv2 data structure you originally read from the input file, which for a raw would have contained the IFDs with the ancilliary renditions, thumbnails, embededd JPEGs, etc. Starting with a new Exiv2 instance and populating it for export should be alleviating that.
Got me to re-consider using exiv2, but I’m coming back to the same conclusion: for renditions, I don’t want to pass on much past shutterspeed/aperture/ISO/date, and feel compelled to include orientation/photometricinterpretation for interoperability. Accordingly, I’m going to fix my present use of the libtiff/jpeg/png libraries (particularly exposuretime as a rational in TIFF) instead of using another library. If this doesn’t meet some ‘standard’ or other expectation, well, my first priority isn’t a customer base, anyway…