sharp icon indicating copy to clipboard operation
sharp copied to clipboard

scaleFactor missing in info.json of IIIF output

Open sammeltassen opened this issue 11 months ago • 2 comments

Possible bug

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

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

If you cannot confirm both of these, please open an installation issue instead.

Are you using the latest version of sharp?

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

If you cannot confirm this, please upgrade to the latest version and try again before opening an issue.

If you are using another package which depends on a version of sharp that is not the latest, please open an issue against that package instead.

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

System: OS: macOS 15.3.2 CPU: (8) arm64 Apple M1 Pro Memory: 116.59 MB / 16.00 GB Shell: 5.9 - /bin/zsh Binaries: Node: 20.8.0 - ~/.nvm/versions/node/v20.8.0/bin/node Yarn: 1.22.21 - ~/.nvm/versions/node/v20.8.0/bin/yarn npm: 10.1.0 - ~/.nvm/versions/node/v20.8.0/bin/npm pnpm: 8.10.0 - ~/.nvm/versions/node/v20.8.0/bin/pnpm bun: 1.2.5 - ~/.bun/bin/bun npmPackages: sharp: ^0.33.5 => 0.33.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.

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

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

Images that contain EXIF Orientation metadata are not auto-oriented. By default, EXIF metadata is removed.

  • To auto-orient pixel values use the parameter-less rotate() operation.

  • To retain EXIF Orientation use keepExif().

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

What are the steps to reproduce?

Tile an image using the iiif or iiif3 layout.

What is the expected behaviour?

The info.json file contains a property tiles with an array of available tile sets, in this case only one. The scaleFactor property of the first object contains an array of available scale factors, in powers of two. In this array, the top of the tile pyramid, or the largest factor, is missing.

Take this info.json generated with sharp: https://github.com/amsterdamtimemachine/berckenrode-iiif/blob/main/KZL_W_X_020/info.json

This is the top tile of the outputted tile set: https://amsterdamtimemachine.github.io/berckenrode-iiif/KZL_W_X_020/0,0,39125,34708/612,/0/default.jpg

It has a width of 612 pixels which is a scale factor of 64 (Math.ceil(39125/64)).

However this scale factor is missing from the info.json:

{
  "scaleFactors": [1, 2, 4, 8, 16, 32],
}

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

Here's the script I use for tiling images with sharp.

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

This Observable Notebook visualizes the tile pyramid and helped me find the upper tile

sammeltassen avatar Mar 13 '25 17:03 sammeltassen

Thanks for reporting, I can reproduce. This looks like something that we'll need to fix upstream in libvips - I've opened a possible PR at https://github.com/libvips/libvips/pull/4421

lovell avatar Mar 17 '25 14:03 lovell

sharp v0.34.3 is now available with prebuilt binaries that include the upstream fix to libvips.

lovell avatar Jul 10 '25 08:07 lovell