Skip to content

fix: compute GoPro 360 crop params dynamically from image dimensions#211

Open
chrisdebian wants to merge 1 commit into
mapilio:mainfrom
chrisdebian:fix/gopro360-dynamic-crop-params
Open

fix: compute GoPro 360 crop params dynamically from image dimensions#211
chrisdebian wants to merge 1 commit into
mapilio:mainfrom
chrisdebian:fix/gopro360-dynamic-crop-params

Conversation

@chrisdebian
Copy link
Copy Markdown
Contributor

Summary

  • Replaces hard-coded 4096×1344 pixel values in the exiftool XMP-tagging step of gopro360max_stitch() with exiftool's computed-value syntax, so CroppedArea and FullPano tags are derived from the actual ImageWidth/ImageHeight at write time
  • Adds a docstring to gopro360max_stitch() explaining the pipeline stages and the dynamic crop approach
  • Formula: CroppedAreaTopPixels = (ImageWidth / 2 − ImageHeight) / 2

Closes #200

Why the hard-coded values break

The original command assumes every GoPro MAX export is 4096×1344 px. GoPro MAX can also output 4096×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 their 4096×2048 footage. Maintainer verification on real GoPro MAX hardware is recommended before merging.

Test plan

  • Run gopro360max_stitch() against a 4096×1344 GoPro MAX clip — verify XMP metadata and panorama viewer display are unchanged
  • Run against a 4096×2048 clip (issue GoPro 360 videos processing: more flexible Exiftool crop parameters #200 reproduction case) — verify correct crop offsets and panorama viewer alignment
  • python -m pytest tests/ passes (95 tests, no GoPro hardware required)

🤖 Generated with Claude Code

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
@ozcan-durak
Copy link
Copy Markdown
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

GoPro 360 videos processing: more flexible Exiftool crop parameters

2 participants