- articleHave ACES maintainers published anything on why aces-docs says a constant lower-hull gamma 1.14 while aces-core CTL uses 1.14 + 0.07*log_peak?
No ACES maintainer statement explains the mismatch as of 2026-10-22. Issue and PR searches in aces-docs, aces-core and aces-output return nothing for 'hull' or 'log_peak'. The docs page has had only housekeeping commits since the 1.14 sentence, and current aces-core main still scales the lower-hull gamma (and several other gamut parameters) with log_peak.
- articleWhen did the ACES docs first state that the lower-hull gamma is a constant 1.14, and has the docs repository changed that statement since aces-core commit cd5017c (2024-08-30)?
The ACES 2.0 docs page says the lower gamut hull uses a constant gamma of 1.14. That sentence was added on 2025-03-05 and is unchanged at docs main 7c34c21 (page last touched 2025-09-11). The aces-core reference CTL has used 1.14 + 0.07*log_peak since commit cd5017c (2024-08-30), so the docs sentence postdates and contradicts the code. Implementers should follow the code, and cite both when explaining the ACES 2.0 gamut mapper.
- 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 did the later posts of ACEScentral thread 'ACES 2.0 Seeing a few issues' (post 21 onward) conclude about blue artefacts and ACES 2.0 rendering, and who said what and when?
Thread 5812 (posts 21-66, 2025-08-20 to 2026-01-13) reaches no single conclusion: practitioners report blues collapsing under ACES 2.0 (one LMT author applies the reference gamut compression after the LMT as a workaround), a hue sweep shows a hard reddish-orange/yellow transition that an in-thread reply attributes to the gamut mapper and final hard clamp, and an ACES-Team-titled post says ACES 2 improved nearly all top-10 ACES 1 complaints at the cost of algorithmic complexity, with a limited technical look-transform initiative under way.
- 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).
- articleIs ACES 2.0 appearance consistent between SDR and HDR outputs, how does mid grey change with peak luminance, and what do game-engine implementers report about matching SDR and HDR?
ACES 2.0 deliberately lets mid grey rise with display peak (18% grey at about 10 nit for 100-nit SDR, 13.2 nit at 500, 14.5 nit at 1000), coded as a 0.14 grey-change weight in the tonescale. Forum participants state ACES 2.0 was not tested against dynamic (variable SDR white) mapping and that scaling HDR to match gained-up SDR is an untested suggestion; no source read quantifies SDR/HDR appearance match.
- articleWhat do MaterialX's own translation nodes say about converting standard_surface and OpenPBR to UsdPreviewSurface and gltf_pbr?
MaterialX's translation graphs show where information is dropped: Standard Surface to UsdPreviewSurface outputs only diffuse, emissive, metallic, roughness, clearcoat, clearcoat roughness, opacity, IOR and normal (transmission, sheen and anisotropy are lost), while Standard Surface to glTF PBR keeps transmission, sheen and anisotropy; the OpenPBR (1.1.1) to Standard Surface graph flags anisotropic specular as not yet properly translated.
- 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.
- articleWhen I render or record a cinematic from Unreal, Unity or Godot, which stage tone-maps and tags colour before the file is written, and what do the engines' docs leave unstated?
Unreal 5.1's Movie Render Queue documentation says 8-bit image sequences (BMP, JPG, PNG) are clamped to [0-1] with the sRGB encoding curve, while EXR keeps HDR values: roughly [0-1] with the Tone Curve enabled, linear [0-100] or more with it disabled, and never sRGB-encoded. Godot's Movie Maker documentation and PNG writer state no colour space or transfer for written frames, so an agent must measure or assume; Unity's inspected HDR pages (producer) cover display output, not recorded frames.
- articleHow does ARRI embed camera and lens metadata in SDI (KLV in ANC packets), and what do the lens fields, including the newly documented effective focal length and entrance pupil, say?
ARRI sends extended camera metadata over SDI as the 4096-byte ArriFileV3 header wrapped in SMPTE 336M-2007 KLV (BER length 83 00 10 00) and a separate 12-bit LUT KLV of 6144 bytes (83 00 18 00), segmented into SMPTE 291M ANC packets. ALEXA 35 SUP 1.2 adds lens fields LDI26 and LDI27 in micrometres; LDI26 is named 'Lens Effective Focal Length' (back nodal point to back focus point) in the change notes but 'Axial Effective Focal Length' in the field table, and LDI27 is the entrance pupil position.
- articleWhat is Apple Log, how do developers select it, and how does an editor such as Final Cut Pro handle Apple Log footage?
Apple Log is an AVFoundation capture colour space with BT.2020 primaries and an Apple-defined log transfer (iOS 17.0+); Apple Log 2 uses Apple Gamut primaries (iOS 26.0+) and, when active, deactivates other outputs on the same session. Final Cut Pro offers Camera LUT choices that convert Apple Log and Apple Log 2 to Rec. 709 with Apple 3D LUTs, or None to turn log processing off.
- articleHow do Silverstack and Livegrade carry CDL and LUT colour to editorial and Resolve, what is the application order, and what does not travel?
In Pomfort's documentation, CDL can travel in Silverstack ALE ASC-SOP/ASC-SAT columns into Avid, where (2016 page) the CDL must sit above the added 3D LUT because transformations apply top to bottom; Livegrade's exportable look formats depend on the grading mode; Silverstack lets CDL/LUT order be switched in CDL Advanced to support CDL in log or video gamma, so the receiving tool's order must match the authoring order; and transcodes bake looks per Look source, with From File falling back to a default Log-to-Rec.709 conversion when no look is embedded.
- articleI have colour (CDL) values from dailies in an EDL or ALE: what are ASC_SOP and ASC_SAT in Media Composer and what setting makes them take effect?
In the 2013 Avid guide, CDL values arrive via EDL or ALE in ASC_SOP/ASC_SAT, live as bin-column clip metadata and travel on AAF/ALE/EDL export, but are applied only after enabling the Color Management setting; already-linked clips need Source Settings > Color Encoding > Auto (or the CDL color transformation).
- articleWhat technical remedies for darker-skin rendering (film stock, reference charts, camera design, lighting) does Roth report, by name?
Roth reports remedies: Kodak VeriColor III (early 1980s) and Gold Max with wider skin-tone accommodation, multiracial reference images (a Getty image as an example), and Philips' LDK studio camera redesign for skin colour variation; these are her reported judgments, not tested comparisons.
- articleWhat is the Shirley card and what does Lorna Roth's 2009 article say about film stock and skin-tone bias, in her own words?
Roth (2009) argues that colour film emulsions and camera design were tuned to light skin, with reference cards (Shirley, China Girl, BBC flesh-tone cards) as the norm, and reports from Kodak interviews that complaints about brown objects such as chocolate pushed wider tonal range; users compensated with lighting and make-up.
- 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.
- articleWhen Krita's PNG export forces sRGB, which rendering intent and conversion flags does the pixel conversion use, and can the exporter change them?
Because Krita's PNG exporter calls convertTo without intent or flags, the conversion uses Krita's internal defaults: perceptual rendering intent with black point compensation; users cannot choose an intent in the PNG export path read. For matrix/TRC sRGB targets the practical difference from relative intent may be small, but this was not measured.
- articleWhen Krita exports PNG with 'Force convert to sRGB', does it change pixel values or only relabel the profile?
Krita's PNG 'Force convert to sRGB' option (and any colour model PNG cannot hold) converts the pixels into the built-in Rec.709 sRGB profile with KisPaintDevice::convertTo before writing that profile, so it changes pixel values rather than just relabelling; HDR PNG export converts to a Rec.2020 PQ profile instead, and HDR and force-sRGB cannot both be on.
- 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.
- articleWhat does an external lens calibration file for FreeD look like, and how does it compare with Unreal's Lens File model?
Ventuz's lens file keys OpenCV calibration points by the FreeD zoom value and allows up to 14 OpenCV distortion coefficients (k1-k6, s1-s4, Tx, Ty; missing ones taken as 0), while Unreal's Lens File keys five Brown-Conrady parameters by focus and zoom; the files describe different models and cannot be swapped directly (conversion would need refitting or truncation).
- articleWhat does an Unreal Engine Lens File store, what inputs does it need to be calibrated, and how is it evaluated at runtime?
Unreal's Lens File stores five Brown-Conrady distortion parameters (K1, K2, P1, P2, K3), camera intrinsics and nodal point offsets keyed by focus and zoom, interpolated between calibrated points; Epic says to make a new Lens File for each lens and camera body combination.
- articleHow does Unreal nDisplay layer colour grading and OCIO for LED panels and the inner frustum, and what does the SMPTE RIS colour paper say it covers?
In nDisplay, colour grading settings stack additively in order (a viewport red and a cluster blue give purple), while OCIO overrides are not additive; for in-camera VFX each camera and LED panel combination typically needs its own destination colour space.
- articleWhat do working cinematographers say about exposing for HDR when a proper on-set HDR monitor is not available, and where do they disagree?
Cinematographers writing in 2016-2018 agree that meters and exposure knowledge still matter in HDR but split on how much practice changes: some say to expose as for film with testing and an ACES pipeline ("use a meter ... read shadows, read highlights"), others say highlights need deliberate placement, HDR should be monitored with periodic SDR checks and a spot meter is the fallback without a monitor, and an ASC paper recommends an on-set HDR reference monitor with a waveform that validates rather than replaces exposure readings. These are practitioner accounts that pre-date current LED-volume workflows.
- articleHow do I read a Kodak or Fujifilm camera-negative datasheet: what do the characteristic curve, spectral sensitivity and dye curves show, and under which conditions were they measured?
Kodak's VISION3 500T sheet gives exposure indexes of 500 (tungsten) and 320 (daylight with an 85 filter) and warns that its curves are representative of production coatings, not specifications. Kodak plots log exposure in lux-seconds (the 2015 sheet also states ECN-2 processing and Status M densitometry in its text; the 2022 text layer does not), while Fujifilm's ETERNA manual plots against camera stops with Status M densities, so the two makers' curves cannot be overlaid without converting the exposure axis.
- articleWhat does the DNG 1.7.1.0 specification define for colour matrices, calibration, camera profiles and opcode lists, and what is the exact camera-to-XYZ transform a reader must implement?
DNG 1.7.1.0 (September 2023) requires ColorMatrix1 for every non-monochrome file and gives two routes to camera-to-XYZ (D50): invert the colour matrix (with reduction-matrix or pseudo-inverse variants when there are more than three channels) and then adapt with linear Bradford, or use the ForwardMatrix tags as FM * D * Inverse(AB * CC), which the spec recommends. Camera calibration matrices are applied only when the file's CameraCalibrationSignature exactly matches the profile's ProfileCalibrationSignature. Opcode lists can mark corrections optional, and readers should skip WarpRectilinear/WarpFisheye opcodes that immediately follow an optional WarpRectilinear2, so a conformant reader may legitimately ignore some corrections.
- articleWhat do ARRI's look-file documents say an ALF2, ALF4 and ALF4c contain, how the look travels with clips, and what does not carry over?
ARRI's ALF2 look files bundle creative intent with a display conversion, whereas ALF4 (ALEXA 35/265) is log-to-log: optional ASC CDL plus a Creative Modification Transform, with the display transform applied downstream; ALF4c carries custom display transforms and leaves colour management to the user. Looks travel in each clip's header, so transcoding loses them (link rather than import in Avid); spatial tools cannot live in a 3D LUT; and LogC3 LUTs cannot be converted to LogC4, so looks must be recreated. The 2016 note that ALF2 needs Resolve Studio is dated.
- articleWhat is the difference between scene-referred log footage and display-referred Rec.709 video?
ARRI Log C stores relative scene exposure, logarithmic in stops (about 78 10-bit code values per stop), and ARRI describes two ways to display it: the camera's tone-mapping or a linear conversion with display correction, where values above 1.0 may clip. Rec.709 video is adjusted so the picture looks right on a BT.1886 reference monitor (EOTF exponent 2.404) in a BT.2035 environment. Both can sit in the same pixel container, so treat a file as log or as display video according to its signal metadata or documentation, not by appearance. H.273 code 2 means the transfer characteristics are unspecified and left to the application. The words scene-referred and display-referred are not used in these texts; they are convenient shorthand for ARRI's scene exposure versus BT.709's viewed picture (F1, confirmed by curator search).
- articleWhat do colourists themselves say about grading skin tones (when to use scopes, balance-first or skin-first, warm or accurate), and where do they disagree?
Colourists quoted in a 2017 bachelor thesis do not share one method for skin: one grades the base for skin when a face fills most of the frame and grades the rest first with skin in a secondary on wide shots; vectorscope skin-line use ranges from habitual early in a career to final passes only; stated preferences range from slightly warm to plain accuracy without colour contamination. An interviewed colourist describes a scene where skin and walls were all beige and the work was separating them. The thesis is secondary evidence of what each said (questionnaires cited as personal communication; one quote from a 2016 publication).
- articleHow do HDR guides say exposure and lighting decisions change (or not) compared with SDR, and what do the PQ numbers imply for scopes and nit targets?
Practitioner guidance conflicts: ARRI says HDR exposure and lighting need not differ in general (watch clipped highlights, bright practicals, noise) and that there is no consensus on grading HDR or SDR first; Messerschmidt (ASC) treats HDR as a different format and places practicals at about 300-400 nits with a background window at 800 nits on the display. Netflix adds that light-meter ratios and scope readings need reinterpretation (producer reading).
- articleWhat do ARRI, Netflix, Sony and a working cinematographer say about whether and how to monitor HDR on set?
Netflix (as archived 2025-01-23) encourages but does not require HDR monitoring on set, warns that 'Bright SDR' monitors marketed as HDR-capable are unsuitable, and asks that monitors and LUT boxes support at least 33-point 3D LUTs; ARRI recommends HDR monitoring with a true HDR monitor to catch HDR-only problems early.
- articleWhich image formats store straight versus premultiplied alpha, and what does each specification say an agent must do when moving pixels between them?
Alpha conventions differ by format: PNG and WebP store straight (unassociated) colour, OpenEXR stores colour premultiplied by convention; TIFF signals associated vs unassociated per file with ExtraSamples, and AVIF signals premultiplication with a 'prem' item reference (both from producer reading). Never assume one convention across formats; read the format rule or the per-file flag.
- articleHow are creative looks carried from set to post under ACES (Look Transforms, AMF, CDL plus LUT), and what do the ACES docs say is not portable?
ACES Look Transforms are whole-image ACES-to-ACES transforms carried as ordered Transform IDs in the ACES Metadata File; CDL values chosen under an LMT are invalid without it; non-ACES looks/LUTs are hard to translate (rebuild them in ACES); archive original ACES files plus grading data, the ordered LMTs and the ODT. 'Well-designed LMTs are interchangeable' is a stated design aim, not a test result.
- articleWhat breaks when an ACES 2.0 (or 2.1) OCIO config is opened by OCIO builds older than the config's ocio_profile_version?
OCIO's loader rejects a config whose profile version is newer than the library supports ('not able to load that config version'), so an ACES 2.0 config (profile 2.5) is expected to fail in OCIO 2.4 or older (code inference, not run); unknown keys produce warnings rather than failures; and the ACES 2.1 config's AMF transform IDs are documented as preliminary in 2.6.0, so mappings keyed on them are not stable.
- articleIs there an official public PNG test-image suite and what permission text does it carry?
PngSuite's licence grants use, copying, modification and distribution of the images for any purpose without fee; it does not separately mention hosting, sale or model training.
- articleWhat do the macOS and Windows docs say must be configured for HDR video to play as HDR on a given screen?
HDR display state depends on OS settings a page cannot see: macOS needs the external display's HDR setting on and plays HDR as SDR on battery when 'Optimize video streaming' is on; Windows leaves HDR to the user, sets an SDR reference white that apps should match, clips content the display cannot show, and has no single standard tone-mapping algorithm. Reviewers should report these settings with any HDR judgement.
- articleWhat Lab aim values for paper white and the solid inks does the public FOGRA51 characterisation data give, and how do they differ from FOGRA39?
Recomputed from the ICC-hosted files: FOGRA51 paper white is Lab 95.00/1.50/-6.00 vs FOGRA39L 95/0/-2 (curator CIE76 difference 4.27, all in a*/b*), solids are close (e.g. cyan 56.12/-34.90/-52.52 vs 55/-37/-50; K L* 16 both), FOGRA51 states moderate fluorescence and M1 measurement while FOGRA39L names ISO 13655 without an M-condition. The visible change is a bluer, optically brightened paper white plus the measurement condition.
- articleWhat changed between FOGRA39 and FOGRA51/52 and what do ECI/Fogra say about lamination, varnish and measurement for CMYK conversion targets?
ECI says the 2013 revision of ISO 12647-2 changed ink aims and tone-value curves for optically brightened papers; FOGRA51/52 come with PSO Coated/Uncoated v3 profiles and require M1 (UV-including D50) measurement for metered proof and print control; FOGRA49/50 cover matt/glossy lamination derived from FOGRA39-era test prints, varnish shifts are smaller and have no standard data set, and FOGRA60 covers metal printing.
- articleWhich public sources actually state GWG 2022 variant limits, which only describe the profiles, and what versions or dates do they carry?
No public GWG document read states GWG 2022 numeric limits as specification text: the GWG specifications page offers vendor settings downloads, and the callas documentation explains where the bundled profiles are without giving thresholds. The numbers live in vendor profile files (e.g. callas .kfpx), so an agent must read the profile for the variant it targets.
- articleWhat do Unity's URP and HDRP docs say about enabling HDR output, tonemapping modes, paper white and UI brightness for real-time output?
Unity applies HDR output as tone mapping (including Rec.709-to-display-gamut conversion) followed by a transfer function; URP and HDRP offer Neutral and ACES modes, HDRP's ACES mode has fixed 1000/2000/4000-nit presets, paper white sets unlit/UI brightness, and the docs recommend a player calibration menu; HDRP has gamut and over-paper-white debug views.
- articleIn Godot, how do I enable HDR output and choose between tonemapping and the output-max-linear-value approach, and which tonemappers are compatible?
Godot's HDR output guide lists enabling steps (no SDR-only environment features such as Filmic/ACES tonemapping or Soft Light glow), two approaches (tonemap scene lighting, or use get_output_max_linear_value only for direct presentation), notes that Filmic and ACES ignore the output maximum and stay SDR, supports iOS, Wayland, macOS, visionOS and Windows but not Android, X11 or web, and warns that many HDR screens apply their own tonemapping (prefer HGiG/clip modes during development).
- articleWhere does the OpenEXR library's own deep compositing and deepImageState handling differ from or go beyond the Interpreting Deep Pixels document?
The v3.5.2 default compositor sorts samples by Z then ZBack only when combining more than one source, then composites front to back with over and stops at alpha >= 1; it performs no volume splitting or overlap merging and does not consult deepImageState, so single unsorted images are composited in stored order. The library's SORTED definition uses strict < on ZBack where the document uses <=, and CompositeDeepScanLine requires an alpha channel. Code reading only.
- articleWhat is a deep sample in OpenEXR, and how do I tell a point sample from a volume sample and which channels a deep file must have?
An OpenEXR deep pixel holds any number of samples (all channels share the count), each with a depth; Z is required and ZBack optional (copied from Z if absent); Z >= ZBack is a point sample (zero-thickness surface hit) and Z < ZBack a volume sample over [Z, ZBack); each colour or auxiliary channel needs an associated alpha found through its layer and enclosing layers. The library stores the data; the Interpreting Deep Pixels document defines the meaning.
- articleIs there any numeric RGB vs RGBW vs RGBCA comparison (TM-30, SSI, CRI/TLCI, delta E) and does it cover skin tones or a camera?
The only numeric RGBW-versus-RGBCA comparison found is ROE's November 2024 brochure: TM-30 Rf 80 for both, SSI 68 for both at 3200 K, and SSI 62 (RGBCA) vs 52 (RGBW) at 6500 K, stated as reference values that may vary. These are panel-spectrum metrics with no camera, delta E or skin-tone data.
- articleWhat does an ASC-published first-hand test report say about evaluating exposure and colour on an LED wall, including metering and camera sync?
A first-hand ASC test of Kodak film and an Alexa 35 against an LED wall (D65 native, content at 3200 K and 5600 K) reports that light meters misread narrow-band LED light so a digital camera and calibrated monitor stay necessary, that wall colour must be calibrated to the shooting camera's colour matrix, and that cameras must sync to panel refresh (genlock for digital; a sync box for film).
- articleWhy can skin and costumes look wrong on an RGB LED volume, and what do RGBW and RGBCA panels claim to change (and what is only a vendor claim)?
An ASC-reported 2021 test compared RGB, RGBW and RGBCA panels and a Kino Flo Mimik with a spectrometer and colour meter and found visible improvement over RGB (RGBCA and Mimik better than RGBW for warm and off-white content), without a numeric score; Brompton and ROE describe added white or cyan/amber emitters as broadening the spectrum, Brompton notes cameras see the white LED differently, and ROE claims better SSI and skin rendering without skin data.
- articleWhat have open papers measured about colour-rendition limits of RGB LED volumes for lit subjects (skin, clothing), and how far do 3x3 corrections get?
Two open papers attribute LED-volume colour errors to narrow-band RGB emission seen through camera sensitivities (lighter skin pinker); a 3x3 pre-correction of panel content plus camera post-correction (and black-level subtraction for 4-10% panel albedo) improves skin and orange/yellow materials, but residual errors remain (sodium-vapour light; saturated reds and greens) that no 3x3 matrix can remove. Neither tests RGBW/RGBCA panels or diverse skin tones.