Intervention/image · error · Intervention\Image\Exceptions\ModifierException

Failed to apply , unable to process rotation of image

Error message

Failed to apply {class}, unable to process rotation of image

What it means

orient() reads the frame's EXIF orientation (falling back to the originalImageOrientation metadata when Imagick reports ORIENTATION_UNDEFINED), then applies a flop/rotate combination for tags 2-8. This exception fires when one of those native calls (flopImage, rotateImage, or the trailing setImageOrientation(ORIENTATION_TOPLE)) returns false, leaving $result false. Orientations 1/undefined hit the 'default' arm, which returns a truthy string, so normal upright images never reach this throw.

Solutions

Read $e->getPrevious()?->getMessage() to see which native op refused and why
Check /etc/ImageMagick-*/policy.xml for denied rotate/flop operations and allow them if you administer the host
Raise PHP memory_limit for large photos since rotation of 90/270 tags reallocates the frame
Strip the orientation beforehand as a workaround: re-encode via ImageMagick CLI ('convert -auto-orient') and re-ingest the file

Example fix

// before
$image->orient();

// after
use Intervention\Image\Exceptions\ModifierException;

try {
    $image->orient();
} catch (ModifierException $e) {
    $logger->warning('Auto-orient failed, serving unrotated image', [
        'reason' => $e->getPrevious()?->getMessage(),
    ]); // orientation stays as-is, image is still usable
}

Defensive patterns

Strategy: try-catch

Try / catch

use Intervention\Image\Exceptions\ModifierException;

try {
    $image->orient();
} catch (ModifierException $e) {
    $logger->warning('Auto-orient failed; using unrotated frame', [
        'reason' => $e->getPrevious()?->getMessage(),
    ]); // image remains usable, just not physically rotated

Prevention

Treat orient() as best-effort for user content; a failed orient should degrade, not abort, the pipeline
On policy-restricted hosts, pre-orient with 'convert -auto-orient' at upload time instead
Load big photos at reduced size first (e.g. via decode options) when orientation is all you need to fix

When it happens

Trigger: $image->orient() on an image whose EXIF orientation is 2-8 (mirrored/rotated phone photos) while the underlying flopImage()/rotateImage()/setImageOrientation() returns false, e.g. policy-restricted operations or an exhausted pixel cache.

Common situations: Processing smartphone JPEGs/HEIC-to-JPEG exports that carry orientation tags on a server whose ImageMagick policy.xml is tightened; large portrait photos rotated 90/270 degrees where rotation reallocates the full frame.

Related errors

AI-assisted analysis of Intervention/image@5598b9e397 (2026-08-23). Data as JSON: /api/errors/b87605961f1abd58. Report an issue: GitHub.

Appendix: source

Thrown at src/Drivers/Imagick/Modifiers/OrientModifier.php:56

                => $image->core()->native()->rotateImage('#000', 90) && $image->core()->native()->flopImage(), // 5

                Imagick::ORIENTATION_RIGHTTOP
                => $image->core()->native()->rotateImage('#000', 90), // 6

                Imagick::ORIENTATION_RIGHTBOTTOM
                => $image->core()->native()->rotateImage('#000', 270) && $image->core()->native()->flopImage(), // 7

                Imagick::ORIENTATION_LEFTBOTTOM
                => $image->core()->native()->rotateImage('#000', 270), // 8

                default => 'value',
            };

            // set new orientation in image
            $result = $result && $image->core()->native()->setImageOrientation(Imagick::ORIENTATION_TOPLEFT);

            if ($result === false) {
                throw new ModifierException(
                    'Failed to apply ' . self::class . ', unable to process rotation of image',
                );
            }
        } catch (ImagickException $e) {
            throw new ModifierException(
                'Failed to apply ' . self::class . ', unable to process rotation',
                previous: $e,
            );
        }

        return $image;
    }
}

View on GitHub (pinned to 5598b9e397)