Ensure HEIF "primary item" is rendered as the default frame/page

[RunDevelopment]

Possible bug

Large AVIF files are not decoded (=loaded) in full. Only a portion is loaded.

E.g. test w10240.avif (see sample files below) is a 10240x2000px image, but loaded as a 1280x1000px image. The portion of the image that is loaded is the most top left portion.

Here's how all my test images are loaded:

File	Correct size	sharp size	Matches?
test w4095.avif	4095x800	4095x800	Yes
test w4096.avif	4096x800	1024x800	No
test w4097.avif	4097x800	4097x800	Yes
test w4098.avif	4098x800	1366x800	No
test w10240.avif	4096x2000	1280x1000	No

Here is the full metadata object of test w10240.avif:

Metadata: {
  format: 'heif',
  width: 1280,
  height: 1000,
  space: 'srgb',
  channels: 3,
  depth: 'uchar',
  isProgressive: false,
  isPalette: false,
  bitsPerSample: 8,
  pages: 17,
  pagePrimary: 16,
  compression: 'av1',
  hasProfile: false,
  hasAlpha: false,
  autoOrient: { width: 1280, height: 1000 }
}

Note the 17 pages. AVIF supports grid images, where the image is split into tiles and then reassembled by the decoder. test w10240.avif consists of an 8x2 grid and sharp only reads one of those tiles.

This can be seen clearly when opening the file with Gimp:

It shows 16 tiles + one primary.

Note: All of the provided sample images are correctly displayed by Windows Image Viewer, Paint.net, Google Chrome, Gimp, and Adobe Photoshop. FireFox reports an error due to a bug. All samples images were generated by Paint.net.

Is this a possible bug in a feature of sharp, unrelated to installation?

• Running npm install sharp completes without error.
• Running node -e "require('sharp')" completes without error.

Are you using the latest version of sharp?

• I am using the latest version of sharp as reported by npm view sharp dist-tags.latest.

What is the output of running npx envinfo --binaries --system --npmPackages=sharp --npmGlobalPackages=sharp?

  System:
    OS: Windows 10 10.0.19045
    CPU: (12) x64 Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz
    Memory: 20.59 GB / 31.93 GB
  Binaries:
    Node: 25.2.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.22 - C:\Users\micha\AppData\Roaming\npm\yarn.CMD
    npm: 9.9.3 - C:\Program Files\nodejs\npm.CMD
    pnpm: 6.6.2 - C:\Users\micha\AppData\Roaming\npm\pnpm.CMD
    Deno: 1.34.1 - C:\ProgramData\chocolatey\lib\deno\deno.EXE
  npmPackages:
    sharp: ^0.34.5 => 0.34.5

Does this problem relate to file caching?

The default behaviour of libvips is to cache input files, which can lead to EBUSY or EPERM errors on Windows.
Use sharp.cache(false) to switch this feature off.

• Adding sharp.cache(false) does not fix this problem.

Does this problem relate to images appearing to have been rotated by 90 degrees?

No.

• Using rotate() or keepExif() does not fix this problem.

What are the steps to reproduce?

Load any of my attatched sample images and either print their metadata or save them in another format.

What is the expected behaviour?

The image should be loaded in full, but only the most top left portion of it is loaded.

Please provide a minimal, standalone code sample, without other dependencies, that demonstrates this problem

import sharp from "sharp";
const img = await sharp("test w10240.avif");
// console.log("Metadata:", await img.metadata());
await img.png().toFile("out.png");

Please provide sample image(s) that help explain this problem

sample images.zip

[lovell]

This appears to relate to multi-frame AVIF images where the "primary item" (the pitm box) is not the first frame.

const input = "test w10240.avif";
const { pagePrimary } = await sharp(input).metadata();

await sharp(input).toFile("default.png");
await sharp(input, { page: pagePrimary }).toFile("primary.png");

$ file *.png
default.png: PNG image data, 1280 x 1000, 8-bit/color RGB, non-interlaced
primary.png: PNG image data, 10240 x 2000, 8-bit/color RGB, non-interlaced

For HEIF input, we should probably default to the primary page when none is specified.