Sharp: resize width is limited to 16383

[stephanebachelier]

I need to resize an image to 16384*16384 with is 2^14 but sharp maximum width is set to 0x3FFF = 16383.

Have you an idea why this limit and if I can override it.

[lovell]

Hi Stéphane, the <=16383 limit is due to the lowest common denominator of WebP storing each dimension in 14 bits.

To increase this we'd need to switch from a generic hard limit applied to all formats to instead use per-format limits, e.g. JPEG uses 16 bits, so <= 65535.

At the moment the output format isn't worked out until near the end of the processing pipeline, so this logic should probably move nearer to the start and then have per-format limits applied.

[stephanebachelier]

@lovell thanks for your explanations.
This means that I could not have a JPEG larger than 65535, which is huge I know but when working on map tiles you can have really large images.

You might help and tell me what strategy is the best between in a memory point of view:

• resizing down a really large image to e.g. 2^17 (131072) and then extract some part which are resized to 256 px
• or extract a part and resize.

[lovell]

Support for Deep Zoom tile output is imminent (I'll be merging #146 today). Might this help?

[stephanebachelier]

@lovell not sure. I don't know about Deep Zoom and when reading comments in #146 it seems a deep understanding of libvips is needed.

[lovell]

Sorry, the discussion on that PR quickly became quite detailed. The API it adds will (hopefully) be simple.

"when working on map tiles you can have really large images"

If you need to generate map tiles, once the new code is merged you should be able to do something as simple as sharp(largeInput).tile(256).toFile('output.dzi') to generate a "pyramid" of 256x256 JPEG tiles at intermediate /2 zoom levels. This might remove the need to manually resize and extract for your use case.

[stephanebachelier]

@lovell read the diff was easier to understand the change :)

I didn't know about openslide nor deep zoom and I think #146 might help me.

[lovell]

Experimental support for tiled output is now available on the judgement branch:

npm install lovell/sharp#judgement

You'll need to ensure libvips was compiled with support for Deep Zoom (vips installed via homebrew does this already; for Linux install libgsf-1-dev first).

[stephanebachelier]

@lovell great! I'll test it.
I've already upgraded libvips after reading through #146 patch.

[lovell]

@stephanebachelier Do you still require an increase to the minimum width or were you able to use the Deep Zoom tile feature for your map use case?

[stephanebachelier]

@lovell no the deep zoom tile did not work for me. But I tested it 3 months ago.
Need to test on the new version.

[lovell]

Given all the possible combinations of resizing, extraction, rotation etc. operations the final output image dimensions won't be known until the end of the pipeline.

What I propose is to have a per-format check just before writing to the output image, with those limits being:

• WebP: 16383 x 16383 (14-bit unsigned)
• JPEG/TIFF: 65535 x 65535 (16-bit unsigned)
• PNG: 2147483647 x 2147483647 (32-bit signed)

[lovell]

Commit 2f534dc on the ridge branch removes the hard-coded 2^14 output limit, replacing it with the relevant per-format limit. This will be in v0.18.0

[lovell]

v0.18.0 now available.