Replace jimp with sharp

[burnhamrobertp]

Summary

Replace Jimp with sharp as the image processing library in spring-map-parser.

Why

Capability	Jimp	sharp
Resampling	Bilinear only	Lanczos3, Mitchell, cubic, etc.
Large images	Crashes on 10240×10240 JPEG (jpeg-js RangeError)	Handles any size via libvips streaming
Performance	Pure JS — slow encode/decode	Native libvips — 10-50× faster
Format support	JPEG, PNG, BMP, TIFF, GIF	+ WebP, AVIF, HEIF
Memory usage	Full RGBA buffer in JS heap	Streams tiles, constant memory
Alpha handling	Manual pixel manipulation	Built-in .removeAlpha(), .ensureAlpha()

Current Jimp usage in the parser

• 10×
  ew Jimp(width, height) — buffer construction
• 1× Jimp.read() — skybox DDS decode
• 2× Jimp.intToRGBA /
  gbaToInt — pixel color helpers
• All returned images are Jimp instances with .bitmap.data (raw RGBA Buffer)

All of these have direct sharp equivalents. The main API change is that sharp uses a pipeline pattern (sharp(input).resize().png().toBuffer()) rather than mutable bitmap objects.

Migration considerations

• Breaking change: Consumers currently receive Jimp objects. The return type would become sharp.Sharp or raw Buffer with metadata.
• Incremental path: Could first expose .bitmap.data raw buffers (already available on Jimp objects) as the public API, then swap internals to sharp. Downstream consumers like maps-metadata already bridge to sharp via raw buffers.
• Native dependency: sharp requires a native binary (pre-built for all major platforms via prebuild). This is standard for Node.js image processing but differs from Jimp's pure-JS approach.
• DDS decoding: Jimp.read() is used for skybox DDS files — would need a DDS decoder that outputs raw RGBA for sharp to consume (or keep a minimal DDS reader).

Related

• Replace jimp with sharp in map-parser cloud service maps-metadata#612 — sharp integration in the cloud service (incremental, doesn't require this)
• The cloud service can bridge Jimp→sharp today via raw bitmap data, but full replacement here would simplify the stack

[p2004a]

The one thing needed to consider is that we will want to use this lib in new-lobby, sharp uses native dependencies and those tend to be painful there. I hope it's solvable, just something to keep in mind.

[p2004a]

Overall though, to be clear: I'm supportive here, I've looked at it myself, just the native code dependency is what gave me a pause.

[burnhamrobertp]

I believe there is an easy path forward. For the same reasons you described, sharp maintainers built sharp-wasm. It shares the same api surface and typings as one another. Technically we could just use sharp-wasm alone but that would be leaving performance gains on the table at the expense of just one extra dependency and a few extra lines of code. Even for the new lobby, using both would allow those users whose OS would allow, to use sharp while still having sharp-wasm as a fallback.