Contrib.social

The module doesn't work with Imagick toolkit

Open on Drupal.org →
Created on 17 July 2017, almost 7 years ago
Updated 13 March 2024, 4 months ago

Tried to use the module with Imagick toolkit (and Image Widget Crop - not sure if it's relevant), discovered that the image is rotated multiple times before it is finally stored (in the original image the building was lying on its left side, when uploaded to site it was lying on its right side).
Discovered two reasons for that:
1. The module uses hook_file_presave (as opposed to hook_file_insert), so the image is processed every time it is [re]saved for whatever reason. In my configuration it was apparently saved two times.
2. As Imagick toolkit doesn't strip the EXIF (unlike GD) and the rotate() operation doesn't reset the Orientation flag in the EXIF, the image will be rotated as many times as it is saved.
Solution:
1. If using Imagick toolkit, use its "autorotate" operaton instead of generic rotate(). In that case you don't need to call exif_read_data() to determine whether the image needs rotating and how many degrees - the toolkit will do it automagically AND it will reset the Orientation flag in the EXIF so that the image won't be autorotated ever again.
2. Use hook_file_insert instead of hook_file_presave. With (1) implemented the image will not be rotated twice anyway, but why call the toolkit many times when it should only be called once.
Here's the code I wound up with for my particular case:

/**
 * Implements hook_file_insert().
 * Rotates an image to its EXIF Orientation.
 * ONLY WORKS WITH IMAGICK TOOLKIT!
 */
function HOOK_file_insert(EntityInterface $file) {
  if ($file->getMimeType() == 'image/jpeg') {
    $image = \Drupal::service('image.factory')->get($file->getFileUri());
    if ($image->getToolkit()->apply("autorotate")) {
      $image->save();
    }
  }
}

Hope this helps someone. Maybe someone will be willing to make a patch that would query the toolkit used and use different code for different toolkits - I'm a bit out of my depth here.

🐛 Bug report
Status

Active

Version

1.0

Component

Code

Created by

🇷🇺Russia marassa Moscow

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment about 1 year ago →
    solideogloria
  • Comment 8 months ago →
    ivnish Poland

    Same problem. I use imagemagick and the module rotating images twice:

    1. When image added to form image widget
    2. When node presave

    When I use -strip I have wrong rotation because I also have file_validate_image_resolution

    I added

    // Remove EXIF.

    $img = new Imagick($path);
$img->stripImage();
$img->writeImage($path);

    after

    $image->save();

    And now it works fine for me

  • Comment 8 months ago →
    ivnish Poland

    $image->getToolkit()->apply("autorotate")

    doesn't work for me (function return FALSE)

  • Comment 8 months ago →
    ivnish Poland

    Topicstarter helps me in private messages. I installed imagemagick → module, but $image->getToolkit()->apply doesn't work. Needs to install imagick → module instead

    If you need to strip exif you can add code after autorotate

    if ($image->getToolkit()->apply("strip")) {
  $image->save();
}
  • Comment 4 months ago →
    🇺🇸United States chucksimply

    -strip was the reason why images weren't being rotated correctly. Removed it, now working as it should. Drupal 10.2

  • Comment 4 months ago →
    🇺🇸United States SocialNicheGuru

    @chucksimply is there a patch?

  • Comment 4 months ago →
    🇺🇸United States chucksimply

    So it's not 100% solved. I originally had the -strip option under the Prepend arguments on the Image Toolkit page. Orientation remained incorrect.

    I then removed the -strip option, and now all my image styles that convert to WEBP have the correct orientation. But without the convert, they still are incorrect.

    This isn't really a solution, and I'm not sure what's going on. Still confused.

  • Comment 4 months ago →
    🇺🇸United States chucksimply

    Circling back on this issue... found a resolution.

    This issue here 🐛 Orientation is no longer fixed if a maximum image resolution is set on the field RTBC fixes an issue where EXIF data was removed if Max Image Size constraints were defined and executed for an image upload.

    Solution:
    - Apply the patch from the related issue
    - Add -strip to Execution > Prepend arguments, just like in comments #5, #6, #7.

    Now ImageMagick and this module work as expected.

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024