Type: Feature request
Where: All three implementations — jadiv-timelapse_plus.py:186-188 (cv2.resize(img, (target_width, target_height), ...)), jadiv-timelapse.py (equivalent resize call), and docs/index.html (ctx.drawImage(img, 0, 0, targetWidth, targetHeight)).
Problem:
The target video resolution and aspect ratio are computed once from the first photo in the sorted sequence (including which of width/height is treated as "portrait"). Every subsequent photo is then force-resized/drawn into that exact target_width x target_height box, regardless of its own aspect ratio. If a folder contains photos with a different aspect ratio than the first one (a very plausible real case: camera rotated between shots, mixed camera/crop settings, a stray screenshot or differently-cropped image mixed into the sequence), those frames are stretched or squashed to fit — silently, with no warning to the user.
This is a natural companion to the aspect-ratio work referenced in #13 (which is about testing the existing per-file math) — this issue is about the cross-file assumption that every photo shares one aspect ratio.
Suggested approach:
When a photo's own aspect ratio doesn't match the target's, letterbox/pillarbox it (scale to fit within the target box preserving aspect ratio, pad the remainder with black) instead of stretching to fill, in all three variants. As a smaller first step, at least warn the user (e.g. "N photos have a different aspect ratio than the first photo and were stretched to fit") so the distortion isn't a silent surprise.
This issue was created by an automated issue-hunt routine.
Type: Feature request
Where: All three implementations —
jadiv-timelapse_plus.py:186-188(cv2.resize(img, (target_width, target_height), ...)),jadiv-timelapse.py(equivalent resize call), anddocs/index.html(ctx.drawImage(img, 0, 0, targetWidth, targetHeight)).Problem:
The target video resolution and aspect ratio are computed once from the first photo in the sorted sequence (including which of width/height is treated as "portrait"). Every subsequent photo is then force-resized/drawn into that exact
target_width x target_heightbox, regardless of its own aspect ratio. If a folder contains photos with a different aspect ratio than the first one (a very plausible real case: camera rotated between shots, mixed camera/crop settings, a stray screenshot or differently-cropped image mixed into the sequence), those frames are stretched or squashed to fit — silently, with no warning to the user.This is a natural companion to the aspect-ratio work referenced in #13 (which is about testing the existing per-file math) — this issue is about the cross-file assumption that every photo shares one aspect ratio.
Suggested approach:
When a photo's own aspect ratio doesn't match the target's, letterbox/pillarbox it (scale to fit within the target box preserving aspect ratio, pad the remainder with black) instead of stretching to fill, in all three variants. As a smaller first step, at least warn the user (e.g. "N photos have a different aspect ratio than the first photo and were stretched to fit") so the distortion isn't a silent surprise.
This issue was created by an automated issue-hunt routine.