Possible double EXIF orientation handling for JPEG images during upload

[fabiSwDevBeg]

Caution

Do not file security issues in this tracker.
Send email to security@plone.org instead.
See Report a security issue.

Describe the bug

Images with EXIF Orientation (e.g. Orientation=6 / Rotate 90 CW) are already physically rotated when opened by Pillow, but plone.namedfile still applies its own EXIF-based rotation logic.
This results in inconsistent image handling and incorrect assumptions about image dimensions during upload/import.

During debugging it appears that PIL.Image.open() may already return an image with pixels rotated according to EXIF Orientation, while the EXIF metadata still reports a non-normalized orientation.
plone.namedfile then applies an additional rotation step based on EXIF, leading to double-handling or no-op rotations depending on geometry.

To Reproduce

1. Take a JPEG image with EXIF Orientation = 6 (portrait photo stored as landscape + EXIF).
2. Upload the image to Plone (Classic UI or Volto).
3. Debug the image handling code in plone.namedfile, inspecting:
   • PIL.Image.open(BytesIO(data))
   • img.size
   • EXIF Orientation before any explicit rotation.
4. Observe that:
   • img.size already reflects a portrait image.
   • EXIF Orientation is still 6.
   • plone.namedfile rotation logic is still executed.

Expected behavior

Plone should either:

• Explicitly normalize EXIF orientation using ImageOps.exif_transpose() and then reset Orientation to 1, or
• Detect that Pillow has already applied EXIF orientation and skip additional rotation logic.

In any case, image rotation should be applied exactly once, and image dimensions should be consistent with the applied transformation.

Screenshots

Not applicable (debug-level issue).

Software (please complete the following information):

• OS: Linux
• Browser: Any
• Plone Version: 6.0.15
• Volto Version: 17.22.3
• Pillow 11.0.0
• plone.namedfile 7.0.1

Additional context

A first inspection of the current code suggests that this behavior is not limited to older versions.

When debugging the upload pipeline, PIL.Image.open() loads the image using JpegImagePlugin (as expected for JPEG files) and returns an Image instance whose pixel data already appears to be rotated according to the EXIF Orientation value.

In this scenario:

• the image geometry (img.size) already reflects the rotated image,
• EXIF metadata still reports a non-normalized Orientation value (e.g. 6),
• plone.namedfile then applies its own EXIF-based rotation logic.

This indicates that, at least in some Pillow versions/configurations, EXIF orientation may already be applied automatically when loading JPEG images, making the additional rotation logic in plone.namedfile redundant or incorrect.

[davisagli]

@fabiSwDevBeg Would it be possible for you to provide a sample image that demonstrates this problem, and give us permission to use it for testing? (preferably one that is not too large in file size)

[fabiSwDevBeg]

In this example image:

the EXIF data shows (using exiftool):

Orientation : Rotate 90 CW

In Plone 4, when uploading this image to a CT with a field defined as:

foto = schema.Bytes( title=_(u"Foto personale"), required=False, description=_(u"Field description"), )

and displaying it in the template using foto_thumb, the image is correctly rotated according to the EXIF orientation:

In Plone 6, however, whether uploaded as a standalone Image CT or as an Image field within a CT, the image is not rotated, and this applies to all generated scales.

[jensens]

I retract my earlier analysis — the reporter is correct. I downloaded and analyzed the sample image:

• Raw pixels: 773x960 (portrait, person standing upright — verified by stripping EXIF and viewing)
• EXIF Orientation: 6 (rotate 90 CW)
• After Plone's rotate_image: 960x773 — person is now lying on their side (wrong!)

The EXIF tag is stale: the pixels are already in the correct orientation but Orientation is still set to 6. This is from a Samsung SM-G7102 phone. Plone blindly trusts the EXIF and rotates an already-correct image.

Unfortunately, PIL.ImageOps.exif_transpose() produces the exact same wrong result — it also trusts the EXIF tag. There is no reliable way to detect that pixels are "already rotated" when the EXIF says otherwise. The image metadata is simply inconsistent.

This is fundamentally a source-image problem (broken EXIF from the Samsung firmware), but it's common enough to warrant discussion. Possible approaches:

1. Do nothing — current behavior is correct per EXIF spec, blame the phone
2. Add an option to skip EXIF rotation — let site admins disable it
3. Strip EXIF Orientation on upload without rotating — just set it to 1, trust the pixels as-is

None of these are great. Option 1 is spec-correct but breaks real-world images. Option 3 would fix this Samsung case but break properly-formed images from other cameras.