What causes "Failed to apply {class}, unable to process rotation" in Intervention/image?

Log $e->getPrevious()?->getMessage(); match on 'MemoryCache'/'not authorized' to pick the fix

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

Failed to apply {class}, unable to process rotation

Error message

Failed to apply {class}, unable to process rotation

What it means

During orient(), one of the native calls matched to the EXIF orientation value threw an ImagickException (rotateImage('#000', 90/180/270) and/or flopImage(), or the final setImageOrientation()), and the driver wraps it with previous preserved. The generic 'unable to process rotation' message hides the real reason, which is in the chained ImagickException. This branch is the typical one on modern ImageMagick builds because they throw rather than return false.

Source

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

                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)

Solutions

Log $e->getPrevious()?->getMessage(); match on 'MemoryCache'/'not authorized' to pick the fix
Increase memory_limit or MAGICK_MEMORY_LIMIT / resource area in policy.xml for the rotated frame
Downscale before orient() if the source is a 12MP+ photo and full size is not needed
Verify the upload is complete (Content-Length vs actual bytes) since truncated files fail at operation time, not decode time

Example fix

// before
$image->orient();

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

try {
    $image->orient();
} catch (ModifierException $e) {
    if (str_contains($e->getPrevious()?->getMessage() ?? '', 'memory')) {
        ini_set('memory_limit', '512M');
        $image->orient(); // retry once with more memory
    } else {
        throw $e;
    }
}

Defensive patterns

Strategy: try-catch

Try / catch

use Intervention\Image\Exceptions\ModifierException;

try {
    $image->orient();
} catch (ModifierException $e) {
    $msg = $e->getPrevious()?->getMessage() ?? '';
    if (str_contains($msg, 'memory') || str_contains($msg, 'cache')) {
        // retry with more headroom or a smaller decode
    } else {
        throw $e;
    }
}

Prevention

Phone photos with orientation tags 5-8 trigger both a rotate and a flop; budget memory for a full frame copy
Watch for EXIF orientation on HEIC/AVIF-derived JPEGs; their large frames stress the same code path
Wrap orient() separately from other modifications so one failure does not discard the whole edit chain

When it happens

Trigger: $image->orient() on a photo with EXIF orientation 3/6/8 (180/90/270 rotation) where rotateImage throws: cache/resources exhausted, 'not authorized' policy error, or corrupted frame data from a partially downloaded upload.

Common situations: Upload pipelines auto-orienting phone photos under low memory_limit; Docker images based on distro packages with hardened policy.xml; animated files where orient() rotates the whole Imagick object frame list.

Related errors

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