Bernard Review mit einer Studio-Pipeline verbinden. Tracker-Konfiguration, Playlists mit Kennungen, zurückkommende Notizen, ein per Skript erstelltes Version Board und die Namensregel.
Diese Seite richtet sich an Pipeline-Teams. Sie beschreibt, wie man ein Review aus einem Produktions-Tracker in den Player holt und wie man die Notizen mit den richtigen Kennungen wieder herausbekommt. Die erwähnten Befehle sind unter Python-API und IPC beschrieben.
Bernard Engine, der Produktions-Tracker von AArts Lab, und jede hauseigene Pipeline laufen in dieser Version über drei Mechanismen: die .bpl-Playlist mit ihrem Block x_tracking, den Befehl build-matrix und den Notizen-Export. Das direkte Veröffentlichen an Bernard Engine aus dem Player (die Schaltfläche Publish to Bernard Engine) kommt bald.
Eine .bpl-Playlist ist eine JSON-Datei (Schema: api/playlist.schema.json). Jeder Clip kann einen Block x_tracking mit den Kennungen des Trackers tragen. Schreiben Sie ihn aus Ihrem Tool und laden Sie ihn dann mit load-playlist:
{
"current_idx": 0,
"playlist": [
{
"path": "//server/proj/SQ010/SH010/comp/SQ010_SH010_COMP_v003.%04d.exr",
"in_frame": 1001,
"out_frame": 1100,
"x_tracking": {
"shot_id": "shot_1001",
"shot_name": "SQ010_SH010",
"version_id": "v003",
"task": "Compositing"
}
}
]
}Die Felder von x_tracking: shot_id, shot_name, version_id, shotgrid_version_id (eine ganze Zahl), ftrack_id, artist, task. Der Block bleibt erhalten, wenn die Playlist gespeichert wird.
export-notes schreibt ohne jeden Dialog export.json und export.html in den gewünschten Ordner, mit einem JPEG pro annotiertem Bild (Schema: api/notes_payload.schema.json). Für jeden Clip: name, status (Pending, Approved oder Not Approved), note, frames (die Nummer und die Datei jedes annotierten Bildes) und, falls er beim Laden vorhanden war, den Block x_tracking unverändert. Ein Skript leitet so jede Notiz anhand ihrer Kennung an die richtige Version zurück, ohne Dateinamen zu vergleichen.
client.load_playlist("D:/review/SQ010_dailies.bpl")
# ... the review takes place ...
client.export_notes("D:/review/SQ010_dailies_notes")Die Dateien werden im Hintergrund geschrieben: Warten Sie, bis export.json aktuell ist, bevor Sie es lesen.
Das Version Board (Versions) füllt sich aus Dateinamen. Eine Pipeline kann es auch fertig mit build-matrix senden, ohne jede Namenskonvention. Ein Befehl pro Sequenz; ein Abteilungseintrag pro anzubietender Version (senden Sie dieselbe Abteilung zweimal mit zwei Versionen, um ihre Liste zu füllen):
{"cmd": "build-matrix", "sequence": "SQ010", "id": "seq_42",
"shots": [
{"name": "SH010", "id": "shot_1001", "departments": {
"ANIM": {"version": "v002", "path": "//server/proj/SQ010/SH010/anim/SQ010_SH010_ANIM_v002.mov", "version_id": "ver_77812", "id": "task_501"},
"LGT": {"version": "v001", "path": "//server/proj/SQ010/SH010/lgt/SQ010_SH010_LGT_v001.mov", "version_id": "ver_77950"}}},
{"name": "SH020", "id": "shot_1002", "departments": {
"COMP": {"version": "v003", "path": "//server/proj/SQ010/SH020/comp/SQ010_SH020_COMP_v003.mov", "version_id": "ver_78001"}}}]}Jeder path, der noch nicht in der Playlist ist, wird ihr hinzugefügt. get-matrix liest das Board zurück. In Python: client.build_matrix(sequence, shots, matrix_id) und client.get_matrix().
Das Rezept ist für jeden Tracker dasselbe: die Versionen einer Sequenz abfragen, sie nach Shot und nach Abteilung (dem Pipeline-Schritt) gruppieren, den Pfad des Mediums in path und die Kennung der Version in version_id eintragen.
Ohne Skript wird jeder hinzugefügte Clip nach der Regel in der Datei naming_rules.json des Profilordners gelesen (siehe Installation und IT):
{"regex": "^([A-Za-z0-9]+)_([A-Za-z0-9]+)_([A-Za-z]+)_v([0-9]+)",
"groups": {"sequence": 1, "shot": 2, "department": 3, "version": 4}}Das ist die Konvention [Sequence]_[Shot]_[Department]_v[Version].[ext], zum Beispiel SQ010_SH010_ANIM_v002.mov. Passen Sie den regulären Ausdruck und die Gruppennummern an die Konvention Ihres Studios an. Eine Datei, die nicht passt, landet unter DefaultSeq / Base.
Das Fenster Tracker verbindet sich direkt mit diesen drei Trackern. Für ein Deployment lassen sich die Sites in trackers.json im Profilordner vorbereiten; diese Datei enthält nie ein Secret (ein Schlüssel, der wie ein Secret aussieht, wird beim Lesen verworfen):
{"sites": [{
"id": "demo-kitsu", "kind": "kitsu",
"base_url": "https://kitsu.example.test",
"user": "reviewer@example.test",
"proxy": "", "ca_cert_file": "",
"path_map": [{"from": "/mnt/show/",
"to": {"windows": "S:\\show\\", "linux": "/mnt/show/", "macos": "/Volumes/show/"}}],
"status_map": {"approved": "done"}
}]}kind: kitsu, ftrack oder flow. user: die E-Mail-Adresse bei Kitsu, der API-Benutzer bei ftrack, der Skriptname bei Flow.base_url muss mit https:// beginnen (http:// nur zu localhost).proxy: leer für den der Umgebung, direct für keinen. ca_cert_file: eine PEM-Datei für eine Studio-Zertifizierungsstelle.path_map übersetzt die Pfade des Trackers für jedes System; status_map ordnet die Status des Players (pending, approved, not_approved) denen des Trackers zu.BERNARD_TRACKER_<ID>_SECRET, wobei <ID> die Id der Site in Großbuchstaben ist, mit _ anstelle jedes Zeichens außer A-Z und 0-9: für demo-kitsu also BERNARD_TRACKER_DEMO_KITSU_SECRET. Die Variable hat Vorrang.Aus einem Skript tun die Befehle tracker-sites, tracker-connect, tracker-projects, tracker-playlists, tracker-load-playlist, tracker-publish (mit dry_run zum Ausprobieren), tracker-download-media und tracker-cancel das, was das Fenster tut; ihre Ergebnisse kommen als Ereignisse an. Eine Anfrage, die ein Secret enthält, wird abgelehnt.
Ein aus einem Tracker geladener Clip behält außerdem in x_tracking die Art des Trackers, die Site, die Aufgabe, die Playlist, die Medienreferenz und, sobald veröffentlicht, den Fingerabdruck der gesendeten Notiz: Eine unveränderte Notiz wird nie zweimal veröffentlicht.
Weiterführend: das vollständige Handbuch, Teile 6.4 und 6.6 (Help > User Guide im Player), und die Schemas im Ordner api/.