Restaurant Food Image Studio

Was macht Restaurant Food Image Studio?

Wandeln Sie gemischte echte Restaurant-Schnappschüsse in ein kleines, kohärentes Set von Webseiten-Fotografien um. Verwenden Sie das echte Foto als faktische Autorität für die Speise. Verwenden Sie das Restaurant-Fotografiesystem als Autorität für Kamerawinkel, Komposition, Licht, Hintergrund, Farbe, Beschnitt und die kundenorientierte Präsentation.

Behalten Sie keinen schwachen Quellwinkel nur deshalb bei, weil er echt ist. Wenn ein Schnappschuss von oben, ein unübersichtlicher oder inkonsistenter Schnappschuss nicht zum Webseiten-System passt, verwenden Sie reference-restage, um dieselbe Speise aus der festgelegten kundenorientierten Kamera zu präsentieren. Lassen Sie niemals zu, dass die Nachinszenierung die Speisenfakten ändert.

Lesen Sie references/food-image-playbook.md vor dem Sammeln, Planen, Auffordern, Generieren oder Überprüfen. Kopieren Sie die gebündelten Manifest V3- und Style Lock-Strukturen, anstatt einen Arbeitsauftrag zu erfinden.

Wählen Sie den Modus

• Collect: Echte Ein-Restaurant-Kandidaten abrufen und Provenienz speichern.
• Audit: Restaurant-Identität, Sichtbarkeit der Speise, Quellwinkel und Nachinszenierungsrisiko überprüfen. Nicht generieren.
• Create: Ein Fotografiesystem festlegen, jede Quelle routen, ein gestaltetes Foto pro echter Quelle generieren und Zeitaufzeichnungen behalten.
• Repair: Nach Diagnose eines fehlgeschlagenen Gates aus der echten Quelle und dem festgelegten Fotografiesystem neu generieren.
• Review: Das kanonische Quell-/Ausgabe-Artefakt und alle fünf QA-Entscheidungen automatisch behalten.

Lassen Sie $restaurant-demo-builder die Geschäftsnachweise, Zielgruppe, das Webseiten-Layout und die Bildslots für eine vollständige Demo festlegen. Verwenden Sie diesen Skill für das Speisenfotografie-System und die Assets.

Evidence Review nicht blockierend halten

Behandeln Sie kanonische Kandidaten-, Quell- und Quell-zu-Ausgabe-Blätter als automatische Evidence-Aufzeichnungen, nicht als Genehmigungsanfragen. Sobald ein kanonisches Quellblatt existiert, zeichnen Sie jeden berechtigten Quell mit status: recorded, reviewer: workflow auf, validieren Sie die generate-Stufe und fahren Sie mit der Bildgenerierung fort, ohne auf den Benutzer zu warten. Nach der Ausgabe-QA zeichnen Sie den kanonischen Vergleich auf die gleiche Weise auf und fahren Sie mit dem privaten Demo-Gate fort.

Halten Sie nur an, wenn Evidence oder Validierung fehlschlägt, ein aktueller changes-requested-Eintrag existiert, die Quelle das vorgeschlagene Bild nicht wahrheitsgemäß unterstützen kann oder der Benutzer die aktuelle Ausführung explizit auffordert, zu pausieren. Die menschliche Inspektion bleibt später verfügbar und kann changes-requested erzeugen; sie ist niemals eine Voraussetzung für die Generierung. Behalten Sie die faktische Bestätigung des Eigentümers und die Veröffentlichungsrechte als separate Launch-Gates bei.

Manifest V3-Vertrag durchsetzen

Verlangen Sie, dass jedes Demo-Speisenbild alle diese Regeln erfüllt:

1. Binden Sie genau eine eindeutige served-dish-photo-visuelle Primäre aus demselben Restaurant ein.
2. Speichern Sie die unberührte Quelle lokal mit Plattform-Identität, Original-URL und SHA-256.
3. Liefern Sie diese echte Quelle an imagegen. Verwenden Sie niemals rein promptbasierte Speisenerzeugung.
4. Zeichnen Sie source_assessment.camera_view, kundenorientierte Eignung und Risiko für verborgene Details auf.
5. Vervollständigen Sie ein Restaurant-Level photography_system vor der Generierung.
6. Verwenden Sie constrained-edit nur, wenn die Quelle bereits in dieses System passt.
7. Verwenden Sie reference-restage, wenn Kamera, Komposition oder kundenorientierte Präsentation geändert werden müssen.
8. Blockieren Sie winkeländernde Nachinszenierungen mit hohem Risiko für verborgene Details, bis ein anderer echter Blick verfügbar ist.
9. Akzeptieren Sie einen bestätigenden Blick nur, wenn es sich um ein weiteres live-geprüftes served-dish-photo aus demselben Restaurant mit einem exakten gleichen-Speise-Übereinstimmungsnachweis handelt.
10. Zeichnen Sie einen transformationsplan pro Speise und erlaubte Appetitanpassungen auf.
11. Zeichnen Sie imagegen-Start, -Abschluss und -Dauer auf.
12. Dekodieren Sie die Ausgabe vollständig, zeichnen Sie ihre echte Breite und Höhe auf und überprüfen Sie ihr Pixelverhältnis gegen das Fotografiesystem.
13. Bestehen Sie die fünf separaten Gates: Wiedergabetreue, Stilkonsistenz, Appetitoptimierung, KI-Merkmale und Webseiten-Bereitschaft.
14. Speichern Sie die kanonischen Artefakte der echten Quelle und des Quell-zu-gestaltetem-Foto.
15. Bestehen Sie das Manifest demo-Gate, bevor Sie die Ausgabe in eine Webseite kopieren.

Wenn kein glaubwürdiges echtes Speisenfoto existiert, halten Sie den Slot textbasiert, verwenden Sie ein separat freigegebenes Nicht-Speisen-Bild, wählen Sie ein anderes fotografiertes Gericht oder fordern Sie ein Foto des Eigentümers an.

Behandeln Sie ein Foto des Eigentümers als zukünftigen Akquisitionskandidaten, nicht als visuelle Primäre, bis es einen implementierten Collector-Datensatz, vollständige Pixel-Dekodierung, ein kanonisches Kandidatenblatt und eine Kandidatenprüfung analog zu Apify/Masa hat. Manifest V3 lässt derzeit nur geprüfte Apify Google Maps- und Masa-Fotos als visuelle Primäre zu.

Arbeitsauftrag vorbereiten

Erstellen Sie output/food-image-studio/<restaurant-slug>/ mit sources/, prompts/, drafts/, selected/ und review/. Verwenden Sie:

• assets/image-manifest-template.json für image-manifest.json.
• assets/style-lock-template.md für style-lock.md.

Verwenden Sie Dateinamen in Kleinbuchstaben (ASCII). Setzen Sie niemals API-Token, private Schlüssel oder Kontogeheimnisse in diese Dateien.

In Befehlen lösen Sie <food-image-skill> aus dem verfügbaren Skill-Locator dieses Skills auf.

Echte Speisenreferenzen sammeln

Führen Sie den Collector nur für das ausgewählte Restaurant aus:

APIFY_TOKEN=... python3 <food-image-skill>/scripts/collect_real_references.py apify \
  --place-id <google-place-id> \
  --max-images 20 \
  --output-dir <work-order>

python3 <food-image-skill>/scripts/collect_real_references.py masa \
  --store-id <masa-store-id> \
  --item-name <exact-menu-item-name> \
  --output-dir <work-order>

Für eine Maps-URL geben Sie auch die unabhängig bekannte Place ID an; der zurückgegebene Datensatz muss mit ihr übereinstimmen:

APIFY_TOKEN=... python3 <food-image-skill>/scripts/collect_real_references.py apify \
  --maps-url <exact-google-maps-place-url> \
  --expected-place-id <google-place-id> \
  --output-dir <work-order>

Der Collector dekodiert JPEG-, PNG- und WebP-Pixel vollständig und lehnt Quellen unter 300 Pixeln kurzer Seite oder 150.000 Gesamtpixeln ab. Er verlangt, dass Apify die gesperrte Place ID und Masa die angeforderte StoreID in der Antwort oder im Menüpunktskontext zurückgibt. Er behandelt niemals die angeforderte Kennung allein als Evidence.

Offline-JSON-Importe sind nur reproduzierbares Prüfmaterial. Sie behalten ihren Eingabe-Hash und den offline-audit-only-Rang, können aber nicht befördert oder in eine Demo aufgenommen werden.

Unabhängige Kandidatenprüfung aufzeichnen

Rendern Sie das kanonische Blatt der nicht klassifizierten Kandidaten:

python3 <food-image-skill>/scripts/make_candidate_sheet.py \
  --source-index <work-order>/source-index.json \
  --out <work-order>/review/candidate-sources.svg

Prüfen Sie jeden lokalen Kandidaten mit view_image und dem beibehaltenen Blatt. Lehnen Sie Screenshots, Menüs, Platzhalter, Stock-Bilder, synthetische Bilder, verdeckte Speisen und falsche Einträge ab. Zeichnen Sie die Klassifizierung als automatischen Prüfschritt auf; pausieren Sie nicht für die Benutzerfreigabe:

python3 <food-image-skill>/scripts/record_candidate_review.py \
  --source-index <work-order>/source-index.json \
  --candidate-sheet <work-order>/review/candidate-sources.svg \
  --candidate-id <candidate-id> \
  --out <work-order>/review/<candidate-id>.json \
  --status recorded \
  --reviewer workflow \
  --classification served-dish-photo \
  --restaurant-match verified \
  --restaurant-match-notes <identity-evidence> \
  --dish-visibility served-dish-visible \
  --visual-notes <visible-served-dish-evidence> \
  --notes <audit-summary>

Der Prüfdatensatz sperrt die Kandidaten-ID, den unberührten Quell-Hash, den Source-Index-Hash, den Hash des kanonischen Kandidatenblatts, den Prüfer, den Zeitstempel, die Klassifizierung und die visuellen Erkenntnisse. Zeichnen Sie Nicht-Speisen-Kandidaten unter ihrer echten Klassifizierung auf und befördern Sie sie nicht. Ein späterer changes-requested-Eintrag blockiert sofort die Beförderung und Demo-Validierung.

Beurteilung des Schnappschusses vor der Wahl des Modus

Zeichnen Sie den Kamerablickwinkel der Quelle als overhead, near-overhead, three-quarter, low-angle, straight-on oder unknown auf. Zeichnen Sie dann auf:

• fit: Die Quelle entspricht bereits dem Fotografiesystem; constrained-edit zulassen.
• restage-required: Die Speise ist faktisch korrekt, aber der Winkel oder die Komposition ist nicht kundenorientiert; reference-restage erforderlich.
• unusable: Das Essen ist zu verdeckt oder unsicher; Generierung blockieren.

Bezeichnen Sie einen Schnappschuss von oben nicht als fit, wenn das festgelegte kundenorientierte System ein three-quarter-tabletop ist. Der Sake Sushi-Fehler ist das kanonische Anti-Muster: Eine echte Quelle von oben kann nicht allein deshalb bestehen, weil eine Bearbeitung dieselbe Komposition von oben beibehält.

Der Validator erzwingt die Kompatibilität der Kamerafamilie. Quellen von overhead und near-overhead können nicht als fit für three-quarter-tabletop, low-tabletop oder straight-on markiert werden; inkompatible Blicke müssen restage-required sein, angle_change_required: true setzen und reference-restage verwenden.

Befördern Sie einen Kandidaten pro vorgeschlagener Ausgabe:

python3 <food-image-skill>/scripts/promote_candidate.py \
  --source-index <work-order>/source-index.json \
  --candidate-review <work-order>/review/<candidate-id>.json \
  --manifest <work-order>/image-manifest.json \
  --candidate-id <candidate-id> \
  --dish-id <dish-id> \
  --dish-name <dish-name> \
  --restaurant-name <restaurant-name> \
  --restaurant-slug <restaurant-slug> \
  --location <location> \
  --google-place-id <place-id> \
  --dish-match-status <exact-or-category-only> \
  --dish-match-notes <name-or-category-evidence> \
  --source-camera-view overhead \
  --customer-facing-fit restage-required \
  --hidden-detail-risk medium \
  --composition-notes <why-the-snapshot-needs-restaging> \
  --angle-change-required yes \
  --generation-mode reference-restage

Verwenden Sie --masa-store-id anstelle von --google-place-id für Masa.

Die Beförderung akzeptiert nur einen aktuellen recorded / audit-record klassifiziert als served-dish-photo aus einer live-verified-Sammlung. Sie kopiert die vollständige originale Provenienz und Quell-Metadaten in das Manifest. Die Source-Index- und Candidate-Review-Dateien bleiben hash-gebunden und werden in jeder späteren Stufe erneut validiert.

Behandeln Sie live-verified als workflow-bescheinigte Evidence, nicht als kryptografische Signatur von Apify oder Masa. Jemand mit Schreibzugriff auf den Arbeitsauftrag kann lokale JSON bearbeiten und lokale Hashes neu berechnen. Wenn die Provenienz bestritten wird oder vor einer öffentlichen Veröffentlichung von diesem Asset abhängt, führen Sie die Live-Provider-Sammlung erneut aus, vergleichen Sie die zurückgegebene Restaurant-Identität und den Bild-Hash oder ersetzen Sie es durch ein freigegebenes Eigentümer-Asset, das eine zukünftige Eigentümer-Erfassungsprüfung bestanden hat. Beschreiben Sie die lokale Kette niemals als manipulationssicher.

Ein gestaltetes Fotografiesystem festlegen

Vervollständigen Sie sowohl das strukturierte photography_system als auch die style-lock.md vor der Generierung. Legen Sie eine primäre Kamerafamilie für das Restaurant-Set fest, normalerweise ein wiederholbares three-quarter-tabletop-System bei etwa 35–45 Grad für kundenorientierte, lässige Speisenfotografie. Zeichnen Sie eine Winkeltoleranz von nicht mehr als 15 Grad auf.

Legen Sie alle diese Variablen fest:

• Zielwinkel, Kamerahöhe, Objektivgefühl und Motivgröße;
• Seitenverhältnis, Beschnitt und Webseiten-Negativraum;
• Oberfläche, Hintergrundfamilie und Zurückhaltung bei Requisiten;
• Lichtrichtung, Lichtqualität und Schattencharakter;
• Belichtung, Weißabgleich, Sättigung und Kontrast;
• Appetitbehandlung und akzeptable echte Unvollkommenheiten;
• die natürlichen Hinweise, die erforderlich sind, um ein KI-generiertes Aussehen zu vermeiden.

Verwenden Sie eine primäre Kamerafamilie im gesamten Set. Wechseln Sie nicht beiläufig zwischen Aufnahmen von oben, von vorne und im Dreiviertelwinkel.

Wahrheitsgetreue Appetitoptimierung planen

Zeichnen Sie spezifische Anpassungen für jede Speise vor dem Prompting auf. Erlauben Sie nur Verbesserungen, die durch die Quelle gestützt werden:

• Belichtung leicht erhöhen und Weißabgleich korrigieren;
• Vorhandenes Brot oder Kruste natürlich wärmer und goldener machen;
• Vorhandene Grillspuren, knusprige Kanten, Gemüsefarben oder Soßenglanz verdeutlichen;
• Ablenkende Hintergrunddetails entfernen und die Platzierung des Tellers verbessern;
• Normale Serviervariationen, ungleichmäßige Schnitte und Quell-Asymmetrie bewahren.

Erfinden Sie keine Bräunung, Grillspuren, Garnitur, Zutaten, Soße, Dampf, Portion, Gefäß oder luxuriöse Anrichteweise. „Appetitlicher“ ist ein Präsentationsziel, keine Erlaubnis, das Essen neu zu gestalten.

Quell-Artefakt automatisch aufzeichnen

Verlangen Sie, dass das strukturierte Fotografiesystem, der Style Lock und jeder Transformationsplan vollständig sind, bevor das Quellblatt erstellt wird:

python3 <food-image-skill>/scripts/validate_manifest.py \
  --manifest <image-manifest.json> \
  --stage plan

Erstellen und behalten Sie dann das kanonische Quellblatt und zeichnen Sie es ohne Pause auf:

python3 <food-image-skill>/scripts/make_contact_sheet.py \
  --manifest <image-manifest.json> \
  --stage source \
  --out <work-order>/review/source-review.svg

python3 <food-image-skill>/scripts/record_review.py \
  --manifest <image-manifest.json> \
  --dish-id <dish-id> \
  --gate source \
  --status recorded \
  --reviewer workflow \
  --notes <source-angle-route-and-evidence-notes>

Pausieren Sie nicht nach dem Rendern des Blatts. Zeichnen Sie jeden berechtigten Quell automatisch auf, ersetzen Sie alle TODO-Marker in Prompts, verlangen Sie validate_manifest.py --stage generate, und fahren Sie direkt mit der Bildgenerierung fort, wenn die Validierung bestanden ist.

Das gestaltete Foto generieren

Verwenden Sie $imagegen. Liefern Sie die visuelle Primäre in jedem Aufruf und fügen Sie echte bestätigende Blicke hinzu, wenn das Risiko verborgener Details dies erfordert. Geben Sie in jedem Prompt an:

Für jede bestätigende ID zeichnen Sie source_assessment.supporting_source_matches.<source-id> mit status: exact und spezifischen Notizen zur gleichen Speise auf. Fügen Sie nur diese geprüften echten Blicke nach der visuellen Primäre in output.input_source_ids ein; Menüdokumente, Veranstaltungsfotos, Stock- und synthetische Bilder können das Risiko verborgener Details nicht decken.

1. Nennen Sie die Quell-ID und constrained-edit oder reference-restage.
2. Nennen Sie die Zielkamerafamilie und den Zielwinkel explizit.
3. Behandeln Sie die echte Quelle als Speisenwahrheit und das Fotografiesystem als Präsentationswahrheit.
4. Wiederholen Sie verifizierte Speisenfakten, Mengen, Portionen, Beilagen, Soßen, Garzustand und Gefäß.
5. Beschreiben Sie nur die geplante Komposition und Appetitverbesserungen.
6. Bewahren Sie echte Unregelmäßigkeiten und die normale unabhängige Restaurantpräsentation.
7. Verbieten Sie Plastikglanz, wachsartige Textur, wiederholte Geometrie, perfekte Symmetrie, deformierte Kanten, gefälschte Effekte, Text und Logos.
8. Erstellen Sie ein ...

---

Hinweis: Der letzte Absatz des Originals wurde aufgrund seiner Trunkierung(unvollständiger) nicht übersetzt. Bitte stellen Sie sicher, dass die vollständige SKILL.md-Datei bereitgestellt wird, um eine vollständige Übersetzung zu erhalten. Der Übersetzer hat bis zum verfügbaren Inhalt übersetzt.