Relier Bernard Review au pipeline d'un studio. Configuration des trackers, playlists avec identifiants, retour des notes, tableau des versions construit par script et règle de nommage.
Cette page s'adresse aux équipes pipeline. Elle décrit comment faire entrer une revue dans le lecteur depuis un outil de suivi de production, et comment en faire sortir les notes avec les bons identifiants. Les commandes citées sont décrites dans API Python et IPC.
Bernard Engine, l'outil de suivi de production d'AArts Lab, et tout pipeline maison passent dans cette version par trois mécanismes : la playlist .bpl avec le bloc x_tracking, la commande build-matrix et l'export des notes. La publication directe vers Bernard Engine depuis le lecteur (bouton Publish to Bernard Engine) arrive bientôt.
Une playlist .bpl est un fichier JSON (schéma : api/playlist.schema.json). Chaque plan peut porter un bloc x_tracking avec les identifiants du tracker. Écrivez-le depuis votre outil, puis chargez-le avec 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"
}
}
]
}Les champs de x_tracking : shot_id, shot_name, version_id, shotgrid_version_id (entier), ftrack_id, artist, task. Le bloc est gardé quand la playlist est enregistrée.
export-notes écrit, sans aucune fenêtre, export.json et export.html dans le dossier demandé, avec une image JPEG par image annotée (schéma : api/notes_payload.schema.json). Pour chaque plan : name, status (Pending, Approved ou Not Approved), note, frames (le numéro et le fichier de chaque image annotée) et, s'il existait au chargement, le bloc x_tracking tel quel. Un script renvoie ainsi chaque note vers la bonne version par son identifiant, sans comparer de noms de fichiers.
client.load_playlist("D:/review/SQ010_dailies.bpl")
# ... la revue a lieu ...
client.export_notes("D:/review/SQ010_dailies_notes")L'écriture se fait en arrière-plan : attendez que export.json soit à jour avant de le lire.
Le tableau des versions (Versions) se remplit seul à partir des noms de fichiers. Un pipeline peut aussi l'envoyer tout fait, avec build-matrix, sans convention de nommage. Une commande par séquence ; une entrée de département par version à proposer (envoyez deux fois le même département avec deux versions pour remplir sa liste) :
{"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"}}}]}Chaque path absent de la playlist y est ajouté. get-matrix relit le tableau. En Python : client.build_matrix(sequence, shots, matrix_id) et client.get_matrix().
La recette est la même pour tout tracker : interroger les versions d'une séquence, les grouper par plan et par département (l'étape de pipeline), mettre le chemin du média dans path et l'identifiant de la version dans version_id.
Sans script, chaque plan ajouté est lu selon la règle du fichier naming_rules.json du dossier de profil (voir Installation et informatique) :
{"regex": "^([A-Za-z0-9]+)_([A-Za-z0-9]+)_([A-Za-z]+)_v([0-9]+)",
"groups": {"sequence": 1, "shot": 2, "department": 3, "version": 4}}C'est la convention [Sequence]_[Shot]_[Department]_v[Version].[ext], par exemple SQ010_SH010_ANIM_v002.mov. Adaptez l'expression régulière et les numéros de groupes à la convention du studio. Un fichier qui ne correspond pas va sous DefaultSeq / Base.
La fenêtre Tracker se connecte directement à ces trois trackers. Pour un déploiement, les sites se préparent dans trackers.json, dans le dossier de profil ; ce fichier ne contient jamais de secret (une clé qui ressemble à un secret est ignorée à la lecture) :
{"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 ou flow. user : l'e-mail pour Kitsu, l'utilisateur API pour ftrack, le nom du script pour Flow.base_url doit commencer par https:// (http:// seulement vers localhost).proxy : vide pour celui de l'environnement, direct pour aucun. ca_cert_file : un fichier PEM pour une autorité de certification du studio.path_map traduit les chemins du tracker pour chaque système ; status_map associe les statuts du lecteur (pending, approved, not_approved) à ceux du tracker.BERNARD_TRACKER_<ID>_SECRET, où <ID> est l'identifiant du site en majuscules, chaque caractère autre que A-Z et 0-9 remplacé par _ : pour demo-kitsu, BERNARD_TRACKER_DEMO_KITSU_SECRET. La variable l'emporte.Par script, les commandes tracker-sites, tracker-connect, tracker-projects, tracker-playlists, tracker-load-playlist, tracker-publish (avec dry_run pour essayer), tracker-download-media et tracker-cancel font ce que fait la fenêtre ; leurs résultats arrivent en événements. Une requête qui contient un secret est refusée.
Un plan chargé depuis un tracker garde aussi dans x_tracking le type de tracker, le site, la tâche, la playlist, la référence du média et, une fois publié, l'empreinte de la note envoyée : une note inchangée n'est jamais publiée deux fois.
Pour aller plus loin : le manuel complet, parties 6.4 et 6.6 (Help > User Guide dans le lecteur), et les schémas du dossier api/.