The latest articles on DEV Community by Daisuke Mino (@minodisk). https://dev.to/minodisk https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F42106%2Fb2f24bef-561c-46b6-8f9d-dfd64f8f9f8b.jpg https://dev.to/minodisk en Daisuke Mino Thu, 09 Jul 2026 14:45:37 +0000 https://dev.to/minodisk/lapse-keep-burst-photos-in-order-on-google-photos-249e https://dev.to/minodisk/lapse-keep-burst-photos-in-order-on-google-photos-249e <p>I built <a href="https://github.com/minodisk/lapse" rel="noopener noreferrer">lapse</a>, a small CLI tool that makes the EXIF timestamps of burst-shot JPEGs unique so that Google Photos displays them in the order they were shot.</p> <h2> The problem </h2> <p>When you shoot a burst, many frames land within the same second. Cameras record the sub-second part in EXIF (<code>SubSecTimeOriginal</code>), but Google Photos ignores it — so photos taken in the same second lose their shooting order after upload.</p> <h2> What lapse does </h2> <p>lapse walks through the JPEGs in a directory in natural filename order (<code>image_2.jpg</code> before <code>image_10.jpg</code>) and assigns each file:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>new time = max(original time, previous file's new time + 1 second) </code></pre> </div> <p>The first file keeps its original time. Only frames collapsed into the same second get pushed forward, one second at a time; separate scenes with real time gaps keep their original capture times. The result is monotonically increasing timestamps that match the filename order — which is enough for Google Photos to sort them correctly.</p> <p>Files that already have unique timestamps are not touched at all, so re-running is idempotent. It's a destructive operation by nature, so there's a <code>--dry-run</code> flag to preview the rewrites first:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code><span class="c"># Preview (no rewriting)</span> lapse <span class="nt">--dry-run</span> /path/to/photos <span class="c"># Run</span> lapse /path/to/photos </code></pre> </div> <h2> Lossless by construction </h2> <p>The part I cared most about: lapse never decodes or rebuilds the JPEG. It patches the date-time tag values (fixed 19 bytes each) in place inside the APP1 segment, so every other byte — including the image scan data, GPS tags, and MakerNote — is bit-identical before and after. Writes go to a temporary file followed by an atomic rename, so a crash mid-write can't corrupt the original.</p> <p>This is also why it's a pure Rust implementation with an in-house minimal TIFF/IFD parser instead of depending on ExifTool or EXIF-writing crates: general-purpose writers rebuild segments and risk corrupting MakerNote offsets.</p> <h2> Try it </h2> <p>Prebuilt binaries for Linux, macOS, and Windows are on the <a href="https://github.com/minodisk/lapse/releases/latest" rel="noopener noreferrer">Releases page</a>, or build from source with Cargo. If you shoot bursts and organize them in Google Photos, give it a try.</p> rust cli photography