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

Failed to apply {class}, unable to process resizing

Error message

Failed to apply {class}, unable to process resizing

What it means

resize() computes the target size via adjustedSize() and calls Imagick::scaleImage($w, $h) per frame; this driver wraps any ImagickException into a ModifierException with the original chained. Unlike the other modifiers there is no false-return check here because scaleImage failures surface as exceptions. The dominant native causes are 'Invalid image geometry' when the computed target has a zero dimension and policy/memory errors when the target is huge.

Source

Thrown at src/Drivers/Imagick/Modifiers/ResizeModifier.php:30

use Intervention\Image\Modifiers\ResizeModifier as GenericResizeModifier;

class ResizeModifier extends GenericResizeModifier implements SpecializedInterface
{
    /**
     * @throws ModifierException
     */
    public function apply(ImageInterface $image): ImageInterface
    {
        $resizeTo = $this->adjustedSize($image);

        foreach ($image as $frame) {
            try {
                $frame->native()->scaleImage(
                    $resizeTo->width(),
                    $resizeTo->height(),
                );
            } catch (ImagickException $e) {
                throw new ModifierException(
                    'Failed to apply ' . self::class . ', unable to process resizing',
                    previous: $e,
                );
            }
        }

        return $image;
    }

    protected function adjustedSize(ImageInterface $image): SizeInterface
    {
        return $image->size()->resize($this->width, $this->height);
    }
}

View on GitHub (pinned to 5598b9e397)

Solutions

  1. Validate dimensions before resizing: both target dimensions must be >= 1 after computation
  2. Check $e->getPrevious()?->getMessage(): 'Invalid image geometry' -> zero dimension, 'exceeds limit' -> policy.xml, memory wording -> raise limits
  3. Raise policy.xml width/height/area limits or memory_limit if legitimate large outputs are intended
  4. Downscale (or cap) user-supplied sizes at the request boundary so targets stay inside your resource envelope

Example fix

// before
$image->resize($request->integer('w'), $request->integer('h')); // 0s pass through

// after
$w = max(1, min(4096, $request->integer('w', 100)));
$h = max(1, min(4096, $request->integer('h', 100)));
$image->resize($w, $h);
Defensive patterns

Strategy: try-catch

Validate before calling

$w = (int) $request->integer('w', 0);
$h = (int) $request->integer('h', 0);
if ($w < 1 && $h < 1) {
    throw new \InvalidArgumentException('Resize needs at least one positive dimension');
}
if ($w !== 0) { $w = max(1, min(8192, $w)); }
if ($h !== 0) { $h = max(1, min(8192, $h)); }
$image->resize($w, $h);

Try / catch

use Intervention\Image\Exceptions\ModifierException;

try {
    $image->resize($w, $h);
} catch (ModifierException $e) {
    $msg = $e->getPrevious()?->getMessage() ?? '';
    if (str_contains($msg, 'geometry')) {
        // zero target dimension: recompute with positive fallbacks
    } elseif (str_contains($msg, 'limit')) {
        // policy cap: clamp target size and retry
    } else {
        throw $e;
    }
}

Prevention

When it happens

Trigger: $image->resize(0, 0) or computing a size that collapses to 0 (e.g. Fraction/percentage math on tiny images); $image->resize(20000, 20000) upscaling beyond policy.xml width/height/area caps; memory exhaustion scaling a large frame up.

Common situations: Thumbnail code passing user-controlled width/height that can be 0; shared hosts capping ImageMagick area so big upscales are denied; Percentage/Fraction-based resizes on 1px images rounding to 0.

Related errors


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