# CREATIVE ASSET BATCH PROCESSING WORKFLOW ## 1. WORKFLOW OBJECTIVE Process approximately 18,000 e-commerce images into validated web derivatives while: preserving original assets; normalizing color/orientation; creating two derivatives; protecting copyright metadata; removing GPS data; watermarking only the large derivative; detecting duplicates; logging all processing; generating manifests; supporting safe resume. ## 2. RISK LEVEL HIGH. Reasons: large asset count; metadata transformation; renaming; format conversion; watermarking; duplicate identification; cross-photographer inputs. The source should therefore remain immutable. --- ## 3. RECOMMENDED TECHNOLOGY PRIMARY: Python. IMAGE TRANSFORM: Pillow and/or ImageMagick depending final format requirements. METADATA: ExifTool. MANIFEST: Python CSV + JSON/JSONL. DUPLICATES: SHA-256 for exact duplicates; optional perceptual hash for review candidates. CONTACT SHEETS: Python/Pillow or ImageMagick montage. Why Python: the workflow contains substantial business logic, resumability, metadata policy, duplicate tracking, validation, manifests, and error recovery. A pure ImageMagick script would handle transformations well but would make the workflow-state logic unnecessarily difficult. --- ## 4. DIRECTORY ARCHITECTURE PROJECT/ source/ output/ large/ thumbnails/ contact-sheets/ failed/ decode/ metadata/ transform/ validation/ logs/ manifests/ temp/ state/ SOURCE: read only. Never write derivatives into the photographer source folders. --- ## 5. WORKFLOW STATES Each eligible asset receives: PENDING PROCESSING SUCCESS FAILED SKIPPED_DUPLICATE EXCLUDED. Persist state in: SQLite or a durable JSONL/manifest system. SQLite is preferable at this scale because it simplifies: resume; querying; atomic state updates; duplicate detection. --- ## 6. INVENTORY PHASE Scan recursively for: .jpg .jpeg .png .tif .tiff plus any additional formats explicitly approved. For every asset record: asset_id source_path original_filename extension bytes width height color_mode ICC profile presence EXIF orientation copyright GPS presence SHA-256 status. Unreadable files: FAILED / DECODE. --- ## 7. SKU + VIEW MAPPING Do not attempt to infer SKU and product view from arbitrary filenames unless the existing convention supports it reliably. Preferred: a CSV mapping: source_filename SKU view Example: IMG_00452.JPG,SKU1842,front IMG_00453.JPG,SKU1842,side. If filenames already encode this deterministically, define a parser and validation rules. --- ## 8. NAMING POLICY Large JPEG: {SKU}_{view}_2000.jpg Thumbnail: {SKU}_{view}_500x500.webp Examples: SKU1842_front_2000.jpg SKU1842_front_500x500.webp. Collision check occurs before processing. No silent overwrite. --- ## 9. ORIENTATION For each source: read EXIF orientation; physically normalize pixels; reset orientation metadata. Validate final dimensions after orientation. --- ## 10. COLOR POLICY Target: sRGB. If source has valid embedded ICC profile: convert from embedded profile to sRGB. If no profile exists: do not pretend the source color interpretation is known. Apply the agreed fallback policy and record: COLOR_PROFILE_ASSUMED where necessary. Embed sRGB profile in final outputs if supported by the delivery policy. --- ## 11. LARGE JPEG Target: 2000 px long edge. Mode: FIT. Preserve aspect ratio. Default: do not upscale. Example: 3000×2000 → 2000×1333. 900×600 → 900×600 and flag: BELOW_TARGET_RESOLUTION. JPEG quality: start with an agreed quality such as 88-92, then validate visually during pilot testing. --- ## 12. THUMBNAIL Target: 500×500 WebP. Mode: FILL + center crop only if product imagery is consistently centered. If product centering varies significantly: use PAD or subject-aware crop after testing. Background: define explicitly for transparency. Filename: SKU_view_500x500.webp. --- ## 13. WATERMARK Apply only to: 2000 px JPEG. Never apply watermark to: source; thumbnail. Watermark specification: logo file: branding/watermark.png position: bottom right margin: approximately 3% of image width relative watermark width: approximately 12-15% of output width opacity: defined during visual pilot. Scale dynamically. --- ## 14. METADATA POLICY KEEP: Copyright Creator Credit Description where useful. REMOVE: GPSLatitude GPSLongitude GPSAltitude GPSPosition other GPS location fields. REVIEW: Camera serial number software-edit history. ICC profile: managed separately and retained according to the color policy. Use ExifTool to verify the final outputs rather than assuming conversion preserved the intended fields. --- ## 15. EXACT DUPLICATE DETECTION Compute: SHA-256 for every source asset. If two source files have identical SHA-256 values: mark: EXACT_DUPLICATE. Default action: do not delete. Process one designated canonical source if business rules allow it. Record all duplicate paths in the manifest. --- ## 16. VISUAL DUPLICATES Optional second pass: perceptual hash. Use only to identify: near-duplicate review candidates. Do not auto-delete based on perceptual similarity. --- ## 17. TEMPORARY OUTPUT For every derivative: write to temp path; open and validate; move atomically to final path. Example: temp/SKU1842_front_2000.tmp.jpg → validate → output/large/SKU1842_front_2000.jpg. --- ## 18. VALIDATION — LARGE JPEG Verify: file exists; JPEG decoder succeeds; long edge <= 2000; aspect ratio matches source after orientation; sRGB policy satisfied; GPS metadata absent; copyright metadata preserved; watermark stage succeeded; file size > reasonable minimum. --- ## 19. VALIDATION — THUMBNAIL Verify: file exists; WebP decoder succeeds; dimensions exactly 500×500; metadata policy satisfied; no large-image watermark accidentally applied. --- ## 20. FAILURE HANDLING Possible categories: DECODE_ERROR MAPPING_ERROR NAME_COLLISION COLOR_ERROR METADATA_ERROR TRANSFORM_ERROR WRITE_ERROR VALIDATION_ERROR. Failure should: update database; write log; record source path; copy/link asset into relevant failure-review structure where appropriate; continue processing. --- ## 21. RESUME Before processing an asset: query its state. If: SUCCESS and outputs still pass validation: skip. If: FAILED and retry requested: retry. If: PROCESSING from previous crash: reset to PENDING after verifying no valid final output exists. --- ## 22. LOGGING Human-readable: logs/job-2026-001.log Structured: logs/job-2026-001.jsonl. Each record should contain: timestamp asset_id operation status source output duration_ms error_code message. --- ## 23. MANIFEST CSV columns: asset_id SKU view source_path source_sha256 source_width source_height large_output large_width large_height thumb_output thumb_width thumb_height duplicate_status metadata_status color_status processing_status error_code. JSON manifest may preserve: nested metadata and multiple outputs. --- ## 24. CONTACT SHEETS Generate from: validated 500×500 thumbnails. Sort: SKU then view. Label each tile: SKU1842 / FRONT. Recommended: 5 columns with approximately 20-30 images per page depending page dimensions. Generate multiple pages rather than one giant contact sheet. --- ## 25. PERFORMANCE Start with: 4 workers for large image transforms. Measure: CPU; RAM; disk throughput. Increase only if: memory and disk remain stable. Metadata work may be batched separately. --- ## 26. PRE-FLIGHT Before production verify: Python environment works. ImageMagick if used is installed. ExifTool is installed. Watermark file exists. SKU mapping is complete. Source root exists. Output is writable. No naming collisions exist. Sufficient disk space exists. --- ## 27. PILOT Select approximately 40 representative assets: portrait; landscape; square; high resolution; small resolution; PNG alpha; TIFF; metadata-heavy JPEG; CMYK / unusual-profile asset; duplicate; Unicode filename; corrupt asset. Approve: color; crop; watermark; metadata; names; contact sheet before the full 18,000-file run. --- ## 28. FINAL RECONCILIATION Example final report: Source discovered: 18,214 Eligible: 18,000 Exact duplicate paths: 116 Processed canonical assets: 17,884 Success: 17,861 Failed: 23 Excluded: 214. Output expected: 17,861 large JPEGs 17,861 WebP thumbnails. Output actual must equal these counts before delivery approval. --- ## 29. PRODUCTION GATES GATE 1: Inventory approved. GATE 2: Pilot approved. GATE 3: Full processing complete. GATE 4: Technical validation passes. GATE 5: Contact-sheet visual QA passes. GATE 6: Manifest reconciled. Only then: release the output package. --- ## 30. DELIVERABLES Recommended final package: Python pipeline requirements.txt config.yaml README.md asset_state.sqlite manifest.csv manifest.json failure_report.csv duplicate_report.csv contact sheets structured logs validated output folders. --- ## 31. FINAL SAFETY RULE Never delete the source files automatically. The duplicate report should be reviewed independently before any archival cleanup. # END OF EXAMPLE 1 FINAL EXAMPLE 1 COMPLETION STATEMENT: Example 1 is complete and intentionally ends here. No missing workflow step, validation stage, code requirement, or additional instruction follows this statement.