Intervention/image · error · ModifierException

Failed to apply Intervention\Image\Drivers\Imagick\Modifiers

Error message

Failed to apply Intervention\Image\Drivers\Imagick\Modifiers\BlurModifier, unable to blur image

What it means

Thrown by the Imagick BlurModifier when Imagick::blurImage() returns false instead of throwing, i.e. ImageMagick reports failure through its return code. It surfaces from $image->blur($level) and wraps a ModifierException with no previous exception, since the native API only said 'false'. The modifier runs per frame, so animated images fail on the first bad frame.

Source

Thrown at src/Drivers/Imagick/Modifiers/BlurModifier.php:24

use ImagickException;
use Intervention\Image\Exceptions\ModifierException;
use Intervention\Image\Interfaces\ImageInterface;
use Intervention\Image\Interfaces\SpecializedInterface;
use Intervention\Image\Modifiers\BlurModifier as GenericBlurModifier;

class BlurModifier extends GenericBlurModifier implements SpecializedInterface
{
    /**
     * @throws ModifierException
     */
    public function apply(ImageInterface $image): ImageInterface
    {
        foreach ($image as $frame) {
            try {
                $result = $frame->native()->blurImage($this->level, 0.5 * $this->level);
                if ($result === false) {
                    throw new ModifierException(
                        'Failed to apply ' . self::class . ', unable to blur image',
                    );
                }
            } catch (ImagickException $e) {
                throw new ModifierException(
                    'Failed to apply ' . self::class . ', unable to blur image',
                    previous: $e,
                );
            }
        }

        return $image;
    }
}

View on GitHub (pinned to 5598b9e397)

Solutions

  1. Check image dimensions and raise ImageMagick resource limits (policy.xml or Imagick::setResourceLimit) — large blurs are memory-heavy.
  2. Convert the image to RGB before blurring: $image = $manager->read($path); consider colorspace conversion first if the source is CMYK/16-bit.
  3. Reproduce with the CLI (convert input.png -blur 0x5 /dev/null) to confirm it is an ImageMagick environment issue, then fix the install (delegates, version).
  4. Fall back to the GD driver if the environment cannot be repaired: new ImageManager(new Driver()) with Intervention\Image\Drivers\Gd\Driver.

Example fix

// before
$image->blur(15); // ModifierException on resource-starved host

// after
\Imagick::setResourceLimit(\Imagick::RESOURCETYPE_MEMORY, 256 * 1024 * 1024);
\Imagick::setResourceLimit(\Imagick::RESOURCETYPE_AREA, 256 * 1024 * 1024);
$image->blur(15);
Defensive patterns

Strategy: fallback

Validate before calling

// pre-flight: confirm the operation is feasible on this environment
$probe = new \Imagick();
$probe->newImage(4, 4, new \ImagickPixel('red'));
$blurOk = $probe->blurImage(2, 1) !== false;
$probe->destroy();

Try / catch

use Intervention\Image\Exceptions\ModifierException;
try {
    $image->blur(12);
} catch (ModifierException $e) {
    // fallback: retry once on a downscaled copy, or route to the GD driver
    $image = $manager->read($source)->scaleDown(1200, 1200)->blur(12);
}

Prevention

When it happens

Trigger: Calling $image->blur() when the ImageMagick install cannot execute the Gaussian blur for this image state (degraded wand, unsupported colorspace for the operation, exhausted resources). Level is already validated as >= 0 by the generic constructor, so the failure is environmental, not argument-related.

Common situations: ImageMagick resource limits (area/memory policy.xml caps) hit on large images; CMYK or 16-bit images on old ImageMagick versions whose blur path fails; container images built without proper ImageMagick delegates; intermittent failures in high-throughput workers under memory pressure.

Related errors


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