What causes "Failed to retrieve image format" in Intervention/image?

Inspect the chained native error: catch ImageDecoderException and read $e->getPrevious()?->getMessage() for the true ImageMagick reason

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

Failed to retrieve image format

Error message

Failed to retrieve image format

What it means

After Imagick::readImage() succeeded, Imagick::getImageFormat() threw. This is an unusual mid-decode state: ImageMagick opened the container but the resulting Imagick object exposes no image format. Unlike the sibling error at line 55, the native exception is preserved as previous, so the real ImageMagick reason is recoverable via getPrevious().

Source

Thrown at src/Drivers/Imagick/Decoders/FilePathImageDecoder.php:63

     */
    public function decode(mixed $input): ImageInterface
    {
        // make sure path is valid
        $path = self::readableFilePathOrFail($input);

        try {
            $imagick = new Imagick();
            $imagick->readImage($path);
        } catch (ImagickException) {
            throw new ImageDecoderException(
                'Failed to decode image data from file "' . $path . '"',
            );
        }

        try {
            $originalFormat = $imagick->getImageFormat();
        } catch (ImagickException $e) {
            throw new ImageDecoderException('Failed to retrieve image format', previous: $e);
        }

        // decode image
        $image = parent::decode($imagick);

        // set file path on origin
        $image->origin()->setFilePath($path);

        // extract exif data for the appropriate formats
        if (in_array($originalFormat, ['JPEG', 'TIFF', 'TIF'])) {
            $image->setExif($this->extractExifData($path));
        }

        return $image;
    }
}

View on GitHub (pinned to 5598b9e397)

Solutions

Inspect the chained native error: catch ImageDecoderException and read $e->getPrevious()?->getMessage() for the true ImageMagick reason
Run `identify -verbose file` on the command line to see whether ImageMagick itself can enumerate a format
Re-save the file externally in a baseline format (convert in.tif out.png) and read that instead
If the previous exception indicates an internal ImageMagick bug, upgrade ImageMagick/imagick

Example fix

// before
$image = $manager->read('truncated.tif');

// after: surface the native ImageMagick reason
try {
    $image = $manager->read('truncated.tif');
} catch (ImageDecoderException $e) {
    $reason = $e->getPrevious()?->getMessage() ?? 'no native reason';
    $logger->warning('Format lookup failed: ' . $reason);
    throw $e;
}

Defensive patterns

Strategy: try-catch

Try / catch

try {
    $image = $manager->read($path);
} catch (\Intervention\Image\Exceptions\ImageDecoderException $e) {
    $native = $e->getPrevious()?->getMessage() ?? 'unknown';
    $logger->warning('ImageMagick format lookup failed: ' . $native);
    throw $e;
}

Prevention

Always log getPrevious() - this error chains the native ImageMagick reason
Smoke-test exotic formats with `identify` before adding them to accepted upload types

When it happens

Trigger: Reading a file whose header parses but whose image list ends up empty or unreadable: truncated progressive JPEG, multi-page container where inner coders are policy-blocked, some RAW/DNG variants where only the container coder exists.

Common situations: Truncated multi-page TIFFs in document pipelines; partially-written files from a crashed producer; exotic formats on minimal ImageMagick builds.

Related errors

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