I’ve recently discovered that the GD library removes Exif data from the image and replaces it with its own when an image is rotated and saved back out again.
Now we can “re-analyse” photos, we need the original Exif data available, so we shouldn’t be modifying the original image.
Instead, the thumbnail generation should be looking at the Orientation flag, and rotating the thumbnail, not the original.
This also means when manually rotating/flipping images, we can’t touch the original - only regenerate the thumbnails. When the original is viewed, we apply the transformations again stored in the database.
After thinking this through a bit more, we now store the Exif data in MySQL (as of meta data V2) therefore as long as this data isn’t overwritten during a re-analyse, we just use that instead of going back to the original image.
This minimises the changes as the rest of BT’s behaviour can stay as it is now.
When an image is replaced, the stored Exif data must be removed and replaced with that from the new image.
Any images that have been rotated (either manually or automatically using the Exif Orientation flag) must be re-uploaded using the new “replace image” function in 2.1 to restore the correct Exif data for future use/analysis.
Migrated from https://github.com/andysh-uk/blue-twilight/issues/39
No due date set.
This issue currently doesn't have any dependencies.
Deleting a branch is permanent. It CANNOT be undone. Continue?