Build a Resize-and-Rotate Image Pipeline with Multiprocessing

Design an image-processing pipeline that uses Pillow to resize and rotate images, then extend it to process independent images using multiple processes.

Constraints & Assumptions

• The source specifically names resize/rotate operations with the image library and a multiprocessing extension; it does not supply a complete original API or transform specification.
• Practice scope: each input image has an explicit transform specification describing target size, rotation angle, operation order, and output destination. Produce one result or error record per input. Do not invent a hidden fixed order or angle.
• Input images are independent, while disk bandwidth and memory are shared resources.
• Define whether rotation expands the output canvas, how resize handles aspect ratio, and which output format is required before evaluating image dimensions or appearance.
• No exact process count, file size, throughput target, or acceptable lossy encoding is supplied.

Clarifying Questions to Ask

• Is resize a stretch, aspect-ratio-preserving fit, or crop, and which resampling mode is required?
• Does rotation preserve the original canvas or expand it, and does it happen before or after resize?
• Can two inputs target the same output path, and may an existing output be replaced?
• Should one invalid image abort the batch or be reported while other images continue?

Part 1 — Build a Correct Single-Image Operation

Describe opening and decoding the image, applying the specified transformations, writing the result, and recording failure. Identify where format, orientation, and resource lifecycle matter.

What This Part Should Cover

• Explicit transform order and dimensions without guessing a missing source rule.
• Proper ownership and closure of image/file resources.
• Output publication that does not confuse a truncated file with a completed result.

Part 2 — Add Multiprocessing

Explain how to distribute independent images across a bounded process set. Describe what is passed to a worker, how results are collected, and how failures and resource pressure are handled.

What This Part Should Cover

• Small serializable work descriptions rather than unnecessary transfer of decoded pixel buffers.
• Bounded in-flight work and memory-aware concurrency.
• Per-input result identity, worker failure handling, and cleanup.