Add Canon CR3 raw file support #44
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- a few types need to be qualified with crate:: - get_by_tag_code() is now get_by_ifd_tag_code() - Error::InvalidEntry doesn't exist, don't mention it in docs
Have the github workflow ensure that "cargo fmt", "cargo clippy" and "cargo doc" all stay clean too.
As more file formats are added, it gets messy if exif.rs has code that handles the specific internals of each file format. Move most of the logic from heif_extract_exif() into heif::extract_exif_data() in heif.rs.
See https://github.com/lclevy/canon_cr3 for information about the CR3 file format. - Add testdata/canon-r6.cr3: minimized valid CR3 file based on an image from a Canon R6 camera - Update to detect CR3 files in file.rs based on brand name 'crx ' - Add bbox/cr3_moov.rs to handle 'moov' boxes and bbox/uuid.rs to handle Canon UUID sub-boxes that contain EXIF data for CR3 files - Add cr3.rs to handle extracting EXIF from CR3 files - Add basic test cases for CR3 parsing
Remove MultiExifIter, since it seems preferable to support CR3 files from the same API as everything else rather than forcing applications to know while files might need a different API. Instead refactor ExifIter to handle discontiguous regions of a file that have EXIF data. Use this to handle CR3 files that spread EXIF data across multiple boxes (CMT1, CMT2, CMT3). Update the CR3 test case to check that the correct information is returned for the test file.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Continuing the discussion from #41 because I pushed something unrelated to the main branch in my fork, I think it's better to have an explicit feature branch anyway.
Anyway I have working support for parsing tags from CMT1/CMT2/CMT3 boxes, which is important because basic tags like "Date/Time Original" are not in CMT1. I did not go with the MultiExifIter because I think it's too confusing for applications to have to know whether to use ExifIter or MultiExifIter. You can see an example of how I used the library in https://github.com/rolandd/photosync/blob/main/src/pipeline.rs - I do think the correct API is to let consumers get information about media files without having to know about the specific format.
The concerns about handling duplicate tags don't seem worth worrying about to me - we already could have a malformed file with the same tag multiple times in a single box, and my camera at least does not put the same tag in different boxes either.
This branch includes the cleanups that I submitted separately in #43 too.