In a previous fix [0], the call to exif_transpose was kept to allow
rotation of images format different than `JPEG`.

After a small test, it appeared that the call would crash if the image
in another format had the same `LensInfo` tag.
So it's safer to not call this method at all.

With this commit, the rotation tag is retrieved disregarding the file
format by using the `getexif` method if available, falling back to the
private method for Pillow < 6 support.

As a bonus, a test is also added with a small embedded `JPEG` image,
crafted with an `Orientation` exif tag and, for reference,  the
`LensInfo`tag that caused so much trouble.

The fix referenced in [0] was not forward-ported as it was only moving
the code the is completely removed in the present.

[0] b83c48d5c48954193

closes odoo/odoo#65793

X-original-commit: 38f696dfa5134d93b5a3a1c0647aa8f8c1bd18c9
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

Before this commit, some images would display incorrectly orientated.

This typically happens for images taken from a non-standard orientation
by some phones or other devices that are able to report orientation.

The specified transposition is applied to the image before all other
operations, because all of them expect the image to be in its final
orientation, which is the case only when the first row of pixels is the top
of the image and the first column of pixels is the left of the image.

Moreover the EXIF tags will not be kept when the image is later saved, so
the transposition has to be done to ensure the final image is correctly
orientated.

closes odoo/odoo#38717

X-original-commit: 0f8e132ec0495fcdfa0a47d5b9c98a2f6f10c7d8
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

closes odoo/odoo#37058

Signed-off-by: Nans Lefebvre (len) <len@odoo.com>

PR: #34925

Both for performance and to avoid reducing the quality of an image in unexpected
situations.

- avoid applying useless operations in the first place
- do not count an operation if it had no effect
- allow quality 0 as a safe default that does not forcefully re-save the image

PR: #31208

Since all the tools have been merged into one, the tests can be restructured and
the duplicate tests removed.

task-1958000
PR: #31811

* = hr, im_livechat, mail, payment, purchase, web, web_editor, web_unsplash,
	website_profile, website_slides

Since the merge of all image tools into one function, the intermediary functions
are not needed anymore.

task-1958000
PR: #31811

Make the image tools more consistent and easier to maintain by having a single
function handling all the cases, instead of several functions doing more or less
the same thing with obscure differences.

Also introduce a new function to guess the size based on a field name, to be
used in the following commit.

task-1958000
PR: #31811

Following commit: 6801baa662a01d2e1990094735b22dc512930b2a

Crop is always used when we know the target size. Therefore there is no point
to pass a ratio argument. However size is required now.

Also "center" is always used, so make it the default type.

task-1958000
PR: #31811

* = website_partner, website_profile, website_sale, website_slides

Before
======

Since commit: 2e3848b394748bf23eff0db0d6d92b9e8c9bf875

The images that are resized have additional borders if the target ratio is
different than the image ratio. Those borders are transparent if the image
format supports it, and are white otherwise.

With that current solution, if the background where the image is displayed is
another color than white, it is looking really bad.

Moreover, most images are stored resized like this, so it is not even possible
to decide if it should have borders or not depending on the context, the
original image and ratio is forever lost.

It is also inconsistent because if the image is already smaller than the target
size then it doesn't include borders. In that case it keeps the original ratio
instead of the target ratio. So it isn't even guaranteed that the target
ratio is going to be respected.

After
=====

This commit will solve all of those problems by always keeping the ratio of the
original image.

This implies the views should be taking care of adding borders when necessary.

task-1958000
PR: #31811