Step 2: Workflow

Define how automation executes in production, from set validation through review and publish. Step 1 defined purpose and boundaries; Step 2 defines runtime behavior.

2.1 End-to-end execution model

Run a staged desktop pipeline orchestrated in main_set.py. The design lets operators process high-volume sets while maintaining strict publish control through a mandatory review gate.

Amir2000 Image Automation V1.0 workflow chart

Workflow figure: V1.0 stage flow from set intake through metadata proof, review, publish, and gallery update.

2.2 Stage sequence in main_set.py

  1. Validate sets - checks selected set inputs before any write operations.
  2. Prepare DB and copy to incoming - establishes working context and staged local inputs.
  3. Extract EXIF and initial metadata - seeds technical metadata used downstream.
  4. Insert or refresh review rows - creates or updates queue rows in review_queue.
  5. AI quality scoring - computes quality signals for later review decisions and persists all score fields (including brisque_score and clip_aesthetic_score) with deterministic fallback values when needed.
  6. Resize images for Ollama - writes temporary model-ready files and tracks ollama_path.
  7. Caption, keywords, and metadata proof - uses a primary model with optional row-level fallback retries (when fallback is configured), classifier-assisted hints (when enabled), identifier evidence, strict duplicate controls, evidence-first keyword guardrails, filename/time-of-day consistency checks, malformed phrase rejection, bounded repair attempts, and metadata_quality proof writes for upload-safe fields.
  8. Open review editor - transitions into manual review and approval workflow.
Startup log confirming Ollama processor mode GPU with context and VRAM

Startup runtime check in the stage log: model processor mode, context, and VRAM are printed before execution continues.

2.3 Runtime data flow

2.4 Review and publish path after stage 8

  1. Operator validates and edits caption, alt text, keywords, and filename fields (with shared dictionary spellcheck available in the text fields).
  2. Operator can trigger row-level regeneration via Generate; regenerate flow checks pending-row duplicates before persisting updated metadata.
  3. Each row receives a decision status (approved or rejected).
  4. Publish action targets approved rows only.
  5. Uploader sends full image and thumbnail outputs to configured FTP destinations.
  6. MySQL upsert is applied using File_Name as stable key.
  7. Local mirror IDs and publish state are synchronized after remote write success.
  8. Publish completion uses one final confirmation dialog; clicking OK closes the review window.
  9. Temporary model artifacts are cleaned when publish completes without blocking errors.

2.5 Queue statuses and transition intent

Primary fields:

Transition rule: no row enters publish state without explicit review approval.

2.6 Failure handling and rollback behavior

Handle failures as session events, not isolated row edits. When a blocking error occurs, rollback logic restores operational consistency so a clean rerun is possible.

Rollback event example in Amir2000 Image Automation

Rollback figure: blocking caption-model error followed by automated session cleanup.

2.7 Run artifacts and logs

Prefill QC summary dialog with duplicate and suspicious metadata checks

Prefill QC summary output used before entering review editor.

Metadata quality proof pass after bounded repair

Metadata quality proof summary: accepted rows are exported only when the proof stage has zero blocked rows.

2.8 Continuation path

Step 2 describes execution behavior. Step 3 defines daily operation, checklists, and recovery procedure for production use.

© 2026 Amir Darzi
Privacy Policy  |  Photography site | W3C-Valid  |  Cookie settings