Post-processing utilities, measured

Five endpoints take an image in and give one back. All are synchronous, all return {usage, image} inline, and all cost 1 generation, including the ones that sound like pure image manipulation.

Endpoint	Cost	Palette survives?	What it actually does
remove-background	1	yes	Genuine cleanup, the only safe one
rotate	1	no	Re-renders from a new angle
resize	1	no	Re-generates, does not resample
image-to-pixelart	1	no	Destroys alpha too
inpaint / edit-image	1	untested	Targeted edits

Measured on one 64×64 riso badge with an exact 4-colour palette (#f4ecd8 #1c1a17 #c1553a #6b7f5e, 57% transparent):

	colours out	transparency	result
source	4	0.57	n/a
remove-background	3	0.60	dropped a stray fringe, kept the rest
rotate	30	0.58	anti-aliased new angle
resize → 32px	38	0.57	cream+rust came back gold
image-to-pixelart → 32px	455	0.00	opaque grey background

remove-background also de-fringes. It removed the scattered sage-green speckles around the badge outline and left the three real inks untouched. Colour count went down, transparency went up. It is the one utility safe to run on palette-locked art.

resize is generative, not a resampler. The name is misleading: it takes a description as a required field, and it re-renders. A 4-colour cream-and-rust badge came back as 38 colours of gold.

color_image does not rescue it. resize accepts the parameter in its schema; passing the exact same swatch that pixflux honours changed nothing. 56 colours, still gold. The forced palette works on pixflux and bitforge only, and being in another endpoint's schema is not evidence it is wired up.

Never round-trip palette-locked art through resize or rotate. Regenerating at the target size with pixflux costs the same 1 generation and the palette holds exactly.

image-to-pixelart is for photographs and 3-D renders, not for reprocessing pixel art. It returned 455 colours on a 4-colour input and flattened the alpha channel to an opaque grey field. There is no no_background parameter to prevent that.

---