A finished image batch is measured in accepted outputs.

Inventory the inputs without touching the originals

Count the files and note their formats, dimensions and particularities: photograph, illustration, transparency, text, fine details or very large image. Check that they open. Identify unreadable files before blaming a setting.

Keep the originals in a separate folder. Assign an identifier to each input and keep the full path in the inventory. Two subfolders can each contain a file named image-01.png; removing their context creates a risk of overwriting. Choose an output rule that preserves this distinction and remains compatible with the names expected at delivery.

Write the output criteria before launching the software

Define the size, format, framing and any presence of transparency. Specify what may change: removing a background does not necessarily authorize modifying a logo or an inscription. For a product catalog, the fidelity of a detail can matter more than an overall more pleasing appearance.

Distinguish resizing from cropping. A 1,600 × 1,200 pixel image has a 4:3 ratio; scaled proportionally to 400 pixels wide, it measures 300 pixels high. A 400 × 400 output therefore requires an additional choice: crop, add margins or distort. Have this choice validated on the sample, without letting a default setting decide for the whole folder.

• Expected dimensions and framing rule.
• File format and transparency to preserve.
• Text, brand or subject detail not to be altered.
• Naming and the tool in which the output will be opened.
• Person who will accept the results.

Check orientation, transparency and retained information

A preview can mask a difference between the pixels and their display information. Some images carry an EXIF orientation: the Pillow documentation describes an operation that transposes the pixels according to this indication and then removes the orientation information. Whatever tool is used, check the file reopened after export to avoid a missing rotation or one applied twice.

Transparency is also information you need to check. Pillow distinguishes RGB, with three color channels, and RGBA, with an additional alpha channel, among others. A conversion or export can change the information that is preserved. Check the edges of objects against both a light and a dark background if the delivery needs to work across multiple media.

Don't rely solely on the software's internal preview. Open a few outputs in the destination tool, and check the dimensions and details at the size they'll be used. If the project requires a specific color profile or metadata, add preserving them to your criteria and check the properties of the exported file.

Choose twelve cases that can reveal a defect

Choose twelve varied entries: large and small images, flat color areas, textures, dark areas, text, and transparency where these cases exist. This number is a starting point, not a guarantee of representativeness. The table describes four identifiers out of twelve in a fictional plan: no files were processed to establish these criteria.

Start with one image, then a small group. Keep settings and variants separate. After processing, record accepted or needs rework along with the reason observed; the criteria in the table are not results.

Pillow's verify method looks for file defects without actually decoding the pixels. It doesn't assess the fidelity of an edit: supplement this technical check with opening the file and a visual review.

Increase group sizes without confusing speed and memory

The number of images processed simultaneously depends on the software, the dimensions, the method, and the memory actually used. Run a test with the large entries before settling on a group size. Note the number completed, the errors, and your observations on memory or time along with their conditions.

If a group fails due to lack of memory, first reduce the number of simultaneous images. If a single entry still fails, look at the software's documented options and the need for more capacity. Some tools may offer tiling an image; whether that's available and how it affects the seams must be verified.

Don't directly extrapolate the time for one small image across three hundred different files. Loading, input sizes, rework, and review can change the total. The first batch also serves to observe this variability, without promising a throughput based on the GPU model alone.

Worked example: tracking three hundred visuals through to delivery

Suppose a batch of 300 shop images. The twelve pilot cases are part of these 300 entries: they are not added to the total. Once they are accepted, their identifier stays marked as done. You then complete a first batch of thirty entries, eighteen of which are new, before widening the processing.

After the initial pass, imagine 286 outputs accepted, 9 needing rework, and 5 unreadable entries: 286 + 9 + 5 = 300. The nine reworks yield seven new accepted outputs and two cases that are still incorrect. The owner of the entries also provides three readable replacement files, whose outputs are then validated.

The tally becomes 286 + 7 + 3 = 296 accepted images, with four unresolved cases. These numbers are an example of tracking, not a measured result. You don't present the project as a delivery of 300 images: you let the client decide how to handle the four exceptions, or you hand over the 296 files with this limitation explicitly accepted.

Give every file a precise status

Your tracking table should link the input identifier, the output path, the attempt used, the verdict and the reason for a rework. The statuses "to do", "in progress", "output to check", "accepted" and "needs rework" prevent a file that is merely present on disk from being declared finished.

If you get interrupted, start from this inventory. Check the files produced before the stop and re-run only those that are not accepted, as far as the software allows. Blindly re-running the whole folder can recreate variants, overwrite a good result or complicate the count.

Write the new variants to a separate location. Replace the retained output only after checking it, and update the link in the inventory. The input identifier stays stable, even if the variant name changes.

Check the delivery from the retrieved copy

Count the expected identifiers rather than files indiscriminately: an original can have several variants. Check that every accepted entry has exactly the output retained for delivery. A contact sheet of thumbnails helps spot overall discrepancies, but fine contours and text require a closer look.

Copy the retained images, the inventory and the useful settings to your destination. Open representative files from this copy, as well as all cases that required a significant correction. Separate the deliverables from the rejected variants and specify the remaining exceptions.

Finally, build the review, the feedback and the export into your choice of 3, 7 or 30 days. A recurring series may have a lot of waiting between two batches; a single batch may require several corrections. The project's actual schedule should guide the duration, without equating a long period with more guaranteed visuals.