VFX and compositing

Tracking, segmentation, roto, keying, simulation and compositing

• articleIs there an official public set of OpenEXR test images, what does each folder test, and what reuse terms does it state?
  At openexr-images e38ffb07 LICENSE and COPYING are byte-identical ILM 2004 BSD-style text with a portions-held-by-others clause; folder READMEs carry a different SPDX BSD-3-Clause / OpenEXR Project header; Damaged folder holds deliberately invalid files.
• article1916 practice and a proposal: which statements in Sargent's Ch. XLI-XLII are claims, which are invented examples, and what check can an agent run on a script that shows thoughts, memories, dreams or apparitions?
  Agent check, labelled 1916 practice plus a proposal. Sargent's chain for a past or thought scene is: restore time order; if not possible name the job (recall, explain a new fact, picture a thought); choose frame or fade vision; choose fade or dissolve; return to the host scene; write plain action for apparitions; and ask whether the viewer should know the fact early. Items 1-8 restate him; counting visions without new facts and flagging technique words in scene action are the agent's proposal, not his rules. Comparison by candidate ID only: C3-B289-S96-04 (Phillips's vision, rules deferred), C3-B307-S111 (cut-back notation shared with fade visions), C3-B125-S27 (transitions), C3-B303-S108-04 (visions and continuity).
• articleWhat are the 'apparition' and stop-camera effects in Sargent's Ch. XLII, when does he choose a dissolved apparition over a straight stop-camera one, and how does the writer script them?
  1916 practice (Sargent, Ch. XLII): an apparition is the sudden or gradual appearance of a person or object in a scene, made by stopping the camera, with or without a dissolve. For a thought of a person (Tom thinking of Mary) the figure is dissolved in and out; for a shock (Bess haunting Ben) a plain stop is used; objects may be dissolved in to remind rather than startle. The instruction to the writer is to state what happens in the scene and to name no technique; the director and camera operator supply it. He admits the Ben scene is troublesome and that every stop means a patched film. Examples are invented scripts.
• articleHow does Sargent (1916, Ch. XLI) separate the vision within the frame from the fade vision, when does he prefer each, and how is each written into a script?
  1916 practice (Sargent, Ch. XLI): two forms. The frame (straight, 'true') vision was a small second image inside the scene made by double exposure; the fade vision is a separate full-frame scene faded down and up, joined at splicing. He prefers the frame form for a person's thought and small effects, and the fade form for narrative visions with new facts that need a full stage; he says current practice favours the fade form for the director's convenience. Script form differs: the frame vision is one inline phrase 'VISION of ... — fades'; the fade vision takes three numbered entries ending 'Back to No. N', with a NOTE on the original scene if it is reused. Worked examples are invented scripts.
• articleIn Blender, what are the line options for a hand-drawn look (Freestyle vs Line Art with Grease Pencil), what does each produce, and what limits does the manual state?
  At Blender 4.5 LTS (manual path observed 2026-10-22), Freestyle is a render-time line engine that outputs lines as a render pass to be composited with Alpha Over, with documented limits (memory, no face-intersection edges, no Z depth). The Line Art modifier generates Grease Pencil strokes from a camera view, can be baked over a frame range, and has option-level fixes (overscan, chaining) for edge continuity. Shader To RGB (EEVEE only) plus Color Ramp is the manual's toon-shading hint. The manual pages read never mention an inverted-hull outline.
• articleWhich of CA-B309's Image Recorder colour-space statements (PNG/JPEG sRGB, EXR linear unclamped, tonemapping, dithering) do the official 5.1.7 pages state, reword, omit or contradict?
  Official pages state the conditions for the Linear, sRGB (unclamped) option exactly as CA-B309 summarises them: HDRP project, Source not Game View, EXR format. They also tell you to disable Tonemapping and Dithering to get unclamped values, and say the Recorder encodes EXR in 16 bits. Not stated officially: that PNG/JPEG are "forced" to sRGB (only implied by the EXR-only condition), any default for Color Space, the internal "HDR frame capture possible" test, and any statement that the Recorder embeds or omits colour tags. The two official pages disagree on UI paths for the same step (HDRP Default Settings vs HDRP Global Settings; Dithering under General vs Rendering).
• articleWhere is AI documented in 360-film attention work (saliency prediction, script-driven object highlighting, generated 360 scenes), and what evidence supports it?
  Two documented AI connections were found. (1) Sitzmann et al. adapt existing 2D saliency predictors to 360 panoramas by multiplying with a learned equator bias and propose saliency-based cut alignment (static-panorama data, not reproduced). (2) da Silva et al. (SVR 2024, arXiv 2026, CC BY 4.0) chain Grounding DINO and Segment Anything to find the object named in a text script and apply a vignette to it in a 360 tour; their text shows frames from a university video tour, one SAM failure, and a conclusion that 'user experience' improves, but the extract shows no user study or measurement supporting that claim. No source linking generated 360 scenes to viewer-attention outcomes was found in a bounded search.
• articleDo Maya, Unreal Engine and Houdini document ML-based deformation or simulation tools, and do they replace or complement the traditional rig/solver?
  Yes for deformation, and in every page read the ML model is trained on the output of the existing rig or simulation and complements it. Maya's ML Deformer approximates a complex deformer for posing and playback or crowds and keeps the original deformer for final rendering; Unreal's ML Deformer approximates deformations at runtime from data made in Maya or Houdini and recommends Neural Morph for flesh-like and Nearest Neighbor for cloth, and Epic says Fortnite used it for muscles and cloth; Houdini (docs labelled 22.0) has ML Deform, an ML Deformer recipe that approximates an expensive flesh simulation, and an ML Volume Upres recipe for pyro. No vendor page read documents ML replacing a cloth or fluid solver; Houdini ML cloth was not found in pages read.
• articleDo learned physics simulators stay stable over long rollouts and generalise beyond their training data, and what do the sources say breaks?
  Both papers report plausible rollouts far longer than the training trajectories (GNS: thousands of steps; MGN: 40,000 steps from a model trained on 400-step trajectories) after training on one-step targets, and GNS credits input-noise injection for this. Generalisation claims are specific: GNS to about 10x more particles and unseen shapes, MGN to a 20k-node windsock and wider angle/speed ranges with RMSE 11.5 to 12.4/13.1. Failures are also stated: GNS rigid block deformation in vigorous shaking and a stuck-goop bad seed; MGN cloth decoherence after about 50 steps; a baseline GNS without mesh-space features is unstable on cloth. A later PyTorch re-implementation README warns accuracy may degrade over time and extrapolation in time should be avoided.
• articleWhat is a 'learned physics simulator' such as DeepMind's GNS or MeshGraphNets, what does it take as input and predict, and what is it trained on?
  In the two DeepMind papers a learned simulator is a graph neural network trained, per scenario family, on trajectories produced by a conventional solver (MPM, SPH, PBD, ArcSim, COMSOL, SU2). It reads the current state (particles or mesh nodes with a short velocity history), predicts per-node acceleration, integrates it with an Euler step, and is applied repeatedly to roll out a trajectory. It is a fast surrogate of the solver it was trained on, not a model that discovers physics; the training supervision is one-step prediction.
• articleWhat do open papers measure for monocular and few-camera markerless capture against reference systems, what is the evidence for commercial tools such as Move AI, and what does it imply for animation production use?
  Open results are research-method numbers, not commercial-tool numbers: on Human3.6M (marker-based) a monocular lifting model reports 46.8 mm MPJPE from detected 2D keypoints (37.2 mm from ground-truth 2D); on in-the-wild 3DPW WHAM reports 57.8 mm; on EMDB global trajectories WHAM reports 354.8 mm W-MPJPE100, 6.0 % root-translation error and 4.4 mm foot sliding. A 2022 clinical review gives 40-60 mm joint-centre differences and up to 30 degree ankle-angle differences for monocular methods, and OpenCap (two or more phones) reports 4.5 degree joint-angle MAE against skin-marker capture, with the authors noting that skin-marker error itself limits what can be shown. No open independent validation of Move AI or Flow Studio mocap against marker-based ground truth was found (bounded Europe PMC search), and Move's own accuracy page gives no numbers. Implication (synthesis): treat markerless output as animation reference or blocking requiring cleanup of root drift and foot contact, not as ma...
• articleWhat footage will Autodesk Flow Studio (Wonder Studio) accept for character replacement, clean plate and camera tracking, and what shooting rules does the documentation give?
  At help.wonderdynamics.com pages stamped "Updated on October 19, 2026", Flow Studio documents hard limits (.mp4/.mov, 2 minutes, 15 shots, hard cuts only), partial support for occlusion, no support for object or actor interactions, a standalone Clean Plate tool (humans only, up to four actors, hidden background must be visible at some point) and a standalone Camera Track tool (no variable zoom; best with wide shots, parallax, distinctive surfaces). No accuracy figures are published on these pages; the limits are vendor-documented constraints, while claims such as the Live Action Easy page wording ("let our advanced AI handle all the heavy lifting") are vendor claims (E16).
• articleWhat can I give Move.ai (Move One single camera, Genesis multi-camera), what do I get back, and what capture conditions do the Move docs require?
  At docs observed 2026-10-22 Move documents two products: Move One (single phone camera or an uploaded .mp4/.mov/.avi up to 1 GB, 30 s free / 60 s paid clips, credit-metered per person-second) and Genesis (6-12 calibrated cameras, on-premise). Outputs are FBX/USDC/USDZ/Blender (Move One) and FBX/BVH/GLB/USDZ/Blend/C3D/JSON plus preview video (Genesis). Capture rules are practical (full body visible, locked camera, contrast clothing, no mirrors) and the docs publish no accuracy numbers; capability tables are vendor specifications, not measurements.
• articleWhich artefacts do the original papers and the vendor documentation themselves report for AI upscaling and frame interpolation (invented detail, smearing, ghosting, occlusion errors, flicker)?
  The Real-ESRGAN paper reports twisted lines, GAN-training artefacts and failure on out-of-distribution degradations; RIFE reports ghosting by competing methods and lists its own limitations (two-frame input, PSNR/SSIM-centred evaluation); FILM states disocclusions force a model to hallucinate pixels and reports unnatural deformations for extreme motion. The Topaz documentation (vendor) lists strobing on reflective water, distortion of patterned caustics, wobble on dense parallax, per-frame detail differences in Theia, flicker of small repeated patterns and mis-read small text in Starlight HQ. None of these sources reports a measured artefact rate for finishing use; the vendor statements are not tests.
• articleWhat documented checks show that a captured lighting HDRI is complete (no clipped sources, full coverage) and calibrated (exposure and colour tied to reference), and what do the manuals leave unsaid?
  No source read gives a numeric acceptance test. The documented checks are scattered: the original paper shows a radiance map stepped down 7 stops with no saturation and compares a rendered local scene with the photograph (differential rendering); a later paper states that diffuse and mirrored estimates must agree if no light clips; a practitioner says the darkest frame must have no clipped sources; a work-in-progress CAVE page neutralises HDRIs with a bracketed chart whose 18 percent patch sets base exposure. Vendor manuals read (Blender, VES guide) state use or purpose only. The checklist assembled here is a synthesis proposal, not a standard.
• articleWhat lighting reference should be shot at a setup so CG can be lit to match, and what does each item (grey ball, chrome ball, colour chart) tell the lighting artist?
  Two practitioner pages and the VES guide agree on the kit: a grey ball (light direction, intensity, shadow), a chrome ball (where lights, camera and set are) and a colour chart (to set exposure and white balance), shot where the CG will sit and slated to the shot. The VES guide (a standards-body list) names charts, HDRIs and material props but not the procedure; the procedure and cautions come from practitioners. Cautions: painted balls may not be neutral, the chart is for exposure/white balance not colour correction, and real-world bounce on the reference should not be compensated by editing shaders.
• articleIf a shoot needs tracking markers, what shape, size, colour, count and placement do practitioners and tool manuals recommend, and where do they disagree?
  Two practitioner accounts (2016) agree markers are a fallback and should be small, simple and at different depths, but disagree on numbers: one says at least nine dots visible at any moment, the other at least seven. Marker size is given only relatively (just visible in the widest shot) plus one anecdotal tape size (half-inch squares). The tool manuals read (Nuke, Blender, SynthEyes) describe what the software needs from features (non-coplanar, high contrast, not reflections, mask movers) but state no physical marker size, spacing or count.
• articleBefore a camera track, how much do I need to know about the lens focal length and sensor size, and what do I enter when I do not know them?
  Both tool manuals read treat focal length and sensor (film back) as inputs to give the solver when known and as values to be estimated when not. Nuke CameraTracker offers five focal-length modes (Known, two Approximate, two Unknown) and says approximate values are refined in the solve; Blender can refine focal length but needs approximate starting values. Two practitioner/trade sources say nominal lens and sensor numbers are only starting points (manufacturer tolerance, cropped sensor areas, stabilisation), while Nuke says accurate physical data gives a better track; the sources are not directly comparable and no source here measures the error.
• articleWhat do the 4D reconstruction and generation papers say about relighting, editing, topology and render cost, i.e. the limits that matter for VFX, volumetric capture or virtual production?
  Across nine primary papers (HTML bodies, before reference lists) no text contains the words relight, albedo, BRDF or virtual production; lighting appears only as scene variation to be fitted (Real-time 4DGS) or as an uncharacterised factor (DyCheck). Gaussian colour is stored as spherical-harmonic coefficients, so appearance is baked and view-dependent; relighting is therefore not a documented capability of these systems. Editing is demonstrated for rig-captured persistent Gaussians (edit propagation, object insertion, camera attachment) and described as naive transformation in 4D-GS. Topology: persistent Gaussians give point correspondence over time, DG4D gives a per-frame obj mesh sequence, and no read source reports a stable mesh topology. Render speed is high for small scenes on a consumer GPU (author-reported tens to hundreds of FPS) but is tied to Gaussian count, resolution and deformation network size; clips are seconds long and scale to large scenes is a stated limit. Produc...
• articleHow are chrome/grey balls and HDRI light probes captured on set for CG lighting, and what goes wrong with each?
  Practitioner sources describe a two-tier approach: a half-chrome, half-matte-grey ball shot at each setup (fast, shows light direction, balance and sheen) and, when the set can be held, a bracketed HDRI taken where the CG object will sit. The original light-probe paper adds the failure cases: a single low-dynamic-range ball photo mis-lights the CG, and a single ball image shows the camera, its own support and samples the area behind it poorly; two images 90 degrees apart removed the camera in the authors' setup. Practical advice from the talk notes: long lens, whole sphere in focus, ball exactly where the CG object will be, and stop crew from striking lights.
• articleWhich public RenderMan docs page defines points:shape, falloffshape, falloffpower and camerafacing for Points?
  The RenderMan for Maya 26 primitive-variables page lists falloffpower only ('used to create fuzzy particles') with no value range, and nothing on points:shape, falloffshape or camerafacing.
• articleIn Blender's Keying node, what exactly do the Tweak (black/white level, garbage and core matte) and Edge stages and the Postprocess stages do, in what order, and what do their parameters mean at the boundary values?
  Blender's Keying node runs in a fixed order: optional chroma blur of the input, matte computation, a tweak stage, then optional blur, dilate/erode and feather of the matte, then the despilled image. In the tweak stage a pixel is an 'edge' when fewer than 90% of its (2r+1)^2 neighbours are within the edge tolerance (strict less-than). Non-edge pixels are remapped by black/white level, the garbage matte is subtracted, and the core matte is applied last, so core wins over garbage. The Edges output comes from that stage, before blur, dilate and feather. Edge Tolerance 0 makes every pixel an edge, which disables level remapping. A defect (in the commit read and still on main on 2026-10-22) sets the white level from the black-level input, so the shortcut that should skip the tweak at default levels never fires. By curator reading this wastes an extra full-image pass rather than changing the result (not run).
• articleWhat concrete timing and easing values do Material motion tokens give, and what does Apple's HIG say qualitatively about motion?
  Material Components for Android defines 16 motion duration tokens from 50 ms to 1000 ms and seven easing curves (standard cubic-bezier(0.2, 0, 0, 1); emphasized-decelerate (0.05, 0.7, 0.1, 1)), and says duration should grow with how far the animation travels. The doc read doesn't mention reduced motion. Apple's HIG gives no numeric timings. It asks for brief, purposeful motion that is optional (not the only way to convey information) and warns against sustained oscillation around 0.2 Hz, which people are especially sensitive to.
• articleHow do I make UI animation respect reduced-motion settings, and what do W3C and MDN require?
  Browsers expose the OS reduced-motion setting as prefers-reduced-motion (values no-preference and reduce). 'Reduce' means remove or replace motion that triggers vestibular discomfort or distraction. WCAG 2.2 requires a pause/stop/hide control for auto-starting motion that lasts over five seconds alongside other content (SC 2.2.2, Level A). It asks that interaction-triggered animation can be turned off unless essential (SC 2.3.3, Level AAA), and technique C39 meets 2.3.3 with the media query. Media Queries 5 is still a Working Draft (February 2026).
• articleWhat coordinate conventions (normalised range, origin, pixel centre, bit depth, premultiplication) do Nuke's STMap documentation and the openfx-misc STMap/IDistort/LensDistortion code use, and what do they leave unstated?
  Nuke documents STMap UVs as the absolute source position normalised to 0-1, with (0,0) the bottom-left corner and (1,1) the top-right corner of the input, plus a premultiplied option for renderer output. It does not state the pixel-centre rule or bit depth. The open-source openfx-misc implementation makes the convention explicit: u,v map to the source rectangle with (0,0) at the lower-left corner of the first pixel, IDistort offsets sample at pixel centres (+0.5), UV input must be float, and there are unpremultiply and offset/scale options. A pixel-exact identity STMap therefore stores (x+0.5)/W and (y+0.5)/H (inference).
• articleWhich YCbCr conversion does Blender's Chroma Key use, what range does it assume, and where else in the Keying node does the same conversion appear?
  Blender's Chroma Key and the Keying node's chroma pre-blur convert RGB to studio-range BT.709 YCbCr (Y = 0.183R + 0.614G + 0.062B + 16, chroma centred at 128, computed on 0-255-scaled values and divided by 255), the same constants on GPU and CPU. Chroma Key rescales Cb/Cr with v*2-1, so neutral grey lands at +1/255 (about +0.0039) rather than 0. The algorithm is credited to Video Demystified, ch. 7. The CPU helper's own FIXME says its 16-235 range comment must be wrong.
• articleWhen shots are pulled for VFX as EXR plates, which header attributes can carry timecode, reel, frame rate, camera and framing, and what do the ACES/AMF documents say about carrying colour intent with plates?
  An EXR plate header can carry optional editorial attributes (timeCode, reelName, framesPerSecond - assume 24 fps if absent - keyCode, imageCounter), an ASC framing decision list, camera identity and state, and acesImageContainerFlag (ST 2065-4 layout); renderingTransform and lookModTransform are deprecated. AMF is the ACES document for colour intent: it can travel with plates to describe how to view each one, but carries no timeline data (EDL/ALE may reference it), no demosaic settings, and an optional clipId link to material.
• articleWhat changed in GIMP's colour management, bit depth and layer/blend support between 2.10, 3.0 and 3.2, and which statements in the manual are out of date relative to the release notes?
  Per GIMP's own release notes: 2.10 brought up to 32-bit per channel processing, linear and perceptual variants of most blend modes and core colour management (LittleCMS 2, ICC v4); 3.0 broadened RGB colour-space support, laid groundwork (not shipped modes) for CMYK and LAB, added float-precision text colours and a PSD export dialog that can save CMYK profiles; 3.2 added Total Ink Coverage in the CMYK selector, an Overwrite paint mode, and link/vector layers. The manual text served for 3.0 still says three image modes, 256 levels per channel (source file last noted as updated for 2.10.18) and an sRGB-by-default recommended working space, so manual and notes are out of step.
• articleWhat does Krita document about bit depth, ICC versus OCIO colour management, HDR display and HDR-safe blending, and what changed in 5.2, 5.3 and 6.0?
  Krita works from 8-bit integer (its lowest depth) through 16-bit integer, 16-bit float and 32-bit float, and runs two colour-management systems (lcms2 for ICC, OCIO for LUT workflows). HDR display arrived in 4.2 on Windows and Linux; 6.0 adds Wayland HDR via a Rec 2020 PQ canvas surface, although 6.0.0 defaults to XWayland unless QT_QPA_PLATFORM=wayland. 5.3/6.0 rechecked blend modes so HDR-capable modes no longer clip; Krita 6 is early access; 5.2 changed CMYK blend modes to match Photoshop (config toggle). 5.3.4 and 6.0.4 shipped 2026-09-15.
• articleWhat do Inkscape's 1.3, 1.4 and 1.5-draft release notes and the 1.4.4 source say about colour spaces, CMYK/ICC handling, blend modes and PNG bit depth?
  Inkscape colour handling changed incrementally: 1.3 restored opacity and 16 blend modes in the Layers dialog and added an opt-in OKLch picker that still writes RGB hex (and cannot read OKLch colours); 1.3 PDF import keeps CMYK information via ICC colour-profile support; 1.4 added limited CMYK palettes and better CMYK-to-RGB conversion without an ICC profile; the 1.5 development notes list a new colour management system. In 1.4.4 source, PNG export offers 16-bit RGB/RGBA/Gray options, but for 16-bit colour PNGs the writer records sBIT 8 per channel, so the files declare only 8 significant bits. 1.4.4 was released on 2026-05-06; the wiki index still calls it the next bugfix release.
• articleWhat did posts 21-46 of ACEScentral thread 'ACES 2.0 Output Rendering' report about saturated-light test renders, rendering primaries and the red/pink tilt of ACES 2.0?
  Thread 5770 posts 21-46 (2025-04-21 to 2025-08-10) concern rendering primaries rather than blue artefacts: multiplying sRGB red by sRGB blue gives zero, but doing the multiplication in ACEScg and converting back gives a small non-zero purple, so the choice of rendering primaries changes light interaction (green vs purple ball test reproduced by a second user in Blender); the last posts report ACES 2.0 tilting bright reds toward pink-salmon compared with OpenDRT. No fix is concluded.
• articleWhat does a Houdini Vellum cloth simulation carry into an Alembic file for rendering, and which attribute and packing details can change on export?
  Houdini's Alembic ROP writes only the extra attributes whose names match its point/vertex/primitive/detail patterns and turns primitive groups into face sets, which Alembic supports only on polygon and subdivision meshes; Vellum Unpack depends on the vellum_type attribute and does not update id attributes properly, so ids and constraint context should be checked before baking cloth to Alembic, which stores results rather than the simulation.
• articleAt the library level, what exactly do ImageBufAlgo premult, unpremult and repremult do at alpha 0 and 1, and how do file-format reader/writer hints for PNG and TIFF interact with them?
  In OpenImageIO, unpremult leaves pixels with alpha exactly 0 or 1 untouched; premult leaves alpha-1 pixels untouched and multiplies everything else (so colour at alpha 0 becomes zero), whereas repremult also leaves alpha-0 pixels untouched, preserving colour carried under zero alpha (e.g. after an unpremult round trip).
• articleHow do the despill formulas in Blender (Color Spill and Keying) and Natron/openfx-misc (Despill) compare, and what do openfx-misc's ChromaKeyer documents cite?
  Blender's Color Spill subtracts from the spill channel the positive excess factor*spill - limit_strength*(average of the limit channels), and Natron's Despill (credited to Wright's Digital Compositing for Film and Video, section 4.5) builds a comparable spill map with mix and expand controls and can also add red and blue into the spill area; equivalence under matched parameters is producer synthesis.
• articleWhat chroma-keying formulas do Blender's Chroma Key and Keying nodes implement, and what failure cases do the manual pages document?
  Blender's Chroma Key works in a rotated chroma plane (after Video Demystified ch. 7): pixels within the minimum angle of the key colour get alpha 0 and others 1 - key/falloff; the Keying node builds a saturation matte (opaque if the pixel's dominant channel differs from the screen's, transparent if as saturated as the key, graded between) and treats any pixel brighter than 1.0 in all channels as opaque because the screen is assumed not overexposed, so overexposed screen areas will key as foreground.
• articleWhat does Blender's compositor define for premultiplication, Over, Disjoint Over, Conjoint Over and alpha conversion, and where do its code comments and manual disagree with other sources?
  Blender's compositor (f46990f) implements Alpha Over as premultiplied Over (fg + bg*(1-fa)), optionally premultiplying a straight foreground first; Disjoint Over un-premultiplies the background when fa+ba >= 1; Conjoint Over returns the foreground when fa > ba, else fg + bg*(1-fa/ba), with a source comment correcting the blog formula it cites; Convert Alpha un-premultiplies by dividing by alpha except at alpha exactly 0, where the pixel passes through unchanged.
• articleWhich Porter-Duff operators exist, what are their fraction (Fa, Fb) definitions, and how does premultiplication enter the formulas in the 1984 paper and in W3C Compositing and Blending Level 1?
  The W3C Compositing and Blending spec (CRD 2024) restates Porter-Duff: each operator is a pair of fractions (Fa, Fb) applied to straight source and backdrop colours weighted by their alphas, producing premultiplied output; source-over is Fa = 1, Fb = 1 - alpha_s. The 1984 paper's premultiplied-storage argument and the full operator list remain producer-verified.
• articleFrom camera card to final delivery, which of timecode, reel/clip name, colour intent and lens data does each handoff have a documented place for?
  Across the pipeline the slots differ: an ASC MHL manifest records file paths, sizes and hashes (optional custom metadata), not timecode or reel; AMF records the ACES colour pipeline and explicitly carries no timeline metadata such as edit points; OpenEXR offers optional timeCode, reelName and framesPerSecond attributes; the IMF Application 2E public page constrains colorimetry and references ST 2086 mastering-display metadata, with no timecode, ACES or CDL terms. Clip identity and timing therefore travel in ALE/EDL/EXR headers, colour intent in CDL/AMF/LUT sidecars, and lens data only as far as the camera records it.
• articleI am new to review: what is a timeline marker or annotation in OTIO, RV, Kitsu and an EDL, and which one holds a frame-accurate note?
  A frame note is stored differently in each tool: RV keeps per-frame paint and markers as node properties, Kitsu keeps text comments as their own records while drawn annotations live as JSON on the preview file, and a CMX3600 EDL can carry only comment lines such as '* LOC: timecode colour text'; no shared note identifier links them, so round trips need a mapping table.
• articleWhich exact node, component and property names in an Open RV v4.0.2 session carry pen strokes, text and shape annotations, and what is documented versus only in code?
  The RV reference manual documents pen and text component properties (width, gauss/circle brush, normalised points, join, cap, over/erase mode, start frame and duration; text position, colour, spacing) under names pen:id:frame:user; the interactive Mu mode actually appends the user and a process id, and Python/OTIO writers use the literal 'annotation' (CA-AM-0040). The node code also handles rect, ellipse, arrow and line components not listed in the table (producer reading).
• articleDoes an Open RV .rv session file keep my drawn annotations and text notes, and where do they live in it?
  Open RV .rv session files are GTO files, and RVPaint nodes store per-frame annotations as named components plus an order stack and a redo stack per frame, so annotations travel inside the session file and can be read with GTO tools.
• articleWhat do NanoVDB and vdb_tool documentation say about runtime use and frame-sequence processing?
  NanoVDB is a read-only, linearised GPU/CPU-friendly copy of an OpenVDB grid that can only be built with createNanoGrid or GridBuilder, so editing happens in OpenVDB; OpenVDB's vdb_tool reads and writes .vdb and .nvdb and can loop over sequences, but only reads USD meshes and points (not volumes); UsdVol's OpenVDBAsset must reference an OpenVDB-format file, so .nvdb files are not valid there.
• articleWhat do the OpenEXR deep-pixel document and the Theory of Deep Samples derivation say about splitting, merging and tidying overlapping volume samples, and what assumptions do the formulas rest on?
  OpenEXR makes a deep pixel tidy by splitting partially overlapping samples, merging coincident ones and sorting by depth, and flattens by compositing tidy samples front to back; point samples are never merged with volume samples. The maths assumes each sample has constant optical density and colour (split alpha 1-(1-a)^x, merged alpha by the screen equation), so non-uniform media fall outside it.
• articleAcross the capture-to-render chain, which time base, unit and naming assumptions must be written down because no format in the chain carries them for the next step?
  Across motion and render handoffs, time, units/axes and names are carried differently by each format (ARKit metres; Live Link Face timecode in recordings; Alembic sample times; the USD Alembic reader assuming Y-up and leaving units unset; UsdRender and EXR names as site conventions), so each step needs a user-authored mapping; this is the producer's synthesis over verified statements.
• articleWhen animation leaves the DCC as UsdSkel or an Alembic cache, which of joint order, bind/rest pose, topology, velocity, time base and units are stated by the specs and what does the Alembic-to-USD reader do with the rest?
  UsdSkel stores joints in an ordered list with world-space bind and local-space rest transforms (rest may be omitted only with a complete, non-sparse animation; animation joint order may differ from the skeleton's). Alembic marks topology changes by full samples and stores explicit time samples; OpenUSD's Alembic reader takes the frame rate from archive metadata, assumes Y-up when none is authored and never sets metersPerUnit, so units and up-axis need checking after conversion.
• articleWhich Open RV v4.0.2 render-path code decides which paint properties are read, and what happens to extra per-stroke properties?
  Open RV's PaintIPNode recompiles drawings when a pen/text/rect/line/arrow/ellipse/frame component changes and reads a fixed property list; uuid, softDeleted and undo/redo data are stored in the session but never read by this node, so they have no render effect here (deleted shapes disappear because they are left out of the order list).
• articleHow do the properties written by the Python OTIO annotation hook differ from those written by the Mu Annotate mode for the same pen stroke or text box?
  The OTIO import hook writes pen strokes with fixed constants (debug 1, join 3, cap 1, splat 0), copies uuid and soft-deleted state from the OTIO layer, treats invisible layers as deleted and leaves them out of frame:N.order, and writes no undo/redo stacks; the interactive Mu mode generates uuid4 ids and keeps per-user undo/redo stacks. Imported drawings therefore are not undoable like hand-drawn ones.
• articleWhat does OpenEXR say deep images represent and how are deep IDs and subsample alpha meant to interchange between tools?
  Splitting an OpenEXR deep sample recomputes alpha as 1-(1-alpha)^x, which equals un-premultiplying and re-premultiplying colour, with alpha 0 handled as a special case. Deep IDs store 32-bit or paired 64-bit hashes per sample (MurmurHash3 suggested, not required) with a manifest, keeping per-sample colour and alpha so isolated objects keep correct edges; Cryptomatte stores coverage only.
• articleAre blend-mode formulas identical in W3C Compositing 1, PDF and OpenRaster, and in what colour encoding are they evaluated?
  W3C Compositing 1 defines blend modes as a mixing function applied in place (weighted by backdrop alpha) followed by a Porter-Duff composite, with exact formulas (soft-light uses a polynomial below Cb 0.25 and sqrt above); OpenRaster adopts these by reference. Neither text says whether blending happens on encoded or linear values; PDF 1.7 makes the blending colour space explicit (producer reading).
• articleWhy do transparent edges fringe after resizing or blending, and does my library premultiply for me?
  Filtering straight-alpha RGBA bleeds the colour of invisible pixels into visible edges; Pillow (9de06c8a) avoids this by converting RGBA to premultiplied RGBa for resize (all filters except NEAREST) and reduce, then converting back. Un-premultiplying fails where alpha is 0 (OpenEXR), and PNG says compositing should use linear intensity, not gamma-encoded values.

More