Color and imaging science

Color management, HDR, transforms, calibration, film looks and image quality

• articleWhat does ARRI claim about REVEAL colour science for SDR/HDR output, and which of those claims are documentation versus measurement?
  Corrected 2026-10-24 - see C3-B1109-01; the original statements below are kept for history and are superseded where the correction says so. ARRI's REVEAL page and FAQs state that the REVEAL chain ends in LogC4/AWG4 and that LogC4 display LUTs must be used; ARRI claims the same colour tones in SDR and HDR and offers no in-camera ACES workflow. These are vendor statements; the pages read give no measurements, and the HDR FAQ is an older page referencing 2017 display technology.
• articleHow many bracketed exposures, at what spacing and range, and with what starting camera settings do practitioners shoot for a lighting HDRI, and where do they disagree?
  Corrected 2026-10-24 - see C3-B1085-03; the original statements below are kept for history and are superseded where the correction says so. Three practitioner sources give bracket recipes: CAVE (5 brackets at 3 stops or 7 at 2), Xuan Prada (5-7 exposures, 3 stops apart) and Greg Zaal (5 at 3 EV, but at least 5 at 2 EV and 9 for unclipped light). By simple arithmetic (synthesis) these span about 12 EV to 16-18 EV. All start with a fast shutter so light sources are not clipped, shoot RAW, fixed manual settings and a fisheye rotated in steps. They disagree on how many exposures the balls and chart get (3 vs 7) and where the chart sits. No vendor or standards document read gives numbers; the VES guide only lists HDRIs.
• articleWhich output formats, compression levels and transparent-background settings do the OpenAI image generation and edit endpoints document, and which combinations are valid?
  Corrected 2026-10-24 - see C3-B955-05; the original statements below are kept for history and are superseded where the correction says so. Problem. Choosing format, compression and background so a generated asset keeps alpha and loads fast. Conditions. GPT image models on the Image API (generations and edits). Method. output_format is png (default), jpeg or webp. output_compression is an integer 0-100 that applies only to jpeg and webp; the openapi schema gives it a default of 100 on edits, and the generation schema constrains it with minimum 0 and maximum 100. The guide says jpeg is faster than png when latency matters. background is transparent, opaque or auto (default); transparent requires png or webp output (jpeg has no alpha). The spec says gpt-image-2.5-sunburst and -flare support opaque and transparent backgrounds, while for gpt-image-2 and gpt-image-2-2026-04-21 transparent support is 'in preview'. Failure modes. transparent with jpeg is outside the documented combination. ...
• articleIn RED's public IPP2 documentation, where in the camera and in post is the output transform applied, and is it baked into the recording or kept as metadata?
  Corrected 2026-10-24 - see C3-B1042-02; the original statements below are kept for history and are superseded where the correction says so. RED's public camera guides (DSMC2 HELIUM 955-0171 V7.1, V-RAPTOR 955-0199 V1.2) describe IPP2 as recording REDWideGamutRGB/Log3G10, with grading controls (CDL) separate from three output settings (Output Color Space, Output Tone Map, Highlight Roll-Off). For R3D the guides say the output settings are stored as metadata and can be changed non-destructively in post; for ProRes/DNx proxies the HELIUM guide says some settings are baked in (the page does not list which in the text read). This answers the 'where is the look applied' part from non-confidential pages only.
• articleWhat is HDR10+ dynamic metadata, what does it contain, and what happens on a display or tool that does not support it?
  Corrected 2026-10-24 - see C3-B1058-02; the original statements below are kept for history and are superseded where the correction says so. HDR10+ is HDR10 (PQ, BT.2020, static ST 2086 + optional MaxCLL/MaxFALL) plus per-scene or per-frame metadata standardised as SMPTE ST 2094-40 (Application #4). The metadata carries scene statistics (MaxSCL per colour component, average maxRGB, a percentile distribution of maxRGB) and optionally a Bezier tone curve with a knee point and a targeted display luminance. It travels as an ITU-T T.35 SEI message in the video stream, so a non-supporting display ignores it and falls back to HDR10. The public statements about licensing differ in tone: HDR10+ Technologies says no licensing fees; the SMPTE standard's foreword records claimed IPR licensable on reasonable terms.
• articleWhat do the BBC File v6.0.2 (2026) and Channel 4/UK DPP File v5.2 delivery specifications say about up-converted, lower-resolution and frame-rate-converted material?
  Corrected 2026-10-24 - see C3-B1042-03; the original statements below are kept for history and are superseded where the correction says so. Both specs accept up-converted SD archive provided it meets the full technical requirements; both cap lower-resolution material at 25 percent of programme duration unless agreed; both require motion-compensated standards conversion and forbid simple timeline conversion. The Channel 4 spec adds that up-converted SD must look no worse than the original, requires removing half-line and blanking artefacts (hence a slight zoom), and requires agreement in advance for 50p to 25p film-motion conversion. In the passages read neither spec has a field or rule for declaring up-conversion; neither mentions AI (bounded: BBC text searched for "declar", "artificial", "generative" and the "AI" token with 0 hits; Channel 4 text searched for "declar" with 0 hits).
• articleWhich ffprobe and MediaInfo fields tell me a file's colour tags and range, and what are the value names?
  Corrected 2026-10-24 - see C3-B1054-01; the original statements below are kept for history and are superseded where the correction says so. At FFmpeg commit 9047fa1b, ffprobe stream output uses the keys color_range (unknown/tv/pc), color_space (e.g. bt709, gbr, unknown), color_transfer and color_primaries, and prints unknown when unspecified; a real user paste confirms these keys. MediaInfoLib (commit 153ad67a) lists colour_range, colour_primaries, transfer_characteristics, matrix_coefficients and colour_description_present, with _Source and _Original variants. Nothing was run; the checklist below is derived from these sources.
• articleHow do I record Unity AOV passes for compositing (multi-part EXR, unclamped linear, motion vectors) and what breaks with TAA?
  Problem. Handing a real-time Unity render to a compositor needs separate passes. Conditions. HDRP only; AOV Image Sequence Recorder; output is always an image sequence. Method. Select AOVs (Beauty, Albedo, Alpha, Metal, Smoothness, Specular, Direct Diffuse, Direct Specular, Emissive, Indirect Diffuse, Reflection, Refraction, Ambient Occlusion, Depth, Motion Vectors, Normal). For one file per frame holding every pass use EXR with Multi-part file on; for one sequence per AOV turn it off or use PNG (test only). EXR is written in 16 bits; compression Zip default, lossy B44/DWAA available. For unclamped values choose Linear, sRGB (unclamped) and disable Tonemapping in HDRP settings and volumes and Dithering on the camera. Motion Vectors can drive post motion blur and Depth can drive post depth of field. Failure modes. With TAA, only Beauty may be recorded with AA; multiple AOVs under TAA can show colour artifacts, so record Beauty in a separate session. ActiveCamera is unavailable, use M...
• articleHow does Unity Recorder accumulate path-tracing samples, how do I get clean frames without motion blur, and why do frames come out overexposed?
  Problem. Path-traced HDRP frames are noisy until sub-samples converge. Conditions. HDRP with ray tracing set up and a path tracing override in the scene; path-tracing accumulation requires DX12 (Recorder 5.1.7 docs). Method. Samples is the number of sub-frames per frame and each sub-frame captures one path-tracing sample. With Shutter Interval above 0, samples are accumulated only inside the interval and the Shutter Profile weights them; with Interval 0 time does not advance, Shutter Profile is not applied, and all Samples converge one static moment (no blur). If noisy, raise Samples. Failure modes. With automatic Exposure and Adaptation set to Progressive, exposure is re-evaluated each sub-frame and noisy early sub-frames can overexpose the result; set Exposure Adaptation Mode to Fixed. A short Shutter Interval reduces path-tracing samples accumulated; the documented workaround is to disable path-tracing overrides on volumes. Limitations. HDRP path-tracing limitations also apply. V...
• articleWhat does Comfy's own upscaling handbook say about choosing and preparing upscalers for image and video, and how strong is that evidence?
  Problem. Choosing between conservative and creative upscalers and avoiding wasted passes. Conditions. Comfy blog post dated 2026-02-06; vendor-authored, qualitative side-by-side comparisons, includes partner-node (paid API) and local open models. Method. The post's takeaways: choose by use case (portrait skin, product photography needing faithful labels and edges, landscapes, illustration, archival video, CGI); conservative models for faithful materials and text; do not rely on upscaling to fix common AI artifacts; for SeedVR2 downscaling to about 0.35 megapixels with ImageScaleToTotalPixels before upscaling gives better results (its claim); video options named include SeedVR2, FlashVSR, HitPaw, Topaz Astra and Wan 2.2 upscale, with workflow downloads provided. Failure modes. Hallucinated detail from creative models; generation time varies strongly by model and hardware (the post lists per-model times without hardware or n for most items). Limitations. No objective metrics (PSNR/LPI...
• articleWhich ICC profiles are public for testing colour management, and what permission text accompanies each?
  Corrected 2026-10-23 - see C3-B686-04; the original statements below are kept for history and are superseded where the correction says so. The ICC Profile Library says that where ICC owns a profile it may be copied, distributed, embedded, made, used and sold without restriction, but altered versions must drop the original identification and not be misrepresented; the sRGB v4 preference profile page grants use, copying and distribution only if the file is not changed (including its copyright notice). The two texts differ on modification, so one 'ICC profile licence' label would be wrong. Little-CMS's root licence is MIT, with no separate note for its testbed files (producer).
• articleWhat parameters and equations define ACES 2.0 chroma compression, gamut compression and the AP1 reach mode, and where do the docs and the reference code differ?
  Corrected 2026-10-23 - see C3-B686-01; the original statements below are kept for history and are superseded where the correction says so. At aces-docs 7c34c210 and aces-core 069b0bc3, chroma-compression constants agree between docs and CTL (1.3, 0.69, 0.5, 2.4, 3.3 with log10(peak/100) scaling), but the gamut-compression docs describe a constant lower-hull gamma of 1.14 and an unscaled focusDistance while the CTL computes lower_hull_gamma = 1.14 + 0.07*log_peak and scales focus distance with log_peak; the gamma change dates from aces-core commit cd5017c5 (30 Aug 2024, CA-B095).
• articleWhat conditions does the ICC attach to the sRGB v4 Preference profile beyond 'not changed', and how do they differ from the general library licence?
  Problem. C2-B69-W1-04 summarises the sRGB v4 terms as use/copy/distribute provided the file is not changed. Conditions. Redistributing the profile in a tool, dataset or test suite. Method. The ICC page says permission is granted to anyone who acknowledges the file is provided 'AS IS' with no warranty, provided the file is unchanged including the copyright tag, and that ICC's name is not used in advertising or publicity without written permission. The display-class version is stated to have the same terms. The general library statement is different (it permits sale and embedding without restriction; altered versions must not be misrepresented). Failure modes. Treating the sRGB v4 terms as the permissive library licence, or re-saving the profile with a changed header, voids the stated permission. Limitations. This is a restatement of site text, not legal advice. Version and date. registry.color.org pages fetched 2026-10-23.
• articleAre the ACES 2.0 chroma-compression constants (expand 1.3, compress 2.4) really fixed, and is the 'power p=1.0' gamut-compression statement supported by the cited reference code?
  Problem. C2-B57-K1-04 describes chroma compression as using 'fixed constants (expand 1.3, compress 2.4 ...)' and cites a 'power-p curve p=1.0' and the docs. Conditions. Anyone implementing or porting the ACES 2.0 output transform from the reference CTL at aces-core 069b0bc. Method. Re-read the CTL: chroma_expand 1.3 and chroma_compress 2.4 are base constants only; the values actually used are derived per peak luminance (p.sat = max(0.2, chroma_expand - chroma_expand*chroma_expand_fact*log_peak); p.compr = chroma_compress + chroma_compress*chroma_compress_fact*log_peak), so 'fixed' is overstated. The 0.75 compression threshold, 1.14/0.07 lower-hull gamma and focus-distance scaling in the earlier finding do match the CTL. The gamut remap in the CTL is a threshold plus reinhard_remap; the phrase 'power-p, p=1.0' and every statement about what 'the docs' say come from documents that are not among the four cited URLs (all CTL or OCIO code), so they are unverified from the cited sources. ...
• articleWith FFmpeg, how do I tag an export as Rec.709 without changing pixels, and when do I need to convert instead?
  Corrected 2026-10-23 - see C3-B681-06; the original statements below are kept for history and are superseded where the correction says so. At FFmpeg commit 9047fa1b (tag n8.1), tagging and converting are different tools. Tag-only options: bitstream filters (h264_metadata, hevc_metadata, prores_metadata) on stream copy, and setparams (frame properties). Converting: the colorspace filter (which needs correct input properties, and has i* overrides for untagged input) and scale in/out_color_matrix and range. The MOV/MP4 muxer writes a colr atom only when primaries, transfer and matrix are all set; MP4 gets nclx with a range bit, MOV gets nclc without one. Nothing here was run.
• articleWhen does FFmpeg's MOV/MP4 muxer write a colr atom?
  Problem. C3-B232-G71-02 says the muxer 'writes a colr atom only when primaries, transfer and matrix are all set'. Correction type: (b) overstated. Method. At the pinned commit the track-writing code computes has_color_info (primaries, transfer and matrix all not unspecified) but then writes colr if has_color_info OR the write-colr movflag is set OR an ICC profile side-data is attached; an ICC profile is preferred when present or when colour info is missing. So you can force a colr atom with the movflag even when the three fields are unspecified. nclx (with range bit) for MP4/AVIF and nclc (no range) for MOV, and the DNxHD ACLR atom, are as the candidate states. Limitations. The movflag's public documentation name was not found in formats.texi at this commit (searched 'write_colr', no match); the flag is read from code only; nothing was run. Version and date. n8.1, fetched 2026-10-23.
• articleWhich parameters does the Topaz upscale API expose (model, upscale_factor, target_fps, recover_detail), and when should I not upscale an AI video at all?
  Problem. Choosing whether and how to upscale generated footage. Conditions. Topaz upscaling via fal's API (hosted). Method. Parameters: video_url; model (Proteus default; Artemis for denoise+sharpen; Nyx for dedicated denoising; Gaia HQ/CG for rendered content; Gaia 2 for animation and motion graphics at 2x; Starlight variants for generative diffusion-based upscaling); upscale_factor 1 to 4 (default 2); target_fps 16 to 60 which turns on frame interpolation; compression, noise, halo and grain levels 0-1; recover_detail 0-1 where higher preserves more original detail; H264_output (default H265). Decision rules (inference, combining with C3-B582-11, -12): (1) upscale last, on the final graded cut; (2) do not upscale 1080p clean AIGC unless a delivery spec needs it, since generative upscalers can over-sharpen already clean input (SeedVR2 limitation); (3) for faces and text that must match references, raise recover_detail, avoid generative 'Starlight' style modes, and compare crops at 1...
• articleFor a print handoff, what must the PDF declare about colour (output intent, embedded profiles, transparency) and what does the PDF standard leave to the print shop?
  In PDF 32000-1:2008 a print PDF names its target condition through an output intent (subtype GTS_PDFX for PDF/X): OutputConditionIdentifier is required, and a DestOutputProfile ICC profile is given when the condition is not a registered standard. PDF has no selector among several intents; which one to use is for the buyer and printer to agree. An ICC profile embedded inside a placed image is normally ignored in rendering, because the PDF colour space entries govern. That PDF/X-4 requires an output intent is stated by the Library of Congress summary; ISO 15930-7 itself was not read. Whether a printer accepts RGB or requires CMYK is a contract matter.
• articleBeginner: my design has transparent areas. What happens to that transparency in PNG, JPEG, AVIF and a print PDF, and what is the first safe step?
  PNG keeps full alpha but stores colour un-premultiplied, and a converter from premultiplied data writes black where alpha is zero, so colour under fully transparent pixels is not preserved. JPEG has no alpha, and Krita flattens onto a fill colour. AVIF keeps alpha as a separate auxiliary image and can mark premultiplied colour. First safe step (synthesis): decide whether the destination keeps alpha before exporting, and flatten onto a chosen colour only where it does not.
• articleWhen I export from a layered editor to PNG, JPEG or AVIF, what colour tag and transparency does each format record, and what does Krita's exporter do by default?
  PNG records colour via cICP, iCCP or sRGB chunks (cICP takes priority). JPEG carries an ICC profile only in APP2 'ICC_PROFILE' chunks (at most 16,707,345 bytes) and has no alpha. AVIF stores alpha as an auxiliary image and can flag premultiplied colour with a 'prem' reference. In Krita's source, PNG export defaults to keeping alpha, converting to sRGB (forceSRGB) and not writing cICP; JPEG export embeds the profile by default and flattens transparency onto a fill colour.
• articleWhat are hue, value and chroma in Munsell's A Color Notation, how do I write a colour in his notation, and what does his book not claim?
  Partially verified: the curator re-read none of the cited sources; S3 rests on the producer's pinned reading. Munsell (2nd ed. 1907, copyright 1905) defines hue as the name of a colour, value as its lightness and chroma as its strength, and writes a colour as hue initial, value over chroma (for example R 5/9 for vermilion). He sets five principal hues (R, Y, G, B, P) and five intermediates around a sphere with white at the north pole and black at the south, then concedes the real solid is irregular because pigments reach different maximum chromas. The text is aimed at school teaching, and its science statements (wavelength, amplitude, purity) are simplified.
• articleWhat is Chevreul's law of simultaneous contrast, how can I reproduce his test with two swatches, and what should I not over-claim from it?
  Partially verified: the curator re-read none of the cited sources; S1, S2 rest on the producer's pinned reading. Chevreul (1855 English translation by Martel) states one law: when the eye sees two contiguous colours at the same time they appear as dissimilar as possible in optical composition and in height of tone. He splits the effect into contrast of tone (lighter/darker) and contrast of colour (hue shift toward the neighbour's complement), gives a paper-and-window protocol, and says the effect fades with distance from the shared edge. His numbers for what the effect is worth (for example a one-tenth strengthening) are assumptions he labels as such, and his mechanism claims are 19th-century.
• articleWhat do the vendor guide and Netflix guidance say about reference monitoring, scopes and the checks that catch grade failures?
  Partially verified: the curator re-read none of the cited sources; S9, S10 rest on the producer's pinned reading. Both sources tie trustworthy grading to a calibrated external display. The Resolve 20 book says computer displays cannot guarantee delivery colour accuracy, lists reasons a deliverable looks different (OS colour management, display profile, wrong input space, wrong data level, mis-tagged metadata) and suggests grading HDR first when delivering several standards. Netflix's partner guidance (change log 2024-06-14) says a Dolby Vision title needs its final pass on a professional HDR reference monitor, consumer OLEDs only for review or pre-grade, SDR preview via an ACES output transform is acceptable for progress, and 8-bit review streams can band.
• articleWhich open tools compute MaxCLL/MaxFALL and which only pass the values through?
  Partially verified: the curator re-read none of the cited sources; S13, S12, S11, S14, S15 rest on the producer's pinned reading. In the source read, FFmpeg and libplacebo only carry MaxCLL/MaxFALL (struct fields, SEI parsing, forwarding to x265), libplacebo stores them, merges them when absent, and in the lines read uses MaxCLL only as a fallback for peak luminance, and dovi_tool copies the values from a madVR measurement file or its config into Dolby Vision L6 metadata. x265 takes the values from --max-cll but also accumulates statistics from luma plane sample values; hdr10plus_tool's plot command derives its MaxFALL and MaxCLL labels from per-frame HDR10+ metadata. Nothing read computes the H.265 D.3.35 per-pixel max(R,G,B) linear-light measurement.
• articleWhat do manufacturer documents say about the vectorscope 'skin tone' line, and where is it documented or not documented?
  Partially verified: the curator re-read none of the cited sources; S10, S11, S8, S2 rest on the producer's pinned reading. Of the first-party documents retrievable here, only the Blackmagic SmartScope manual describes the line: keep warm skin saturation along a line 'approximately' at 10 o'clock on the vectorscope, called the 'fleshtone line', which it says is based on blood colour and applies to all pigmentations. That is a vendor statement; this candidate records no independent test of it. Tektronix WFM5200, 1740A and the Tektronix application note have no skin/flesh text, the ITU Recommendations read have none, and the Resolve 19 guide only adds a Skin Tone vector to ColorSlice (not a scope marker). The Resolve reference manual and Leader manuals were unavailable.
• articleWhat do Real-ESRGAN (super-resolution), RIFE and FILM (frame interpolation) each take as input and produce, and which documented settings should a newcomer know first?
  Partially verified: the curator re-read none of the cited sources; S1, S6, S9 rest on the producer's pinned reading. Real-ESRGAN enlarges single images (and frame-by-frame video) by a model-specific factor; RIFE and FILM synthesise new frames between two input frames, which changes frame count or speed, not resolution. The READMEs at the pinned commits document the CLI settings: scale/tile/precision/face-enhance for Real-ESRGAN; exp/multi, scale and fps for RIFE; times_to_interpolate and block grid for FILM. All three are research code run from Python; none of the READMEs read states a finishing-pipeline recommendation for broadcast delivery.
• articleWhen an agent passes HDR10+ or Dolby Vision metadata through hdr10plus_tool, dovi_tool and x265/FFmpeg, which steps are lossless, which alter or drop metadata by design, and which fail quietly?
  Partially verified: the curator re-read none of the cited sources; S12, S13, S10 rest on the producer's pinned reading. From the READMEs, docs and code at the pins (nothing executed): hdr10plus_tool inject needs a raw HEVC bitstream (extraction also accepts MKV), dovi_tool's HDR10+ SEI matching recognises only ST 2094-40 application version 1 HDR10+ SEI, and print but do not stop on a JSON/video frame-count mismatch (metadata is duplicated or skipped at the end). dovi_tool offers documented lossy operations (mode 2 removes profile-7 FEL mapping; editor remove_cmv4 deletes L3/L8/L9/L10/L11 and L254) and generating a Dolby RPU from HDR10+ yields only L1, so no L2/L8 colourist trims. FFmpeg's libx265 wrapper has no HDR10+ path while it enforces Dolby Vision metadata when configured; x265's own options carry both.
• articleWhat do libplacebo and FFmpeg's libplacebo filter actually consume from HDR10+ and Dolby Vision metadata when tone mapping, and what do they ignore or discard?
  Partially verified: the curator re-read none of the cited sources; S11, S10 rest on the producer's pinned reading. Per the libplacebo source at 13d0b798 (code reading only), HDR10+ scene statistics (MaxSCL, average maxRGB, the 99.99% distribution value) and, when present, the Bezier OOTF are mapped into its HDR metadata and feed peak/average-based tone mapping and the ST 2094-40 curve. For Dolby Vision it applies RPU reshaping and reads only Level 1 (max_pq, avg_pq) from the extension blocks; in the seven files scanned there is no use of L2/L8 trim values. Colourist trims are therefore not reproduced by this path, and the FFmpeg filter strips the COLOR_DEPENDENT side data when output transfer or primaries change.
• articleWhat documented failure modes affect Dolby Vision HDR-to-SDR metadata, and which can be checked before delivery?
  Partially verified: the curator re-read none of the cited sources; S2, S1, S3 rest on the producer's pinned reading. Netflix's QC section and Dolby's guide document a short list of Dolby Vision failure modes: L1 values of 0,0,0 on non-black shots (analysis done on the wrong active area or unusable), shot boundaries in the metadata that do not match cuts (mid-shot SDR shifts), wrong canvas/image aspect ratio (translucent bars, lifted matte blacks), positive lift above 0.025 on letterboxed content, cross-vendor tool incompatibility, and stale first-generation CMv2.9-compat blocks (CMVersion 4 0 instead of 4 1). Both sources name the Dolby Metafier validator, plus Dolby CM Offline for rendering the SDR, as the pre-delivery check.
• articleWhat do Dolby Vision metadata levels L0, L1, L2, L3 and L8 mean, and which of them does a colourist author versus the system generate?
  Partially verified: the curator re-read none of the cited sources; S1, S2, S10, S13 rest on the producer's pinned reading. Dolby's own best-practice guide (v4.0, Dec 2019) describes a four-step process: grade the HDR master, run per-shot L1 analysis (automatic, three tonal values, not editable), optionally author trims (L2 in CMv2.9, L8 in CMv4) against named target displays, then deliver. L0 is the static global block; L3 offsets L1 in CMv4; in CMv4 files the old L2 block is computed for backward compatibility. Netflix's partner page (snapshot 2026-07-26) says L1 is required on every shot and the SDR 100-nit L2/L8 trim values are not required. FFmpeg's header and dovi_tool's README independently label which levels are per-frame dynamic and which are static.
• articleI have lens-distortion numbers from one tracking or compositing tool: can I type them into another tool, and what should I check first?
  Partially verified: the curator re-read none of the cited sources; S11, S10, S20, S27, S17 rest on the producer's pinned reading. Generally no, not without checking. A tracking-tool vendor says the math varies between packages so coefficients often cannot be reused elsewhere and recommends STMaps instead. Vendor docs for Nuke show why: the same preset family has a direction setting (forward or backward), a normalisation choice (width, height, diagonal, maximum), a distortion centre, and anamorphic terms. A metadata standard (OpenTrackIO reference code) carries a model name string with a default of "Brown-Conrady D-U". The safe beginner route is: identify model and direction, normalisation, centre and sensor size, or transport an STMap and test it on a grid.
• articleWhat do the DaVinci Resolve 19, 20 and 21 New Features Guides say Magic Mask does as a roto/matte tool, which controls affect edge quality and jitter, what are its stated limits, and how do you get the matte out as pixels?
  The Resolve 20 guide describes AI Magic Mask v2 (Studio only): click-based selection of people or objects, a Faster versus Better quality setting, Matte Finesse controls, a Consistency control that smooths edge jitter in low-confidence areas such as frizzy hair or translucent clothing, and a paint tool for frame fixes. Blackmagic itself says the mask will not always be perfect. The older mask remains as Legacy Object Mask. The Resolve 21 guide (public beta) adds rendering Magic Mask 2 in place as an external matte node; the Resolve 19 guide says Magic Mask does not transfer through the OpenFX DaVinci Resolve Renderer plugin. No accuracy numbers appear in the three guides.
• articleWhy does nearest-neighbour downscaling pick different source pixels in OpenCV, PyTorch, Pillow and skimage?
  OpenCV (c8628d47) INTER_NEAREST picks floor(x*scale) with no half-pixel offset, while INTER_NEAREST_EXACT picks floor((x+0.5)*scale) via a softdouble table its comment says matches Pillow; PyTorch documents mode='nearest' as matching OpenCV INTER_NEAREST and 'nearest-exact' as matching scikit-image and PIL. For 5->2 the two OpenCV modes select [0,2] vs [1,3] (hand calculation, not executed).
• articleHow do CDL and LUT colour, tape/reel names and timecode move from dailies into editorial via ALE and EDL, and what does an OTIO conversion keep?
  At the adapter pins, the OTIO ALE reader parses CDL (CDL, ASC_SOP, ASC_SAT columns) into clip CDL values while keeping other columns as metadata, and the CMX3600 EDL writer re-emits CDL as *ASC_SOP/*ASC_SAT comment lines from clip metadata (static reading).
• articleHow do STMap/UV-map conventions relate to OpenCV remap maps and to the 3DE and OpenCV lens-model coordinates implemented in openfx-misc?
  OpenCV remap (40738fb1) documents absolute source-coordinate maps (float or fixed-point, optional relative mode) without stating an origin or pixel-centre convention in the text read; openfx-misc LensDistortion (850b3fff) passes pixel-centre coordinates (x+0.5, y+0.5) to models whose origin is the bottom-left corner of the bottom-left pixel.
• articleAt loudness QC, which measurements must be repeated after every re-render, and which values (numbers and metadata) do EBU R 128, Netflix v1.4 and BWF carry to the delivery package?
  R 128 V5 and Netflix v1.4 differ in target (-23.0 LUFS vs -27 LKFS), gating basis (programme vs dialog-gated) and peak limit (-1 dBTP vs -2 dBTP); one measured value cannot demonstrate both.
• articleIn a dailies workflow, which identifiers must match so synced sound, burn-ins, colour (CDL/LUT) and metadata land on the right clips in editorial?
  Partially verified: the curator re-read S28, S33, S35, S39; S29, S30 were not re-read by the curator and rest on the producer's pinned reading. Dailies tools join data on different keys: Silverstack Lab syncs audio to picture by timecode with audio and video in separate bins; Avid matches ALE metadata to MXF dailies by tape name (or source file name) plus timecode, so the transcode preset tape name must equal the ALE's or relink fails; Resolve applies Silverstack CDLs via EDL plus CCC matched by reel name, which ARRI composes from camera index, reel counter and camera ID.
• articleWhat exactly must a writer of an OpenEXR file do to tag colour space, and where does the Figure 1 writer flowchart disagree with the prose steps?
  Corrected 2026-10-23 - see C3-B643-04; the original statements below are kept for history and are superseded where the correction says so. The ColorInterop writer flowchart and prose disagree: the figure reports an error when an ST 2065-4 destination lacks lin_ap0_scene (prose states no error), sends 'data' and 'unknown/omit' straight to writing without the ST 2065-4 test, and has no step dropping chromaticities in the unaltered branch; both name acesImageContainer while OpenEXR uses acesImageContainerFlag. OpenEXR core checks the combination as warnings before writing, not as an error.
• articleWhat do OpenEXR lossy compressions (DWAA/DWAB, LJ2K) change in the pixels and the colour metadata, and is HTJ2K lossy?
  Corrected 2026-10-23 - see C3-B643-01; the original statements below are kept for history and are superseded where the correction says so. OpenEXR 3.5.2 distinguishes lossless codecs (including HTJ2K256 and HTJ2K32) from lossy ones (DWA, LJ2K) whose pixels 'may have changed slightly', with quality set by dwaCompressionLevel or lossyHTJ2KQuality. DWA quantises after a perceptual power/log mapping and, for RGB channels of one layer, decorrelates with a fixed Rec. 709 Y'CbCr matrix whatever the file's chromaticities, so wide-gamut content is compressed in a 709-based space; no inspected source measures the effect on wide-gamut or HDR images.
• articleDoes the ColorInterop writer flowchart mention acesImageContainer? Corrected: no. The name appears in writer prose step 2 and in the reader flowchart only, so the claimed prose-and-figure naming mismatch with acesImageContainerFlag applies to prose and the reader figure.
  Problem. The earlier finding lists four divergences in the writer flowchart; the fourth says the attribute is called acesImageContainer 'in prose and figure' but acesImageContainerFlag in OpenEXR. Conditions. ColorInterop commit 8b7b15cc, OpenEXRFiles.md. Method. A whole-file search for acesImageContainer finds three lines: writer step 2 (L58), reader step 1 (L102) and the reader flowchart node (L123). The writer Figure 1 (L72-L96) does not contain it. OpenEXR v3.5.2 StandardAttributes names the attribute acesImageContainerFlag. Failure modes. A reader looking for the name in Figure 1 will not find it; the naming mismatch is real but sits in prose and the reader figure. Limitations. Divergences 1 to 3 in the original finding were re-read and hold. Version and date. Fetched 2026-10-23.
• articleIs HTJ2K lossy in OpenEXR 3.5.2? Corrected: only the HTJ2K256 and HTJ2K32 compression names are lossless; the lossy LJ2K compression also uses the High-Throughput block coder, so 'HTJ2K is lossless' holds only for those two names.
  Problem. The earlier finding answers 'is HTJ2K lossy?' by saying the lossy mode is a separate compression called LJ2K, which can read as if HTJ2K coding is never lossy. Conditions. OpenEXR v3.5.2 attribute list. Method. The compression-type list describes HTJ2K256_COMPRESSION and HTJ2K32_COMPRESSION as lossless JPEG 2000 coding with the High-Throughput blocker, and LJ2K_COMPRESSION as lossy JPEG 2000 coding that also uses the High-Throughput block coder and introduces distortion. Failure modes. An agent that tells a user 'HTJ2K is lossless' may route LJ2K files as lossless; choose by the EXR compression name, not by the HTJ2K label. Limitations. Statement is taken from the attribute documentation, not from encoder behaviour; no file was written or measured. Version and date. OpenEXR v3.5.2 docs fetched 2026-10-23.
• articleWhy can a browser not be trusted for colour-accurate HDR review, and what controls exist?
  Partially verified: the curator re-read S21; S20, S22, S24, S27 were not re-read by the curator and rest on the producer's pinned reading. The CSS Color HDR draft deliberately hides display headroom (tracking concern) and anchors SDR reference white at 203 cd/m2 for compositing; with UA tone/gamut mapping unspecified, two reviewers can see different results for identical bytes and no web API verifies what was displayed.
• articleCan a web page tell whether the viewer's browser and screen can show HDR or wide-gamut video, and which queries do I use?
  Partially verified: the curator re-read S19, S22; S20, S23 were not re-read by the curator and rest on the producer's pinned reading. CSS dynamic-range 'high' reports capability (peak brightness, contrast, >8-bit) and explicitly not whether an HDR mode is active; color-gamut values are approximate; Media Capabilities answers whether a given HDR stream can be decoded/rendered ('or something close enough'). A page needs both checks and still cannot certify what is displayed.
• articleShould my engine project use linear or gamma colour space, and what goes wrong with textures, blending and 2D colour if I pick wrong?
  Partially verified: the curator re-read S17, S2, S20, S22; S18, S19, S34 were not re-read by the curator and rest on the producer's pinned reading. Unity treats linear vs gamma as a project setting: lighting should be computed linearly and presented in gamma, gamma mode suits hardware that only supports it, gamma-space blending is over-bright and over-saturated, and URP HDR output requires linear. Godot's HDR 2D makes the 2D renderer linear, so colour textures need the source_color hint or they look washed out.
• articleWhere can I get numeric gamut primaries for Sony S-Gamut3/S-Gamut3.Cine, Blackmagic Wide Gamut / DaVinci Wide Gamut and Canon Cinema Gamut, and which of them come from a manufacturer document?
  Partially verified: the curator re-read S2, S5, S6, S7, S8; S1, S3, S4, S9 were not re-read by the curator and rest on the producer's pinned reading. Camera wide-gamut primaries are published unevenly. Blackmagic's DaVinci Wide Gamut document gives the xy primaries (red 0.8000/0.3130, green 0.1682/0.9877, blue 0.0790/-0.1155, D65 white) and matrices, and records a 2021 fix to the green x value. Blackmagic Wide Gamut Gen 4/5 and Canon Cinema Gamut primaries are easiest to find in the colour-science library, which cites vendor pages; Canon's white paper text has no numeric primaries. Sony's S-Gamut3 table exists only as an image in its PDF. Check any library constant against the vendor document where one exists.
• articleHow invertible is ACES 2.0 in practice, what exactly do the working group and docs claim, and what discrepancies between the reference CTL and a vendor integration have been reported?
  Partially verified: the curator re-read S13, S34, S35, S8; S11, S16, S22, S36 were not re-read by the curator and rest on the producer's pinned reading. Working-group members say ACES 1.x was not fully invertible and that the ACES 2 inverse is meant to reproduce output images (e.g. graphics) on a forward pass, not to recover scene colorimetry; the docs say gamut compression is analytically invertible only below a threshold, above which the inverse solves approximately, as implemented in gamut_compress_inv.
• articleFrom USD render settings to EXR frames, what do UsdRender and OpenEXR actually define for AOV names, layers, parts and ID mattes, and which choices are left to the renderer?
  Partially verified: the curator re-read none of the cited sources; S21, S22, S24, S25 rest on the producer's pinned reading. UsdRender lets a RenderProduct list RenderVars by name and source but USD does not standardise RenderVar names, and OpenEXR channel and layer names carry no stacking or compositing meaning (multipart names must be unique; colorInteropID now carries colour space); AOV names and recombination therefore depend on a renderer-specific naming table passed to compositing.
• articleWhat byte layout does libultrahdr v2.0.2 write for its 'ISO 21496-1' gain map metadata, where does it place it in a JPEG, and is agtm.h part of that layout?
  Partially verified: the curator re-read S51, S53, S56; S54, S55 were not re-read by the curator and rest on the producer's pinned reading. libultrahdr v2.0.2 writes the gain-map metadata as a big-endian binary block. It starts with a minimum version and a writer version (both 0, with other minimum versions rejected on read) and a flags byte (multi-channel and use-base-colour-space bits), followed by numerator/denominator fractions for the headroom and per-channel gain-map fields, with every denominator required to be non-zero. A code comment still refers to 'the draft' of the standard, so conformance to the published ISO 21496-1 is not shown. SMPTE ST 2094-50 conversion (agtm.h) and XMP metadata writing are both off by default in the CMake build.
• articleDoes the Avid ALE guide really document no colour-related columns?
  Problem. C2-B16-B2-07 says the Avid MediaLog guide 'documents no colour-metadata columns'. Correction (clarification). Table A-2 lists an optional 'Color Framing' column with no explanation. It is a video colour-frame field, not grading metadata, so the intended claim holds, but the absence statement should read 'no colour-grade or colour-space columns' and mention this column. Limitations. Meaning of Color Framing is inferred from context; the guide gives none. Version/date. Part 0130-04230-01 Rev. A, August 1999.
• articleWhat exactly changed between Hillman's 2013 deep-samples PDF and the 2018 amendment, so I know which copy's equations to use?
  Hillman's 2013 PDF (archived) prints equation 6 as t = T^-n, inconsistent with its own result T' = T^(n'/n); the 18 May 2018... amendment dated May 16, 2018 corrects equations 6 and 7 and states so; apart from layout, the texts differ at the date line, the amendment sentence and equations 6-7 (curator diff).

More