--- title: 'PhotoCraft: rules, orchestration and result validation' date: '2026-10-21' author: Karbonic category: Technologie language: en-GB canonical: https://www.karbonic.net/journal-photocraft-harness-en.html description: 'PhotoCraft: govern agents, orchestrate tasks and validate results with harnesses, computed judges and local tools.' og:image: https://www.karbonic.net/assets/photocraft-orchestration-v54.webp --- # PhotoCraft: rules, orchestration and result validation PhotoCraft is an orchestration project: rules govern agents, tasks are coordinated and results are checked. Image processing provides the concrete application explored here. ![Illustration of a software orchestration workstation seen from behind: validation table, execution log and Git history on two monitors.](https://www.karbonic.net/assets/photocraft-orchestration-v54.webp) Rules, validation status and Git history: orchestration in focus. Illustration. ## The application: from a photograph to new lighting We are developing a PhotoCraft pipeline combining existing photographs, mesh preparation, UV projection, a Blender scene, lighting and image checks. Processing steps are run on three local machines. Integration and evaluation methods are under development. This article describes an iteration, rather than an established industrial result. A photograph already contains reflections and shadows. Projecting it onto geometry and adding light can combine two lighting conditions. A partly hidden face can also receive a texture that appears twice when the camera turns. A better prompt cannot resolve this alone. ## The harness: a verifiable execution framework The harness surrounds the agent with permitted tools, context, instructions, execution, logs and checks. For an image pipeline, that contract must also identify inputs, script and model versions, parameters, expected outputs and stop conditions. A run identifier links source files, their hashes, settings and results. A script copied to another machine must be checked before comparing renders. Otherwise, a version difference may be mistaken for an algorithmic improvement. This is the reproducibility framework we are building around the work. ## CPU judges — and tests for the judges Here, a CPU judge means a computed, reproducible check, distinct from a language model’s opinion. In the observed iteration, measurements include preserved pixels at the reference angle, duplicates, unknown areas and text deformation. A model can help identify a defect or propose a correction. Validation must then return to images, measurements and control cases. A deliberately degraded mesh is particularly useful: if the judge gives it almost the same result as the corrected mesh, the judge does not distinguish them well enough. ## Measured progress, with a trade-off In the same test at +10°, the internal duplicate indicator falls from 5.06% to 1.72%. Meanwhile, the area classified as unknown increases from 11.8% to 13.2%. Identical pixels at 0° remain at 99.71%. These figures concern this one test and its internal measurements; they are not a general benchmark. The correction avoids projecting texture onto certain unseen surfaces. It reduces repetition but leaves more areas without information. That trade-off needs to remain visible rather than disappearing inside an overall score. Yet the degraded-mesh control produces 1.79% duplicates, close to the corrected result’s 1.72%. The conclusion for this iteration is that this indicator alone is insufficient to authorise the next stage. ## UVs, normals and relighting solve different problems UV mapping establishes a correspondence between a surface and its texture. It does not reveal parts missing from the photograph. A normal map changes the response to light; it does not by itself create actual volume or a reliable silhouette from a new angle. The ongoing work also examines depth, normal and appearance prediction using Diffusers’ Marigold pipelines. Available outputs depend on the chosen model. They remain estimates: a predicted material or suggested relief is not a product measurement. The next step is to separate the object, its sensitive details and its lighting environment as far as possible. Lettering and functional features need separate checks. A generated background can support presentation; it must not be confused with a documented reconstruction of the object. ## Three machines, one comparable experiment Python and Blender provide execution components; local models can assist analysis and orchestration. Parallel execution must allocate work without overwhelming the workstations and return comparable results. The pipeline needs a job queue, CPU, RAM and VRAM budgets per machine, time limits and controlled retries. Three machines’ memory does not automatically become a single memory pool. Low process priority alone does not cap CPU consumption. Raw renders, lit renders and final results must remain separately comparable. Geometry, material and lighting should not all change at once when trying to isolate a defect’s cause. ## ECC, Hermes, MCP and llama.cpp have distinct roles ECC provides resources for structuring agent work, including skills, hooks and rules. Hermes Agent can connect to tool servers through MCP. MCP describes interaction with tools; it replaces neither render scheduling nor validation criteria. llama.cpp supports local model execution, with CPU and GPU options depending on configuration. In the intended architecture, the model proposes actions, tools execute and checks determine whether a stage can continue. These components are integration reference points; listing them does not mean they are all already connected to PhotoCraft. ## All local: a boundary to verify The aim is to keep images and processing on local machines. This requires checking configured model providers, initial downloads, telemetry, remote tools and any fallback providers. An MCP server or an installed model alone does not guarantee the absence of external traffic. Keeping up with developments is part of the work. But adopting a new component only matters if it improves a reproducible experiment: the same sources, identified versions, explicit comparisons and visible limits. That is PhotoCraft’s purpose here: producing images whose transformations can be explained and checked. ## Technical references - [ECC](https://github.com/affaan-m/ECC) - [Hermes Agent · MCP](https://hermes-agent.nousresearch.com/docs/user-guide/features/mcp) - [llama.cpp · server](https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md) - [Blender · Python API](https://docs.blender.org/api/current/) - [Diffusers · Marigold](https://huggingface.co/docs/diffusers/main/en/using-diffusers/marigold_usage)