Proxy-workflow til RAW-footage: BRAW, R3D og CinemaDNG uden at knække conformen

Hvorfor RAW overhovedet skal have proxyer

Et konventionelt codec som ProRes eller H.264 gemmer færdige billeder. Et RAW-format gemmer det, sensoren så: en mosaik af enkeltfarvede fotosites plus de metadata, der skal til for at fremkalde dem. Hvidbalance, ISO og farvevidenskab lægges på ved afspilning, ikke ved optagelse. Det fremkaldelses-trin, debayeren, er hele charmen (grade fra sensordata, skift hvidbalance i post, behold highlight-latitude) og hele problemet: at afkode en frame betyder at rekonstruere den, og rekonstruktion koster GPU-tid ved hvert eneste scrub, hver parkering og hver afspilning.

Hvor meget det koster, afhænger af formatet og maskinen, men problemets form er konstant: en timeline der afspiller én strøm kamera-native RAW glat, begynder at tabe frames, i samme øjeblik en ekstra vinkel eller et speed ramp dukker op. Klipning er en rytmisk aktivitet, en klipper scrubber, parkerer, afspiller tre sekunder, scrubber igen, og medie der tøver ved hver af de bevægelser, lægger skat på hvert klip hele dagen. Løsningen har været standard siden filmæraen: klip på billige billeder, færdiggør på dyre. I moderne termer: klip på en letvægts-proxy, der bærer sin RAW-masters identitet, og skift tilbage til masteren til grade og finishing.

Hvad der tæller som en proxy: codec- og bitrate-tal

En proxy gør nytte ved at være let at afkode, ikke bare ved at være lille. Det udelukker det fristende valg, interframe-H.264/H.265, som er lille men rekonstruerer billeder fra nabo-frames, præcis det der får scrubbing til at føles som at vade, og det peger på intraframe-klippecodecs, hvor hver frame står alene:

• ProRes 422 Proxy: standarden i Mac-centrerede pipelines. Cirka 45 Mbit/s ved 1080p29.97, kald det 20 GB pr. kameratime: en fuld 8-timers optagedag i proxyer kan ligge på en billig SSD.
• ProRes 422 LT: cirka 100 Mbit/s ved 1080p, omkring 45 GB pr. kameratime. Det er pengene værd, når ”proxyen” også skal fungere som review-medie, og kunder skal dømme billederne.
• DNxHR LB: det tilsvarende valg i Avid-centrerede huse, i samme størrelsesorden.

Opløsning: fuld HD er rigeligt til at klippe UHD og opefter; proxyer i halv opløsning af 4K+-masters er standard. To egenskaber er derimod ikke til forhandling. Proxyen skal beholde masterens præcise frame rate: en 23.976-master med en ”24 fps”-proxy planter den samme 0,1 %-drift, som er beskrevet i guiden om frame rate-mismatch, i dit eget klippemedie. Og den skal beholde masterens antal lydkanaler, for nogle NLE'er nægter at koble en proxy på, hvis kanal-layoutet afviger fra originalen. Produktionslyd skal slet ikke igennem dette: broadcast-WAV'er er allerede klippevenlige, og deres BWF- og iXML-metadata skal rejse urørt.

Identitets-trioen: filnavn, timecode, reel

Alt det, der gør et proxy-workflow reversibelt, bor i tre felter:

1. Filnavn. Samme basenavn som masteren, anden endelse eller højst et _proxy-suffiks. Navnet er sådan, mennesker og relink-dialoger finder parret.
2. Start-timecode. Identisk med masteren, til framen. Timecode er sådan, NLE'en ved, at frame 1200 af proxyen er frame 1200 af masteren, og sådan en finishing-conform måneder senere trækker de rigtige frames fra kameraoriginalen.
3. Reel-/tape-navn. Identisk med masteren. Når to kort begge indeholder en C0001, er reel-navnet det eneste, der står mellem din conform og et relink til det forkerte klip.

Trioen er kontrakten, der lader et klip rejse: proxy-klippede timelines eksporteret som FCPXML, Premiere XML eller ALE refererer klip via navn, timecode og reel, og finishing-systemet opløser referencerne mod RAW-masterne igen. En proxy med strippet timecode eller et tomt reel-felt spiller fint i dag og fejler lydløst i præcis det øjeblik, projektet forlader din maskine. Anatomien i den overlevering er dækket i guiden om editor-pakken.

Format for format: hvad hver RAW-variant kræver

Blackmagic RAW (.braw)

BRAW er delvist debayeret i kameraet, og det gør det til det billigste RAW at afkode; moderne maskiner klipper ofte én strøm native. DaVinci Resolve læser det ud af boksen; Premiere Pro skal have et tredjeparts-plugin. Den asymmetri er argumentet for proxyer, selv når afspilningen føles fin: proxyen spiller alle steder, masteren gør ikke. Frame rate, timecode og reel-metadata er alle indlejret og overlever en Resolve-rendering urørt.

REDCODE RAW (.r3d)

R3D er wavelet-komprimeret og berygtet debayer-sulten i fuld kvalitet, og derfor tilbyder alle værktøjer der læser det, brøkdels-afkodning (halv, kvart, ottendedel). Brøkdels-afkodning er et fint monitorerings-trick og en dårlig proxy-erstatning: det brænder stadig GPU ved hvert scrub og hjælper ingen på en bærbar uden footagen. Både Premiere og Resolve læser R3D native; begge kan rendere dets proxyer. Klipnavne følger REDs reel-orienterede navngivning, og reel-navnet skal med over i proxyen.

CinemaDNG

Den akavede: ikke en videofil, men en mappe af DNG-frames, én fil pr. frame, med lyden som en separat WAV ved siden af. Kun nogle værktøjer ingester det ordentligt, Resolve er den pålidelige vej, og identitetshåndteringen kræver omhu: klippets ”navn” er i virkeligheden mappenavnet, og timecode bor i DNG-metadata, som en skødesløs transcode smider væk. Proxy-rendering er tæt på obligatorisk her; ingen NLE nyder at scrubbe en billedsekvens på 25 filer i sekundet.

Canon Cinema RAW Light (.crm)

Canons RAW kræver Canons plugin i Premiere, mens Resolve læser det direkte. Samme mønster som BRAW: nogenlunde native på ét system, plugin-afhængigt på et andet, så proxyen er den transportable kopi. CRM bærer sin timecode og sine klip-metadata internt; en korrekt rendering bevarer begge dele.

Den røde tråd: RAW-proxy-generering er et render-job i et værktøj, der reelt forstår formatet, i praksis DaVinci Resolve, Adobe Media Encoder med de rigtige plugins eller Compressor for de formater, den dækker. Workflow-spørgsmålet er ikke om der skal renderes, men hvem der passer køen: en der taster indstillinger ind i hånden for hvert kort, eller en automatiseret rundtur, der kommer tilbage korrekt navngivet og stemplet.

Render-opskriften

Uanset hvad der driver renderingen, er indstillingsarket kort og værd at hænge op:

• Én proxy pr. master, spejlet struktur: et PROXY/-træ der spejler kameramapperne, så parringen er indlysende for et menneske klokken 2 om natten.
• Codec: ProRes 422 Proxy (eller LT), fuld eller halv opløsning, samme frame rate som masteren.
• Filnavn = masterens basenavn. Ingen datoer foran, ingen versionsnumre, ingen ”oprydning” i kameraets navngivning.
• Timecode og reel kopieret fra masteren: de fleste render-værktøjer gør det som standard; verificér én gang pr. ny kameratype, og stol så på det.
• Lyd: samme antal kanaler som masteren, også selvom det er en scratch-mikrofon, du aldrig vil bruge. Attach-proxy-funktioner er kræsne med layoutet.
• Rene billeder, ingen burn-ins. Indbrændt timecode på en proxy, der er tiltænkt attach-workflowet, er fastbagt støj, du ikke kan fjerne igen.

Kobl proxyer på i NLE'en

Premiere Pro: markér masterne i Project-panelet, højreklik → Proxy → Attach Proxies, og peg på proxy-filerne. Knappen Toggle Proxies skifter hele timelinen mellem proxy- og fuldopløsnings-afspilning; eksporter bruger altid masterne. Nægter attach-dialogen at tage en fil, så mistænk lydkanal-layoutet først.

DaVinci Resolve: højreklik på klip i Media Pool → Link Proxy Media, og styr brugen under Playback → Proxy Handling. Resolve kan også generere sine proxyer fra samme menu, praktisk når Resolve i forvejen er din RAW-renderer, og resultatet lander med identiteten intakt.

Final Cut Pro: håndterer proxyer internt, genererer ProRes Proxy-kopier inde i library'et og kan siden 10.4.9 relinke eksternt leverede proxy-filer. Identitets-trioen betyder præcis lige så meget her; FCP's relink matcher på de samme felter.

At klippe på proxyer ændrer intet nedstrøms: timeline-referencerne opløses tilbage til masterne ved eksport eller conform, forudsat at trioen holdt. Det er hele tricket, og det er hele grunden til, at offline/online-workflowet overhovedet kan klippe på proxyer og finishe på originaler.

Fejlmønstre: sådan går gode proxyer i stykker

• Den omdøbte proxy. En velment ”oprydnings”-omdøbning, datoer, scenenumre, initialer, knækker filnavns-halvdelen af kontrakten. Relink bliver arkæologi.
• Den strippede timecode. Forbruger-transcodeværktøjer og watch-folder-scripts der som standard sætter ”start ved 00:00:00:00”. Klippet virker; conformen gør ikke. Ingen opdager det i ugevis.
• Proxyen med forkert rate. En 23.976-master renderet til en 25 fps-proxy, eller omvendt, driver mod sin egen lyd og klipper på frame-grænser, masteren ikke har.
• Interframe-”proxyer”. H.264 ved lav bitrate fylder halvt så meget som ProRes Proxy og scrubber som sirup, og det underminerer hele grunden til at proxyer findes.
• Dublerede reel-navne, eller ingen. To kort, begge A001, eller en renderer der lader reel-feltet stå tomt. Conformen vælger et klip; en gang imellem det forkerte.
• Proxyer af proxyerne. Når review-kopier bliver klippet i stedet for de identitetsbærende proxyer, formerer generationerne sig, og vejen tilbage til masteren forsvinder stille og roligt.

Her passer Launchr Post ind

Launchr Post behandler RAW-proxyer som en rundtur, ikke som et manuelt render-job. Når programmet ingester en optagedag og møder masters, der ikke kan proxy-genereres direkte, BRAW, R3D, Canon CRM og venner, styrer det dine egne værktøjer (DaVinci Resolve, Adobe Media Encoder eller Compressor), rækker dem præcis indstillingerne ovenfor og samler de færdige filer ind: samme basenavn, samme start-timecode, samme reel, spejlet mappestruktur. Proxyer du allerede har, genkendes og genbruges i stedet for at blive renderet igen, originalen i fuld opløsning er ét klik væk fra hvert klip, og editor-pakken, der forlader appen, refererer masters og proxyer, der er enige om hvem de er. Alt kører lokalt på din Mac.