What causes "Failed to get image loop count" in Intervention/image?

Call loops() on an image straight from $manager->read(); if that works, your earlier mutation corrupted the core

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

Failed to get image loop count

Error message

Failed to get image loop count

What it means

Thrown by Core::loops() when Imagick::getImageIterations() fails with an ImagickException. getImageIterations reads the GIF/WebP loop count; failing here means the native object cannot answer the question at all — destroyed, cleared, or holding frames without animation metadata in an unreadable state.

Source

Thrown at src/Drivers/Imagick/Core.php:359

            }
        }

        throw new InvalidArgumentException('Frame #' . $position . ' could not be found in the image');
    }

    /**
     * {@inheritdoc}
     *
     * @see CoreInterface::loops()
     *
     * @throws DriverException
     */
    public function loops(): int
    {
        try {
            return $this->imagick->getImageIterations();
        } catch (ImagickException $e) {
            throw new DriverException('Failed to get image loop count', previous: $e);
        }
    }

    /**
     * {@inheritdoc}
     *
     * @see CoreInterface::setLoops()
     *
     * @throws DriverException
     */
    public function setLoops(int $loops): CoreInterface
    {
        try {
            $this->imagick->resetIterator();
            $this->imagick->setImageIterations($loops);
        } catch (ImagickException $e) {
            throw new DriverException('Failed to set image loop count', previous: $e);
        }

View on GitHub (pinned to 5598b9e397)

Solutions

Call loops() on an image straight from $manager->read(); if that works, your earlier mutation corrupted the core
Re-read the source instead of continuing after any exception from slice/add
Check $e->getPrevious() for the native reason (usually 'unable to read iterations' style messages)

Defensive patterns

Strategy: try-catch

Try / catch

use Intervention\Image\Exceptions\DriverException;

try {
    $loops = $image->loops();
} catch (DriverException $e) {
    $loops = 0; // sensible default for a broken/unreadable animation state
}

Prevention

Read loop counts right after read(), before mutations
Treat loops() failures as a signal the core is corrupted — re-read the source
Default to 0 in consumers so a metadata hiccup does not crash rendering

When it happens

Trigger: Calling $image->loops() on the Imagick driver after the core's Imagick object was cleared/destroyed, or on a core assembled from frames whose container state is invalid (e.g. after a failed slice or add left a half-built stack).

Common situations: Reading loop counts after destructive operations threw earlier; images held across requests in long-lived workers while the resource was freed; cores built manually frame-by-frame without a coalesced base.

Related errors

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