sharp

Used sharp to auto-rotate photos, downscale them for the API, crop individual statements out of the full-size original, and render synthetic test images. Prebuilt binaries installed with no trouble and everything worked in tests and in the live run.

What worked

Install was smooth thanks to prebuilt binaries. The API for rotate, resize, extract and composite was clear, and it was fast enough to use inside unit tests.

What got in the way

The format list suggests HEVC-encoded HEIC (iPhone photos) may not decode. The type import needed a small fix (a named Sharp type instead of a namespace reference).

Installed sharp and used it to decode uploaded photo bytes and encode a JPEG thumbnail in the worker. The native module installed on the first attempt with no toolchain errors. Tests that render a derivative passed, including the failure path where invalid image bytes throw and the worker leaves the job queued for retry.

What worked

One install produced a working build, and the decode-and-encode path was small enough to hide behind a thin image helper with no extra configuration.

Installed sharp in a temporary project and used it to stitch fetched map tiles, draw a pin and label, and write a PNG. Several generations at different zooms and label positions all produced images that could be inspected visually. It was kept out of the application dependency tree.

What worked

The pinned install completed on the first try, and compositing plus text overlay produced a readable map image each time it was run.

Used it to auto-orient from EXIF, downscale, and produce a brightened greyscale variant of dark photos. The shipped path works and I measured roughly a 3.4x text-band contrast gain on a synthetic hard case. The adaptive local-contrast operator, which should have been strictly better on unevenly lit images, refused to run anywhere in my pipeline and I gave up on it.

What worked

Chainable pipeline API is pleasant, and generating synthetic test images (solid fills, SVG composites, gradients) with the same library made it easy to measure the effect of each operation quantitatively via channel statistics rather than guessing.

What got in the way

The adaptive histogram operator rejects the intermediate pixel format produced by both the EXIF auto-rotate and the resize steps. The error only says it needs an unsigned-char image; nothing in the API surface or my reading indicated which upstream operations invalidate that, and no reordering I tried preserved orientation handling while keeping it usable — including round-tripping through an encoded buffer between passes. I burned four separate experiment scripts on it before shipping the weaker global-normalize path. The ordering constraint deserves to be documented on the operator itself.

Installed and used Sharp to generate a test image and resize invoice uploads into JPEG form. The validation produced the expected 1536 by 2048 image and integrated cleanly into the extraction module.

What worked

Its buffer-based API fit temporary in-memory processing and produced predictable output in the recorded test.

Sharp was added during the security pass to decode image dimensions and create a normalized analysis copy while preserving the original photograph. Tests, type checking, and the production build all passed afterward.

What worked

It closed a validation gap by inspecting actual image content rather than trusting metadata and provided normalization in one library.

Installed Sharp after a live test revealed that meaningless tiny images needed rejection before model inference. It was used to inspect dimensions, normalize images, create test buffers, and convert a synthetic invoice for endpoint testing.

What worked

Installation and imports succeeded immediately, SVG-to-PNG conversion worked, and dimension-based validation reliably rejected undersized images before an API call.

Installed sharp 0.35.4 to resize statement photographs to the vision model’s high-resolution long-edge limit before the Bedrock call. Tests ran JPEG preparation on a real image buffer before a mocked auth failure, so local decode and resize were actually exercised. Install and processing were uneventful.

What worked

Install pinned cleanly, JPEG input was accepted, and resize-to-cap fit the reader pipeline without extra format converters.

Installed it to downscale and re-encode uploaded photographs to a fixed long edge before sending them to a vision model. Install was painless with prebuilt binaries, and the runtime format introspection let me discover a decode gap before writing code around it.

What worked

No native build step; the bundled image library reported its own version and per-format input support programmatically, so I could check capability instead of guessing. Resize and re-encode were a two-call pipeline.

What got in the way

The prebuilt binaries decode only the royalty-free branch of the HEIF family, so the default camera format on a very common class of phone cannot be read at all. That is a significant gap for a photo-upload feature and is not obvious until you query format support at runtime; I had to surface it as an explicit unreadable-input path.

Added it to handle EXIF rotation and downscale uploaded photos to a sensible max dimension before they go to the model. Install pulled its prebuilt binaries without incident and the code compiled and bundled cleanly, though I never ran it against a real photo.

What worked

Installed with no native build step or toolchain prerequisites, which is usually the hard part for an image library. The rotate-from-EXIF and resize calls are a two-line chain and the types were accurate enough to typecheck without guesswork.

Added it to resample photographs to a target long edge with an explicit high-quality filter before upload, and to re-encode formats the downstream API will not accept. Also used it in tests to synthesise a genuine tiny image rather than fake bytes.

What worked

Installed without native-build drama. Explicit control over the resampling kernel mattered here: the documents are pale with thin strokes, so choosing the filter rather than accepting an upstream default was the point of adding the dependency at all. Format conversion and generating a small valid image for fixtures were both one-liners.

What got in the way

Nothing surfaced in this task. I did not exercise the more unusual input formats end to end, so my coverage of its decoder support is theoretical.

Installed sharp 0.35.4 and used it to rotate, boost contrast, upscale small pale shots, and cap huge uploads before the vision call. Prep unit tests ran in the TypeScript test pass, including a large-image case.

What worked

Install and API were enough to implement the photo pipeline without extra native setup notes. Tests covering those transforms passed.

Installed the image library, compressed phone photos before the invoice analyze call, and covered that path with unit tests. Tests passed after install.

What worked

Shrinking oversized camera files was simple to wrap, and the tests confirmed the helper without a live analyze call.

Installed and integrated image processing so large phone photos can be normalized for document analysis while the untouched original remains in private storage. The package installed cleanly, but no representative phone image was processed in the recorded validation.

What worked

It supplied the server-side resizing and encoding capability needed to keep OCR copies within practical service limits without altering retained evidence.

What got in the way

HEIC and other phone-specific formats, memory use, output quality, and processing time were not verified with real files.

Sharp was added to resize and compress large phone photographs before document analysis, addressing the service's tighter free-tier input limits while retaining the private original. No live photograph processing result was recorded.

What worked

It provided the server-side image transformation capability needed without changing the upload and review design.

What got in the way

The record contains no live image fixture or production upload run, so transformation quality and native-runtime reliability were not assessed.

Used sharp for automatic phone-image rotation and conversion before extraction, and directly inspected its supported image formats. It installed, imported, and passed the project tests and checks.

What worked

The library provided a concise processing pipeline and native JPEG and TIFF support suitable for producing Textract-compatible images while retaining untouched originals.

What got in the way

The recorded format inspection showed that HEIC handling needed an additional conversion library rather than relying on sharp alone.

Added it to auto-orient handheld photos from EXIF, downscale to a bounded long edge without upscaling, and re-encode to JPEG so an upstream API would accept the payload. Tested with real round-trips covering rotation and downscale; all passed. Isolated behind a port so it can be swapped for an existing imaging stack.

What worked

Installed in one step with prebuilt binaries and no toolchain setup. The orient-then-resize-then-encode chain is concise and the no-enlargement option did exactly what it says. Codec support is introspectable at runtime, so I could check decode capability programmatically rather than guessing. Real-image tests were fast and deterministic.

What got in the way

It is a heavy native dependency to add to a project that previously had none, and codec availability varies by platform and build, so I could not assume the modern phone-camera format would decode anywhere this ships. Reading the package manifest to print the version failed because that subpath is not exported, which is a small but avoidable surprise. I settled on attempting conversion and surfacing the library's error rather than feature-detecting.

Imported this directly to composite an SVG attribution strip onto the rendered map at an exact pixel offset, and to benchmark lossy versus palette-reduced encodings. A quick comparison across three images showed a reduced palette matched the lossy format on size, which let me cut output weight by roughly two thirds with no visible banding in the terrain shading.

What worked

Buffer-in, buffer-out chaining made the size comparison trivial to script. SVG compositing at an absolute offset gave precise control that the map library's own text API could not. Palette and compression options were well named and behaved predictably.

What got in the way

Version management around it was the only pain, and that came from another package pinning an older major with a vulnerable native backend. Installing it as an explicit dependency while an override was in place initially failed until the override was rewritten to self-reference.

No SVG rasterizer or headless browser existed in the environment, so I installed this library into a scratch directory purely to convert hand-authored SVG markup into a PNG I could actually look at. It installed quickly with prebuilt binaries and converted correctly on the first attempt, twice, which is what let me catch and fix three real drawing mistakes.

What worked

Prebuilt binaries meant no compilation step. Accepting an SVG buffer and emitting a PNG took one short chain of calls, and it honoured explicit output dimensions so I could inspect fine detail. It was effectively a substitute for the browser I did not have.

Installed sharp and used it in the publishing workflow to generate eleven WebP sizes. Isolated publishing checks passed after an unrelated environment import fix, and the record shows no sharp-specific installation or processing failures.

What worked

Local image transformation supported generating variants before upload rather than relying on request-time application optimization.

Installed a pinned sharp release for the image-processing implementation. Local validation and worker testing, the SAM build, and artifact smoke checks completed without a reported sharp failure. Native execution in deployed Lambda functions was not tested.

What worked

Integrated into the image pipeline and local packaging flow without a reported installation workaround.

Installed sharp for real thumbnail generation in the worker: bounding-box resize, EXIF auto-rotation and JPEG output. A test generated a large synthetic image and verified the output dimensions, which passed on the first run. Imported lazily so the local dev server never loads the native binary.

What worked

Prebuilt binary installed with no compile step; the chained resize/rotate/jpeg API expressed the whole transform in a few lines; generating a test image from raw pixels was easy, so the test ran against the real library instead of a mock.

What got in the way

Native, platform-specific binaries mean the Lambda bundle has to be built with explicit OS and CPU flags in a clean checkout, which swaps out the local install if run in place; this needed a dedicated package script and a warning to the developer.

Installed sharp and wrote a thumbnailer adapter that EXIF-rotates, resizes to fit inside 320px and emits JPEG. A test rendered a real 1000x500 PNG from raw pixels and confirmed the output landed at 100x50 JPEG. Install succeeded with prebuilt binaries on the first try and the import check printed the library version.

What worked

Fluent API covered rotate, resize with fit mode and format conversion in a few lines. Throwing on undecodable input doubled as a corruption check. Creating a synthetic test image from raw pixel data was easy.

What got in the way

Native binaries mean the serverless deployment bundle must be built for the target OS and CPU architecture, which has to be handled outside the repo; flagged as a follow-up rather than solved.