fix: compute GoPro 360 crop params dynamically from image dimensions#211
Open
chrisdebian wants to merge 1 commit into
Open
fix: compute GoPro 360 crop params dynamically from image dimensions#211chrisdebian wants to merge 1 commit into
chrisdebian wants to merge 1 commit into
Conversation
Hard-coded 4096x1344 values only work for one specific GoPro MAX recording mode. Use exiftool computed-value syntax so CroppedArea and FullPano tags are derived from actual ImageWidth/ImageHeight, making the command work for any output resolution (e.g. 4096x2048). CroppedAreaTopPixels = (ImageWidth/2 - ImageHeight) / 2 Closes mapilio#200
Contributor
|
thanks @chrisdebian. this one cant go in on review alone like #210 - it changes an exiftool command on real footage, CI cant test it, and a bad value fails silently into misaligned panoramas. do you have a 4096x1344 clip you can test gopro360max_stitch() on? that is the regression case, metadata must stay unchanged with this fix. and if you can log the final cmd + output tags so we see the computed values, that helps a lot. |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
4096×1344pixel values in the exiftool XMP-tagging step ofgopro360max_stitch()with exiftool's computed-value syntax, soCroppedAreaandFullPanotags are derived from the actualImageWidth/ImageHeightat write timegopro360max_stitch()explaining the pipeline stages and the dynamic crop approachCroppedAreaTopPixels = (ImageWidth / 2 − ImageHeight) / 2Closes #200
Why the hard-coded values break
The original command assumes every GoPro MAX export is
4096×1344 px. GoPro MAX can also output4096×2048(full equirectangular), which causes incorrect XMP metadata and panorama viewer misalignment. The fix uses exiftool's${TAG;EXPR}computed-value syntax to read the actual dimensions from each frame and derive the correct crop offsets dynamically.Testing
The existing test suite (95 tests) passes.
gopro360max_stitch()requires external binaries (MAX2spherebatch,ffpb,exiftool) and real GoPro MAX footage, so it cannot be run in CI. The exiftool command string was verified correct against the documented computed-value syntax, and the formula was taken directly from the approach proposed by the original reporter in #200, who confirmed it works on their4096×2048footage. Maintainer verification on real GoPro MAX hardware is recommended before merging.Test plan
gopro360max_stitch()against a4096×1344GoPro MAX clip — verify XMP metadata and panorama viewer display are unchanged4096×2048clip (issue GoPro 360 videos processing: more flexible Exiftool crop parameters #200 reproduction case) — verify correct crop offsets and panorama viewer alignmentpython -m pytest tests/passes (95 tests, no GoPro hardware required)🤖 Generated with Claude Code