v29.0.0

• 💔/🐞/📦 ExifTool sometimes returns boolean values for some tags, like SemanticStylePreset, but uses "Yes" or "No" values for other tags, like GPSValid (TIL!). If the tag name ends in Valid and is truthy (1, true, "Yes") or falsy (0, false, "No"), we'll convert it to a boolean for you. Note that this is arguably a breaking API change, but it should be what you were already expecting (so is it a bug fix?). See the diff to the Tags interface in this version to verify what types have changed.

• 📦 Reduced streamFlushMillis to 10. This reduced elapsed time for the full test suite by 2.5x on macOS and 3x on Windows, and drops the upper latency bound substantially. Note that this is at the risk of buffered stream collisions between tasks. The (extensive) test suite on Github Actions (whose virtual machines are notoriously slower than molasses) still runs solidly, but if you see internal errors, please open a Github issue and increase your streamFlushMillis.

• 💔 TypeScript now emits ES2022, which requires Node.js 18.

GPS improvements

• 🐞/📦 GPS Latitude and GPS Longitude values are now parsed from DMS notation, which seems to avoid some incorrectly signed values in some file formats (especially for some problematic XMP exports, like from Apple Photos). Numeric GPSLatitude and GPSLongitude are still accepted: to avoid the new coordinates parsing code, restore GPSLatitude and GPSLongitude to the ExifToolOptions.numericTags array.

• 🐞/📦 If ExifToolOptions.geolocation is enabled, and GeolocationPosition exists, and we got numeric GPS coordinates, we will assume the hemisphere from GeolocationPosition, as that tag seems to correct for more conditions than GPS*Ref values.

• 🐞/📦 If the encoded GPS location is invalid, all GPS* and Geolocation* metadata will be omitted from ExifTool.readTags(). Prior versions let some values (like GPSCoordinates) from invalid values slip by. A location is invalid if latitude and longitude are 0, out of bounds, either are unspecified.

• 🐞/📦 Reading and writing GPS latitude and GPS longitude values is surprisingly tricky, and could fail for some file formats due to inconsistent handling of negative values. Now, within ExifTool.writeTags(), we will automatically set GPSLatitudeRef and GPSLongitudeRef if lat/lon are provided but references are unspecified. More tests were added to verify this workaround. On reads, GPSLatitudeRef and GPSLongitudeRef will be backfilled to be correct. Note that they only return "N" | "S" | "E" | "W" now, rather than possibly being the full cardinal direction name.

• 🐞 If ignoreZeroZeroLatLon and geolocation were true, (0,0) location timezones could still be inferred in prior versions.

• 📦 GPS coordinates are now round to 6 decimal places (≈11cm precision). This exceeds consumer GPS accuracy while simplifying test assertions and reducing noise in comparisons. Previously storing full float precision added complexity without practical benefit.

Full Changelog: v28.8.0...v29.0.0