Color and imaging science

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

• articleWhere can colour intent recorded in an AMF be lost or contradicted between camera, on-set grading, dailies, editorial and VFX?
  The curator re-read all cited web sources (S15, S16, S17); nothing was executed. The AMF documents themselves name the handoff risks: transport between stages is not defined; AMF carries no edit points and no RAW demosaic settings; association with clips relies on an optional clipId or optional AMF_UUID/AMF_NAME columns in ALE (host support not guaranteed); referenced CDL/CLF files are found by relative path or URI; dailies may change the look or output transform, with prior pipelines archived and conflicts flagged or prompted rather than silently overwritten; in-camera application may be precision-limited because cameras use small 3D LUTs. These are the authors' statements, not field measurements. Producer synthesis (association loss, reference loss, semantic mismatch) is a reasonable grouping of the stated risks, labelled synthesis.
• articleWhich AVIF conformance test files exist in the AOM av1-avif repo and what terms does each vendor folder state?
  At av1-avif bf4c18d1, folder notices differ: Netflix CC BY-NC-ND 4.0 (property of Netflix); Apple names CC-BY-SA-4.0 but links the CC BY 4.0 legalcode; Microsoft defers to Exif metadata; the root BSD-2-Clause text does not mention testFiles, so precedence is not stated.
• articleAt pinned revisions, what must a reader of an OpenEXR file do about colour space, where do the ColorInterop prose and its Figure 2 flowchart (and OpenEXR docs) disagree, and what is the conservative reading?
  At the pins (ColorInterop 8b7b15cc v1.0.0; OpenEXR 69b2604f v3.5.2; OIIO febb1748) the recommendation prose keys on the attribute 'acesImageContainer' being present, its flowchart on the flag being 'set', while OpenEXR docs/core name it acesImageContainerFlag and require int value 1, and OIIO tests == 1. All bytes match producer pins. For a header with acesImageContainerFlag = 0, a literal reading of the prose yields ACES2065-1 while the flowchart, OpenEXR docs and OIIO yield not-ACES (curator agrees this is the plain reading; synthesis, not tested). Prose both permits fallback for an unrecognised ID and says the failure should ideally be surfaced; the flowchart shows only the fallback path at node J.
• 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.
• articleWhat are the Apple Log 2 transfer-function equations and the Apple Wide Gamut primaries, as implemented in ACES and OpenColorIO transforms?
  Scope: pinned-constants observation from two sources (ACES CSC and OCIO) with corrected provenance wording; no Apple statement was obtained; any numeric comparison is a proposal only. At ACES CSC 29b722bc and OCIO 22dd9c4f the Apple Wide Gamut primaries R(0.725,0.301) G(0.221,0.814) B(0.068,-0.076) W(0.3127,0.3290) and the six Apple Log transfer constants are textually identical (source_statement, two pinned files). OCIO states Apple Log 2 reuses the Apple Log transfer function with Apple Wide Gamut instead of Rec.2020, and builds its AP0 matrix with Bradford adaptation (source_statement / code reading, not run).
• articleHow does the ACES 2 output transform's own gamut compression relate to the ACES 1.3 RGC, so an agent knows they are different operations?
  They are different operations in different places. The RGC works on scene-referred ACES values in RGB (AP0 to AP1 distance-from-neutral compression), applied before compositing/grading; the ACES 2 gamut compression runs inside the Rendering Transform in JMh space (after tone scale and chroma compression), compressing J and M toward the display gamut boundary. The ACES 2 page says its original curve is the same powerP family as the RGC (p=1.0 versus the RGC's 1.2). The docs do not say one replaces the other.
• articleDoes any Blackmagic document under 2 MB (or already pinned) state DaVinci Resolve's default for gamut compression / RGC when colour management is ACES 2.0?
  Scoped negative. The Resolve 21.1 release page fetched here (49,818 bytes) mentions 'ACES Transform color space choices' but has no gamut-compression or RGC text. The Resolve 20 New Features Guide (already pinned) has zero 'gamut' hits; the Resolve 19 guide (already pinned) documents that an AMF look transform specifying the ACES reference gamut compress sets the 'Apply ACES reference gamut compress' checkbox, with no default and no ACES 2.0 mention (zero ACES 2 hits). The Resolve Reference Manual, Resolve 20.x read-me/release notes, and the Blackmagic forum release-notes thread were not read: the manual URL guess returned 404 and the forum thread returned 403 (access limit, not retried).
• articleWhat is the Reference Gamut Compression, and what default does the Academy tell implementers (and users) to use for it?
  The RGC is an ACES 1.3 operator (classed as a Look Modification Transform but applied first, right after the input transform) that compresses out-of-gamut values toward the AP1 gamut. The Academy's user and implementation guides recommend, in the absence of AMF tracking, that productions keep it on everywhere, and tell implementers to offer a project-level check-box defaulting to on (with a clip-level override) when the application's ACES version is 1.3 or higher. Neither guide names ACES 2.0, so this is the documented ACES 1.3-era default, not a documented ACES 2.0 default.
• articleDoes any ACES documentation page (RGC pages, ACES 2 pages, aces-core changelog, AMF pages) say whether the Reference Gamut Compression is still recommended, optional or unnecessary in ACES 2.0 output pipelines?
  Scoped negative with useful adjacent statements. In the aces-docs files read at commit 7c34c2100c8da55cd6f94301125d57e38079fc62, no page states that the RGC is recommended, optional, unnecessary or deprecated for ACES 2.0 output pipelines: the four RGC pages and the two AMF pages contain no explicit 'ACES 2' / 'ACES 2.0' mention, and the aces-core changelog (commit 069b0bc) never names the RGC. What the docs do say: the RGC pages state an ACES 1.3-era 'always on' recommendation; the About-rendering page says ACES 2 does not show the clipping artifacts of ACES 1 even when the comparison ACES 1 image has the RGC applied; and the ACES 2 gamut-compression page says its curve was originally the same powerP curve as the RGC. These are statements about different things and do not amount to a recommendation for or against the RGC with ACES 2.
• articleDo the ACES documentation, aces-core changelog or Blackmagic's Resolve 20 guide already pinned in this program state the Reference Gamut Compression's status or Resolve's default under ACES 2.0?
  Scoped negative for C3-C-FEEDBACK-0065 item 1 (cycle-2 C2-B89-U2-04, whose forum evidence is not repeated). Four already-pinned primary texts do not state RGC's status in ACES 2.0 pipelines or Resolve's RGC default under ACES 2.0: the aces-docs overview (RGC is a Look Transform introduced in ACES 1.3), the About ACES 2 page (body names the new output transform's own gamut mapping, not RGC), the aces-core changelog snapshot at Developer Release 3 (gamut compression only in the 1.3 entry) and the Resolve 20 New Features Guide (announces ACES 2.0 support; zero 'gamut' hits). The docs.acescentral.com rgc/ pages, ACES 2.0 release notes and Blackmagic support pages were not fetched because the batch's 600 KB work/ limit was exceeded by the first fetch.
• articleWhat do the official 5.1.7 Movie Recorder pages state about ProRes, colour and tonemapping, and which part of CA-B309's "ProRes hard-codes Rec. 709" is only in mirror source?
  The official Movie Recorder page lists six ProRes codecs, says the ProRes encoder supports Stereo only, does not support variable frame rate, and is unsupported on Linux and Windows Arm64. It contains no colour, tonemapping, Rec. 709, Rec. 2020, PQ or HLG statement (0 hits in the whole 15,316-character page; 0 also in the linear-sRGB page for 709/2020/HLG/PQ and 0 in the changelog apart from dates). CA-B309's "Movie docs contain no colour-tag or tonemapping setting" is corroborated as an absence; "ProRes encoder hard-codes Rec. 709 with Rec. 2020/PQ/HLG commented out" is code-only (ProResEncoder.cs in the mirror) and cannot be byte-checked without the archive.
• 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).
• articleWhat pre-air checklist for scorebugs, lower thirds and data graphics can be assembled from the broadcaster, regulator and sports-body texts, and how strong is each check's evidence?
  Synthesis only. Seven checks can be traced to the inspected texts: (1) list every element where colour carries meaning (BBC mobile audit step); (2) add a non-colour cue such as label, logo, tick/cross (BBC Trust remedies; fans' proposal); (3) run the palette through a CVD simulator (named by the Trust as used in 2015; model unspecified); (4) test text/background contrast (WCAG AA on web and app; TV only "good contrast"); (5) greyscale or monochrome screen (BBC broadcast guidance; UEFA, World Rugby for kits); (6) check the rendered output on real or virtual lighting and small screens (Trust; World Rugby); (7) do not rely on narration. No inspected source gives a numeric pass/fail threshold for TV graphics, a validated order of the checks, or a test of any scorebug, so this list is a proposal with an experiment sketched for later.
• articleWhat do colour-blind football fans report about TV graphics (shootouts, cards, substitution boards), and what remedies did they propose?
  A 2018 focus group of 8 colour-blind male football fans, run for Colour Blind Awareness and co-funded by the FA and Fans for Diversity, reports TV penalty-shootout graphics as the clearest broadcast graphics problem: green and red balls for scored and missed penalties, with small blocks making it worse. Their proposed fix is a tick or cross. They also report difficulty telling red and yellow cards on TV and not noticing the red number on substitution boards. This is self-reported, small-sample, advocacy-organisation evidence with untested remedies; it is consistent in direction with the BBC Trust decision's accepted remedy of adding labels.
• articleWhat do the football law, UEFA, FA and World Rugby texts say to do about kit clashes for colour-blind viewers, which parts are binding, and what checks do they imply?
  Binding text read: IFAB Law 4.3 requires kits that distinguish the teams and officials, without mentioning colour vision. UEFA describes its CVD practice (EURO 2020 kit selections made with teams, e.g. a black away kit for Croatia) as best effort in a news article; the Equipment Regulations article that would carry any rule was not readable. World Rugby's July 2024 document is the one text read that states a policy: for its tournaments from 1 January 2025 a dark primary kit needs a light alternate (and vice versa), with World Rugby directing the kit when a clash is found. Shared checks: greyscale look-alike test, one dark and one light kit, avoid single-colour mid red/orange/green kits, whole-shirt patterns, sock/pitch contrast, number contrast, and approval on physical samples rather than CAD simulations. TV viewing (wide-angle shots, small screens) is named as an aggravating condition, but no inspected text addresses scorebug team-colour chips.
• articleDo Ofcom or EBU texts set any rule about colour-vision deficiency for broadcast graphics or subtitles, and what do they say about colour in subtitles?
  In the texts read in full, none contains colour-vision-deficiency wording: the Ofcom Broadcasting Code (January 2019 text), Ofcom's Guidelines on Providing Television and On-Demand Access Services (capture of 20 Nov 2024), EBU Tech 3380 v1.0.1 and the BBC Subtitle Guidelines page each return 0 hits for colour-blind, colour vision, CVD and deficien*. What they do say about colour: Ofcom lists colour as one speaker-identification option and points to WCAG for subtitle contrast; EBU-TT-D recommends a highly contrastive default text colour; the BBC subtitle guide makes colour the preferred speaker cue, limits it to white, yellow, cyan or green on black, and gives legibility as the reason. A negative result bounded to these documents, not to Ofcom rulings or EBU output in general.
• articleWhat do BBC's own colour rules for graphics say, and how do the broadcast, online and app rules differ in what they require and how they are tested?
  Three BBC rule sets appear in the inspected texts. The broadcast editorial guidance (read only as quoted in the 2016 Trust decision) says to use colours with good foreground/background contrast, names green, yellow or white as best foreground colours, says to avoid pure blues, reds and mauves, and offers a monochrome spot-check; it sets no CVD-specific test or numbers. The online Future Media rules (also read only as quoted in the decision) are MUST statements: information carried by colour must also be available without colour, WCAG 2.0 AA contrast via Snook, and no colour pairs indistinguishable to colour-blind people (check with Vischeck). The current BBC Mobile Accessibility Guidelines (read directly, observed 22 Oct 2026) say colour must not be the only carrier of meaning, require WCAG 2.1 AA contrast, and give a test procedure. The Trust found the broadcast and online sets significantly different.
• articleWhat checks on colour-coded TV and web graphics (bar graphics, maps, lower-third tickers) does the BBC Trust decision of July 2016 imply, point by point?
  The seven appeal points show what Trustees accepted and rejected for broadcast graphics. Upheld: white text on yellow/orange/green blocks, orange v yellow and green v orange pairs read as indistinguishable for deuteranopia, a lower-third ticker and exit-poll lettering with weak foreground/background contrast, and a web map failing the BBC online rule. Not upheld: a column graphic whose party colours were tied to a same-order logo panel, and the claim of "nine shades of orange" (the BBC said lighting in the virtual studio varies the render). A strong voiceover did not rescue a weak graphic. The BBC had already run Vischeck and a contrast checker, but only online designers were required to; television designers were not.
• articleDid the BBC Trust's 2016 decision rule on red/green football kits, and what did the decision text actually decide?
  The decision text found in the BBC Trust's Complaints and Appeals Board bulletin (June 2016, issued July 2016) is about BBC General Election 2015 graphics, not football kits. It partly upheld a Colour Blind Awareness appeal (6 of 7 points, by the complainant's count and consistent with the point-by-point findings), said people with colour vision deficiency are a significant minority audience, and asked the BBC to review its CVD guidance across broadcast and online. No part of the 16-page bulletin text mentions football, kits or sport; the football references found are in the complainant's press release (BBC Football Table web page; a separate kit-clash campaign).
• articleHow could an agent numerically check a graded frame's levels against EBU R 103 and BT.709/BT.2100 without a hardware scope?
  A proposed procedure assembled from the standards: decode to the stated bit depth and range, drop pixels outside the active picture, low-pass filter with R 103's separable filters (horizontal 1,2,3,4,3,2,1 over 16; vertical 1,2,1 over 4), compute the share of R,G,B,Y samples outside nominal, preferred and total bands, and flag out-of-gamut only when more than 1% of the image exceeds the preferred band. Colour balance and hue checks follow from per-channel percentiles and Cb/Cr angles. The method is the worker's synthesis; a small stdlib script reproduces the band arithmetic on synthetic data, and no real frame, tool or scope output was run or compared.
• articleWhat are the 75% and 100% colour-bar targets, which should a scope be set to, and what code values do they have?
  Vendor manuals expose 75% vs 100% as a setting that must match the bar signal being fed (Tektronix WFM5200 and 1740A, Blackmagic SmartScope): the vectorscope graticule targets are drawn for one or the other. ITU-R BT.2111-3 (HDR bars) tabulates the codes: 100% bars use 940/64 and 75% bars use 721/64 at 10-bit (2884 at 12-bit), with a 40% grey, -2%/+2%/+4% black (PLUGE-like) steps and an explicit note that the pattern is not for black level setting. No SDR bar standard (e.g. SMPTE RP 219, ITU-R BT.801) was fetched, so the SDR 75% code values here are the worker's arithmetic from BT.709 s3.4.
• articleWhat do Sony and Blackmagic public pages state about output transforms, roll-off and where the look is applied?
  Negative/limited result. Sony's Venice pages and manuals (pro.sony) and Blackmagic's forum returned 403 to curl, so no Venice or Gen 5 output-transform statement was read. The readable Sony ILME-FR7 help page describes a base-look import with Input/Output attributes and says mode (SDR/HLG/Log) does not trigger conversion; the Blackmagic RAW product page is marketing and lists no output options. Do not generalise from the FR7 to Venice.
• articleWhere does ARRI say the creative look is applied relative to the output transform in ALF4 and ALF4c look files, and what constraints apply?
  ARRI's ALF4 workflow guideline (dated 2025-09-30) states the look is applied in LogC4 (log-to-log CMT, with optional ASC CDL before it) and the output transform comes after, either ARRI's fixed DRTs (ALF4) or user-supplied SDR and HDR DRTs (ALF4c, which requires both and drops the Intensity control). ALF2 combined look and output rendering, and ARRI says ALF2 and ALF4 cannot be converted. ARRI recommends a LogC4-to-LogC4 CMT and says LogC3 looks must be recreated visually in LogC4 (S10).
• articleWhat are the WCAG 2.2 contrast-ratio and relative-luminance formulas and thresholds (1.4.3, 1.4.11), and what in them applies to text burned into video?
  WCAG 2.2 (Recommendation, 12 Dec 2024) defines contrast ratio as (L1 + 0.05) / (L2 + 0.05) with sRGB relative luminance L = 0.2126 R + 0.7152 G + 0.0722 B (linearised with the 0.04045 piecewise function). 1.4.3 requires 4.5:1 for text and 3:1 for large-scale text (18 pt or 14 pt bold); 1.4.11 requires 3:1 for UI components and graphical objects. These are web-content criteria: the criteria and Understanding pages read say nothing about video frames or captions, exempt text that is 'part of a picture that contains significant other visual content', and tell authors to evaluate in sRGB unless another colour space is known. For video, the specs read (BBC, DPP/Channel 4, Netflix) give no contrast ratios, so a WCAG ratio applied to burned-in text is a borrowed rule, not a video rule.
• articleHow should upscaled footage be judged: what do primary sources say about full-reference versus no-reference metrics and their limits?
  Blau and Michaeli prove that lower distortion (full-reference measures such as PSNR/SSIM) and better perceptual quality are at odds for any distortion measure, which is why GAN-based upscalers can score worse on PSNR while looking better. Real-ESRGAN reports only the no-reference NIQE and warns such metrics do not track human preference. The VMAF docs describe a full-reference metric trained on subjective data for stated viewing conditions, say it captures gains from enhancement operations, and provide a NEG mode that disables enhancement gain for codec comparisons; its FAQ shows upscaling the distorted clip before comparison. No inspected source states a validated protocol for judging AI-upscaled finishing footage; broadcaster specs require QC but no metric thresholds in the passages read.
• 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.
• articleIn an FFmpeg zscale + tonemap HDR-to-SDR chain, which HDR metadata is read, kept, stripped or left stale, and where would an agent silently lose dynamic metadata?
  Reading FFmpeg at 5fd305b8 (code only; nothing executed): the HEVC decoder exposes HDR10+ and Dolby Vision as frame side data, but vf_tonemap derives its peak only from MaxCLL, then mastering-display max luminance, then a fixed default (10.0 = 1000 nits for a non-PQ-tagged frame), and never reads dynamic metadata. vf_zscale removes every COLOR_DEPENDENT side-data type (CLL, MDCV, HDR10+, Dolby Vision RPU/metadata) whenever the output transfer or primaries differ from the input. In FFmpeg's own documented chain the first zscale (to linear) therefore strips the metadata before tonemap runs, so the detected peak falls back to the default unless peak= is set. libx265.c has no HDR10+ handling at this pin, so a re-encode drops it silently; x265 needs --dhdr10-info.
• articleWhat do ITU-R BT.2408 and BT.2390 say about HDR-to-SDR down-mapping, do they cover dynamic metadata, and where is the BT.2390 EETF now?
  BT.2408-8 section 5.2 says display-light down-mapping is usually preferred, that the monitoring down-mapper must match the one used to make the SDR transmission, and that a plain 0.5 linear scale does not preserve the look on a 100 cd/m2 display. Neither BT.2408-8 nor BT.2390-12 mentions dynamic metadata or trims (keyword counts of 0 for 'dynamic metadata' and '2094'); they are static, display-mapping guidance. The hermite-spline EETF that tools label 'BT.2390' appears in BT.2390 editions -5, -7 and -8 but in this extraction not in -9 to -12; BT.2408-8 Annex 5 carries it. This extends C2-B05-B-08 (BT.2100/2408/2446 reference-white and BT.2446 methods) without repeating it.
• 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.
• 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.
• articleHow could an agent check a frame, UI or chart for CVD problems, and what does a minimal computed check show for common palettes?
  No inspected source defines a pass threshold. A defensible procedure assembled from the sources: (1) inventory colour meanings and add non-colour cues; (2) simulate protan, deutan and tritan with a pinned model in linear RGB; (3) compare each pair of meaningful colours before and after simulation; (4) treat the simulation as a prompt for human review, not as what a person sees. The author's own computation (synthesis, not a source result) applied Machado severity-1.0 matrices to six palettes: rainbow_5 collapses to a minimum CIE76 dE of 8.2-8.3 under protan/deutan from 52.9 normal, a mid red/green pair falls to 9.9 (deutan), and the Okabe-Ito set including R's added gray keeps min dE 7.1 under deutan because reddish purple and gray converge.
• articleHow common is colour-vision deficiency (CVD), who is affected, and why do open sources quote different percentages?
  Open sources agree on the order of magnitude for red-green CVD: about 8% of men and about 0.4-0.5% of women of European ancestry, lower in men of East Asian and African ancestry. They disagree on the non-European figures (Birch 4-6.5% for Chinese and Japanese men; Machado et al. Table 1 gives 4.2% Asian and 2.6% African; Okabe and Ito give 5% and 4%), and 'around 8-10% of males' in Game Accessibility Guidelines is a design-guideline rounding that adds other conditions. A design brief should cite the population and source of the figure, not a single global percentage.
• articleWhat does Munsell's Chapter VII give a designer to do about colour harmony (paths through the colour solid, area balance), and what does he say is still unproven?
  Munsell rejects the musical analogy for colour harmony and the 'three parts yellow, five red, eight blue' formula, and says only that a measured, orderly relation underlies harmony. He gives three typical paths from any colour (vertical = value change, lateral = hue change, inward through grey to the opposite hue), says small areas of strong chroma balance large areas of weak chroma, and says collecting measured records of pleasing and disliked groups 'should discover some broad law'. He defines complements as points opposite through the centre of the solid and shows balance by Maxwell-disc area ratios; his appendix criticises Runge's and Chevreul's colour solids as distorted.
• articleWhat exactly does Chevreul's book list as the harmonies of analogy and of contrast and as good and bad assortments with white, black and grey, and which of those statements does he himself label as personal taste?
  In the 1855 Martel translation Chevreul sorts colour harmony into two kinds with three members each (analogy: scale, hues, dominant coloured light; contrast: of scale, of hues, of colours) and then gives ranked assortments of red, orange, yellow, green, blue and violet with white, black and grey. His 'first proposition' is that the complementary assortment is best in harmonies of contrast, with tones of equal height, and he pairs complements as red-green, blue-orange and yellow-violet. He says twice that the ranked assortments are not scientific rules but his 'peculiar idea[s]'; the 1861 Spanton translation renders the same passages as 'peculiar taste'. Neither English text in the OCR contains the words triad, tetrad or split complement.
• articleHow do practitioner and digital-era sources qualify film-era lighting-ratio rules?
  The inspected sources do not replace the 1953 numbers with a digital equivalent. They move the decision to measured stops from exposure tests (CML, film era), consistency within a scene's coverage, light meter/false colour/waveform checks, and the trade between raising key and cutting fill for noise versus highlight headroom (Deakins forum, 2023 and 2025). No manufacturer sensor-latitude statement was retrieved, so any digital numeric rule is unsupported here.
• articleWhich scope (waveform, RGB parade, vectorscope, histogram, gamut diamond) should be used to check what, and does a vendor's '0-100%' rule match EBU R 103's tolerance?
  Blackmagic's SmartScope manual assigns luma legality to the waveform (keep blacks at or above 0% and whites at or below 100%), colour-channel legality to the RGB parade ('should be used for checking for illegal colors'), colour balance and tint to the vectorscope, and states a vectorscope alone cannot show illegal levels; a histogram cannot show colour illegality. Tektronix' WFM5200 manual adds that signals legal in digital YCbCr may be illegal when transcoded to RGB and provides Diamond/Spearhead RGB gamut displays with adjustable thresholds. Both vendor texts speak of 0-100% as the limits, whereas EBU R 103 tolerates a preferred band to about -5%/+105% and flags gamut errors only when above 1% of the image.
• articleWhat are the nominal, preferred and total code-value ranges for 8-, 10- and 12-bit Rec.709/BT.2100 video, and what is the difference between narrow ('legal') and full range?
  BT.709-6 s4.6 fixes black=16 and nominal peak=235 (8-bit) or 64 and 940 (10-bit), with video data 1-254 / 4-1019 and the rest reserved for timing. BT.2100-3 Table 9 gives narrow range (default) and full range (only by agreement) and the same 64/940 and 256/3760 at 10/12-bit. EBU R 103 v3.0 Table 1 adds a 'Preferred Min/Max' tolerance (8-bit 5-246, 10-bit 20-984) inside the 'Total Video Signal Range' and says values beyond nominal but inside preferred are not an error. The percentage forms (-5.02 to +105.02 preferred; -6.85 to +109.02 total at 10-bit) are the worker's arithmetic.
• articleWhat SDR and HDR output transforms does an ALEXA 35 apply in camera under ARRI Color Management, and which LUT files correspond?
  ARRI documents four fixed in-camera display render transforms for ALEXA 35/265 under ARRI Color Management: Rec 709 (SDR), Rec 2020 (SDR), Rec 2100 PQ (HDR), Rec 2100 HLG (HDR), each with an equivalent file in the official LogC4 LUT package. A July 2025 naming guideline adds an HLG variant with 203 nit diffuse white (BT.2408) and renames the PQ/HLG colour-space tag from Rec2100 to Rec2020 in file names, while the workflow FAQ still shows the older names. ARRI's pages do not publish tone-map or roll-off parameters for these DRTs.
• articleWhich Dolby Vision trim passes must a colourist actually do for HDR-to-SDR delivery, in what order, and how many targets?
  Dolby's guide requires the colourist to review the Rec.709 100-nit mapping across the whole timeline, and to make the 100-nit trim first if any shot is trimmed; extra targets (600/1000 nit) are optional, up to four trims per deliverable, and should be real passes rather than pasted values. Netflix (2022 and 2026-07 snapshots) says HDR is graded first, followed by analysis and a shot-by-shot trim pass, but lists the 100-nit L2/L8 trim values themselves as not required unless creatives want scene-level adjustments. The two statements are compatible if 'review the default mapping' (Dolby, required) is separated from 'deliver authored trim values' (Netflix, optional); the sources do not say so explicitly.
• articleWhat is the normative definition of MaxCLL and MaxFALL that is openly readable, and what does it say about how they are measured?
  The CTA-861.3 text is paywalled, but ITU-T H.265 (V11, 01/2026) clause D.3.35 is a free primary text that defines the content light level SEI in terms CTA-861.3 relies on. Per pixel, take EMax = max(R,G,B) in linear light, convert to a light level as the CIE 1931 luminance of equal-amplitude RGB at EMax, scaled so peak white is 10,000 cd/m2 for PQ. max_content_light_level is an upper bound over all samples of the coded video sequence; max_pic_average_light_level is an upper bound on the maximum, over pictures, of the average over samples. The SEI does not itself specify the conversion from decoded samples to linear light.
• articleWhat does Android's public camera documentation say about RAW capture, colour metadata and 10-bit/HDR video, and does it define a log profile?
  Android's Camera2 API gives RAW capture as a 16-bit mosaic plus the metadata to decode it (black-level pattern, white level, per-illuminant colour matrices), and DngCreator writes a DNG from a capture without extra setup. For video, the dynamic-range profiles are standard 8-bit, HLG10 (required on all 10-bit-capable devices), HDR10, HDR10+ and Dolby Vision variants; API level 37 adds SMPTE ST 2094-50 Dolby Vision modes. There is still no log profile (page last updated August 2026). Vendor log curves like Xiaomi Mi-Log are documented by the vendor and implemented in colour-science.
• articleHow much of a VISION3 negative's density range fits in a 10-bit DPX scan at 0.002 versus 0.0025 density per code value, and what does Kodak say changes downstream?
  Kodak says a standard 10-bit scan (0.002 density per code value, D-min at code 95) can encode 1.856 density above D-min. That was enough for VISION2 negative but can clip VISION3's extra highlight range. Kodak recommends 0.0025 per code value, recording the choice in the DPX header, and warns that the flatter files affect compositing and colour correction. Two figures need care. The quoted 0.512 extra density is the full-range difference; above D-min at code 95 the gain is 0.464. The contrast change is a factor of 0.8 (20% lower, needing a 1.25x gain to restore), which the paper calls '25% lower contrast'.
• articleWhat containers and metadata encodings does libultrahdr v2.0.2 claim to read and write (JPEG, HEIF, AVIF; XMP, ISO 21496-1), and which API takes which inputs?
  libultrahdr offers five encode paths (API-0 to API-4) depending on whether you supply raw HDR, raw SDR, compressed SDR, or a compressed gain map plus metadata, and a decoder option for the display's maximum boost. Its header version table says 2.0.0 added HEIF/HEIC and AVIF containers (via libheif and an ISO 21496-1 'tmap' item, behind the UHDR_ENABLE_HEIF build flag), and 1.5.1 enabled writing both ISO 21496-1 and XMP metadata. The api_changes document still describes these as planned for a 'Potential v2.0.0', so treat container support as build-dependent and verify it in the build you use.
• articleWhat have the ColorInterop and OpenEXR maintainers said publicly about how readers should handle an unresolved or unknown colorInteropID?
  As of 2026-10-22, the ColorInterop 'bypass' ID issue is still open, and the OpenEXR recommendation was last edited on 2026-07-16. A maintainer's comment on that issue reads the current text this way: an ID other than 'unknown' that matches no colour space is an error that should ideally be shown to the user, while an application that doesn't recognise a new ID may treat it like any missing colour space, possibly by applying file rules. OpenEXR 3.5.0 added header colour-metadata validation helpers but no rule for unresolved IDs.
• 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.
• articleHow do FFmpeg, ImageMagick and libwebp represent and handle straight versus premultiplied alpha when reading and writing?
  FFmpeg tags frames with an explicit alpha mode (unspecified, premultiplied or straight), set by the user when encoding and by libavcodec when decoding. WebP stores straight (non-premultiplied) RGB: libwebp exposes premultiplied output only through lowercase decode modes (e.g. MODE_rgbA), and by default its lossless encoder rewrites RGB under fully transparent pixels unless WebPConfig.exact is set. ImageMagick's WebP coder decodes to straight RGBA and writes straight ARGB.
• articleWhat do FFmpeg, ImageMagick and libwebp document or implement for images with no ICC profile or CICP tags?
  For untagged images: the WebP container spec says to assume sRGB (including for alpha blending in linear light); ImageMagick documents a non-linear sRGB default for unknown 8- to 16-bit formats, overridden by file metadata, profiles or -set, and its WebP writer converts non-sRGB-compatible colourspaces to sRGB and embeds an ICCP chunk when the image has a profile. FFmpeg instead marks primaries, transfer and matrix as 'unspecified', passes a WebP ICCP chunk through as frame side data, and its libwebp encoder wrapper files contain no ICC handling, so FFmpeg-encoded WebP drops a source profile unless handled elsewhere. No FFmpeg statement assuming sRGB was found in the files read.
• articleWhat do the OCIO 2.4 to 2.6 release notes say about the status of ACES 2.0 support (preview, final, performance, fixes), and which OCIO version should a pipeline require?
  OCIO 2.4.0 shipped ACES 2 Output Transforms as a not-for-production Preview, with ACES 1.3 built-in configs. 2.4.1 kept the Preview label and planned finalisation for 2.4.2. 2.4.2 (2025-03-19) removed the label and reported a ~25% speed-up, while ACES 2 stays substantially slower than ACES 1 on CPU and somewhat slower on GPU. ACES 2.0 configs shipped as Config-ACES v3.0.0 (2025-03-15) and became built-in in 2.5.0, whose displays pass negative values. 2.6.0 adds built-in ACES 2.1 configs with unchanged Output Transforms but preliminary AMF IDs that will change in 2.6.1. A pipeline needing production ACES 2 output should require at least 2.4.2, and at least 2.5.0 for built-in ACES 2.0 configs (synthesis).

More