Conecte Bernard Review a un pipeline de estudio. Configuración de trackers, playlists con identificadores, notas de vuelta, un Version Board construido por script y la regla de nomenclatura.
Esta página es para los equipos de pipeline. Describe cómo llevar una revisión al reproductor desde un tracker de producción, y cómo sacar las notas con los identificadores correctos. Los comandos mencionados se describen en API de Python e IPC.
Bernard Engine, el tracker de producción de AArts Lab, y cualquier pipeline propio pasan en esta versión por tres mecanismos: la playlist .bpl con su bloque x_tracking, el comando build-matrix y la exportación de notas. La publicación directa en Bernard Engine desde el reproductor (el botón Publish to Bernard Engine) llegará próximamente.
Una playlist .bpl es un archivo JSON (esquema: api/playlist.schema.json). Cada clip puede llevar un bloque x_tracking con los identificadores del tracker. Escríbalo desde su herramienta y cárguelo después con 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"
}
}
]
}Los campos de x_tracking: shot_id, shot_name, version_id, shotgrid_version_id (un entero), ftrack_id, artist, task. El bloque se conserva cuando se guarda la playlist.
export-notes escribe, sin ningún cuadro de diálogo, export.json y export.html en la carpeta indicada, con un JPEG por cada fotograma anotado (esquema: api/notes_payload.schema.json). Para cada clip: name, status (Pending, Approved o Not Approved), note, frames (el número y el archivo de cada fotograma anotado) y, si estaba presente en la carga, el bloque x_tracking tal como estaba. Un script puede así dirigir cada nota a la versión correcta mediante su identificador, sin comparar nombres de archivo.
client.load_playlist("D:/review/SQ010_dailies.bpl")
# ... the review takes place ...
client.export_notes("D:/review/SQ010_dailies_notes")Los archivos se escriben en segundo plano: espere a que export.json esté al día antes de leerlo.
El Version Board (Versions) se rellena a partir de los nombres de archivo. Un pipeline también puede enviarlo ya preparado, con build-matrix, sin ninguna convención de nomenclatura. Un comando por secuencia; una entrada de departamento por cada versión que se ofrece (envíe el mismo departamento dos veces con dos versiones para rellenar su lista):
{"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"}}}]}Cada path que aún no esté en la playlist se le añade. get-matrix vuelve a leer el tablero. En Python: client.build_matrix(sequence, shots, matrix_id) y client.get_matrix().
La receta es la misma para cualquier tracker: consultar las versiones de una secuencia, agruparlas por plano y por departamento (el paso del pipeline), poner la ruta del medio en path y el identificador de la versión en version_id.
Sin script, cada clip añadido se lee según la regla del archivo naming_rules.json de la carpeta del perfil (véase Instalación e informática):
{"regex": "^([A-Za-z0-9]+)_([A-Za-z0-9]+)_([A-Za-z]+)_v([0-9]+)",
"groups": {"sequence": 1, "shot": 2, "department": 3, "version": 4}}Es la convención [Sequence]_[Shot]_[Department]_v[Version].[ext], por ejemplo SQ010_SH010_ANIM_v002.mov. Adapte la expresión regular y los números de grupo a la convención de su estudio. Un archivo que no coincide va a DefaultSeq / Base.
La ventana Tracker se conecta directamente a estos tres trackers. Para un despliegue, los sitios pueden prepararse en trackers.json, en la carpeta del perfil; ese archivo nunca contiene un secreto (una clave que parezca un secreto se descarta al leerla):
{"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 o flow. user: el correo electrónico para Kitsu, el usuario de la API para ftrack, el nombre del script para Flow.base_url debe empezar por https:// (http:// solo hacia localhost).proxy: vacío para el del entorno, direct para ninguno. ca_cert_file: un archivo PEM para una autoridad de certificación del estudio.path_map traduce las rutas del tracker para cada sistema; status_map asocia los estados del reproductor (pending, approved, not_approved) con los del tracker.BERNARD_TRACKER_<ID>_SECRET, donde <ID> es el id del sitio en mayúsculas con cada carácter distinto de A-Z y 0-9 sustituido por _: para demo-kitsu, BERNARD_TRACKER_DEMO_KITSU_SECRET. La variable prevalece.Desde un script, los comandos tracker-sites, tracker-connect, tracker-projects, tracker-playlists, tracker-load-playlist, tracker-publish (con dry_run para probarlo), tracker-download-media y tracker-cancel hacen lo que hace la ventana; sus resultados llegan como eventos. Una petición que lleve un secreto se rechaza.
Un clip cargado desde un tracker también conserva en x_tracking el tipo de tracker, el sitio, la tarea, la playlist, la referencia del medio y, una vez publicada, la huella de la nota enviada: una nota sin cambios nunca se publica dos veces.
Para ir más lejos: el manual completo, partes 6.4 y 6.6 (Help > User Guide en el reproductor), y los esquemas en la carpeta api/.