Upload optimisation
The upload pipeline most applications actually need: cap the dimensions, re-encode to a modern format, strip the metadata, and see exactly how many bytes that saved. Everything happens on the user's device, so your servers never receive the 8 megapixel original.
Try it
Pipeline
The batch API's MaxConcurrency, as in the snippet below; this page itself decodes one file at a time to keep memory flat. Higher is faster but holds more decoded images at once - two is a safe default on phones. Batch processing runs it for real.
The code
One pipeline, built once and reused for every file: nothing runs until it is executed, so it
is safe to keep in a field. MaxSize only ever shrinks - a small image passes
through untouched instead of being blown up - and the sharpen afterwards recovers the bite
that downscaling takes away.
// One pipeline, reused for every file. Nothing runs until ProcessBatchAsync executes it.var pipeline = ImagePipeline.Create() .AutoOrient() // honour the phone's rotation sensor .MaxSize(maxEdge, maxEdge) // never enlarge, only cap .Sharpen(0.3f); // recover the bite lost to downscalingvar processor = await processorFactory.GetAsync();var result = await processor.ProcessBatchAsync(items, pipeline, new BatchOptions{ MaxConcurrency = 2, Progress = progress, ExportOptions = new ImageExportOptions { Format = ImageFormat.WebP, Quality = 0.82, Metadata = MetadataPolicy.Remove, },});Choosing the numbers
- 1920 on the long edge covers a full-width hero on most screens; product thumbnails and avatars want far less.
- WebP at 0.8 is typically 25 to 35% smaller than JPEG at similar quality. Where this browser cannot write it, the format list above simply does not offer it - the list is the capability probe's answer.
- Re-encoding can grow a file. A small or already heavily compressed upload may come out larger; the table says so in red rather than claiming a saving. A real pipeline would keep the original in that case.