Transparent Sprite Component Extractor

How to use Transparent Sprite Component Extractor

Separate alpha-connected regions into individually masked PNG cutouts and download a ZIP with original-coordinate evidence. Recover distinct pieces from a transparent sprite image without guessing a tile grid or replacing the original. Choose an explicit alpha cutoff and neighborhood, inspect each region’s bounding rectangle and pixel count, and receive a separate PNG for every selected component.

1. Provide static transparent source image, include source alpha strictly above this byte, minimum connected pixel count.
2. Choose the supported mode and run the tool. Review its assumptions and any reported errors.
3. Copy the result or download a separate output; reset to clear the current form.

Good to know

• One static PNG, baseline JPEG or simple VP8/VP8L WebP up to 8 MiB, 1,000,000 decoded pixels and 2,048 per side. Existing full structure/CRC/dimension preflight precedes decoding; animated/extended/progressive formats, compressed PNG metadata and supplied SVG are refused. An opaque photo usually produces one component.
• Alpha cutoff is an exact plain integer 0–254; minimum area is an exact plain integer 1–1,000,000. A source pixel belongs to foreground only when its decoded alpha is strictly greater than the cutoff. Four neighbors share an edge; eight also connects diagonals. No semantic object detection or color similarity is inferred.
• At most 32 selected components and 4,000,000 aggregate bounding-rectangle pixels are permitted. Every component and rectangle budget is checked before output raster allocation. Small components below the chosen area are counted as ignored; larger output overflow refuses the entire operation rather than silently omitting sprites.
• Each PNG retains that component’s original decoded samples inside its smallest integer bounding rectangle. Holes, background and different components inside the same rectangle become transparent black. Region order is the row-major first source pixel. The JSON manifest records original coordinates, counts and stable generated file names.
• One source-sized four-byte component-label array, one four-byte queue and the bounded output rasters define core allocation. Pixel work prepares in a same-origin module within 10 seconds, then has a separate 2-second computation deadline. The original source buffer is copied before Worker transfer.
• PNG encoding proceeds sequentially. Each native encode waits at most 5 seconds and the batch is checked cooperatively against 15 seconds between images; native codec work cannot be forcibly interrupted. ZIP input plus conservative archive overhead is limited before construction and the final ZIP is at most 8 MiB.
• The ZIP contains only generated component-NNN.png names and manifest.json, never arbitrary source paths or untrusted archive entries. Zero selected components produces a manifest-only ZIP with an explicit zero count. The on-page image, when present, previews only the first selected cutout.
• Native decoding, color conversion, premultiplication and re-encoding can change source metadata or hidden transparent colors. Original files are not modified, uploaded, deleted or automatically saved. Bitmap/canvas resources are released on success and failure.
• Structured text output is limited to 500,000 characters. Reduce the supplied source when that separate output budget is exceeded.
• Inputs are processed on this device and are not automatically saved or uploaded.