Implemented rotate image feature

[tognee]

Pull request for issue #856

The orientation field contains the "Orientation" tag present in the file (if not present it will default to 1).
The localOrientation field is used to rotate the thumbnail without writing into the original file (by default is one).
Both use the EXIF orientation standard (numbers form 1 to 8) to describe how the image should be rotated.

The app by default rotates the thumbnails using the localOrientation field.
If the users wants to save the tags to the image, the orientation field is used and it is written into the file itself. Most (if not all) image viewers will see that tag and rotate the image accordly. This method is non-destructive on the images as this is a loseless rotation (the image doesn't get re-encoded).

The api/photosedit/rotate endpoint has been added and it accepts POST requests passing:

• image_hash: The hash of the image that needs to be rotated
• angle: A number that is a multiple of 90, that the image will be rotated by. If the number is negative the rotation will be counter-clockwise
• flip: If the image should be filp (can be omitted, the default is false)

[derneuere]

Looks good, but I think we should just stick to one new field. orientation and localOrientation seem to be the same, so we should just stick with orientation and only save it when the setting says so.

[tognee]

I think I can do that but I would need to disable the rotation made by the image library and apply the rotation myself. That way there will be less chances of de-sync of the variables.

Also when the user setting to save tags on the files is changed should all photos be updated or the idea is to have them save the tags only when modified after the settings change?

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication