prism-mosaic

byMarcelino Justo

1. Executive Summary This program builds a web product that compiles a licensed raster artwork into a manufacturable, wall-mounted, 3D relief LEGO mosaic using only official elements and colors from versioned catalog snapshots, constrained by a fixed MVP part whitelist (Appendix A) and three exact stud-grid tiers: 32×32, 48×48, 64×64 studs. The core technical stance is a constrained compiler pipeline: semantic and perceptual analysis → relief and palette-constrained quantization → primitive and bounded-SNOT proposal → global discrete optimization → physical legality and assembly validation → ranked candidate designs → export bundle (placement, depth, BOM, steps, validation, renders, manifests). Primary success measure: visual fidelity under hard physical and catalog constraints, with cost and rarity as secondary penalties. Reproducibility is a first-class requirement: every export must be rebuildable from pinned catalog snapshots, model weights, solver configs, and scoring rules. MVP delivery path: (1) deterministic compiler + validators on synthetic and fixture inputs, (2) catalog enforcement + backplane specs, (3) solver + ranking, (4) ML-assisted prioritization trained on synthetic data plus a small expert-labeled set, (5) website job lifecycle and export, (6) observability and acceptance hardening. 1. Problem Framing and Invariants Primary optimization objective Maximize perceptual fidelity of the visible assembled mosaic to the normalized source artwork under: • official discrete color palette (from ColorPaletteSnapshot) • stud-grid resolution per tier • bounded relief depth and backplane structural rules • whitelist-only parts Operationalized as a scalarized score (see §13): weighted sum of perceptual loss (e.g., LPIPS-like, SSIM, edge/structure terms) plus semantic saliency-weighted regions (faces, type, logo contours). Secondary optimization objectives • Minimize instruction complexity (step count, ambiguous attachments, reorientation count). cope In scope (MVP) • Web upload of licensed artwork (with provenance gate). • Tier selection: 32×32, 48×48, 64×64. • Pipeline: analysis → compilation → validation → ranked candidates → human/operator review option → export. • Artifacts: placement map, per-cell depth map, BOM, assembly steps, validation report, review renders, run manifest, config bundle. • Official elements only via snapshots + whitelist. • Bounded SNOT via template patches. • Synthetic pretraining + small expert labels for ranking/prior modules. • Standardized wall-mount backplane per tier. Out of scope for MVP (see §4) 1. Non-Goals • Arbitrary resolution or non-square grids. • Non-LEGO or custom 3D-printed elements. • Unlimited palette (e.g., RGB free optimization). • Primary optimization for minimal cost or minimal piece count. • Guaranteed photographic match in all regions regardless of brick vocabulary (soft failures become ranked or needs_review). • Full AR “build in your room” (could be future). • Retail/partner automatic inventory ordering (export is BOM; purchasing is external). 1. Assumptions ID Assumption If false A1 A curated catalog snapshot format can be ingested (BrickLink-like part/color IDs or internal normalized IDs with stable mapping). Lock import adapter and ID scheme in Gate 2. A2 Physical legality can be approximated by a connection graph + collision model validated against simplified LEGO geometry (not necessarily full CAD for MVP). Increase validation fidelity in later phase; gate “first physical build” with real build. A3 MVP whitelist in Appendix A is the sole allowed superset of parts at runtime. Enforcement is fatal on violation. A4 Expert labelers can provide 100–500 high-quality examples (order-of-magnitude; exact N is a parameter). Reduce ML scope to ranking only; more synthetic. A5 Users possess rights to upload artwork; product does not substitute legal review—workflow records attestations. Legal review external; system stores metadata only. A6 Renders are indicative; final fidelity ground truth is physical build spot checks. Label render vs photo discrepancy as known risk. 1. System Architecture Logical architecture [Web Client] <-> [API Gateway / BFF] | v [Job Orchestrator + State Store] | +———––+———––+ v v v [Artifact Store] [Queue/Workers] [Auth/Billing - future] | +———––+———––+ v v v [Ingest/Normalize] [Analysis ML] [Compiler+Solver] | | | v v v [Provenance svc] [Feature maps] [Validators] | v [Export/Render] Subsystem boundaries Subsystem Responsibility Client Upload, tier selection, review UI, download export. API Auth, job CRUD, signed URLs, idempotent job creation. Orchestrator State machine, retries, pinning manifests. Workers CPU/GPU jobs: analysis, compile, validate, render. Artifact store Versioned blobs + content-addressed hashes. Catalog service Read-only snapshots; no runtime edits. Technology stance (non-prescriptive) • API: HTTP + JSON (or gRPC internally); jobs async. • Workers: Containerized; GPU optional for analysis/inference. • Storage: Object store for artifacts; relational DB for job metadata.