Color and imaging science

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

• articleWhich ACES 2.0 Output Transform presets exist, how do I choose one (rendering target versus display), and where do the docs and the repository disagree on names or coverage?
  ACES 2 presets combine a rendering target (limiting gamut, peak luminance, creative white) with a display encoding; at the pinned aces-output commit the curator counts 54 forward and 54 inverse CTL presets, every one named with '_in_', while the implementer notes' example uses '_as_' (a docs/repo naming mismatch). Working-group members say little-used targets (e.g. Rec.2020 gamma 2.4) were dropped because nobody was known to use them.
• articleIn plain terms, what is the ACES 2.0 Output Transform, what stages does it run in what order, and how is that different in structure from ACES 1.x?
  ACES 2 Output Transforms concatenate a Rendering Transform (scene ACES to display-limited colorimetry, informed by peak luminance and limiting primaries) and a Display Encoding Transform. Rendering converts to a JMh space from a simplified Hellwig 2022 model, tone-maps J only, compresses chroma and gamut, then limits white, whereas ACES 1 tone-mapped AP1 RGB directly (RRT and ODT merged as 'Output Transform' since 1.1). Some technical pages are still placeholders.
• articleWhat do Canon's white papers define for Canon Log, Canon Log 2, Canon Log 3 and Cinema Gamut, and which curve do they recommend for ACES?
  Canon's 2018 white paper gives Canon Log, Log 2 and Log 3 formulas only as images; the curator's recomputation reproduces every 10-bit code in its table (inputs in scene linear, with reflection = 0.9 x scene linear) and confirms Canon Log 3's linear segment joins its log branches. Canon recommends Log 2 with Cinema Gamut for ACES where all curves exist, calls Log 3 the successor to Canon Log (it matches Canon Log at 0% and 20%), and its 2014 paper describes Cinema Gamut only qualitatively.
• articleWhat exactly do Panasonic's V-Log and V-Gamut reference define (curve constants, primaries, matrices)?
  Panasonic's V-Log is 5.6x+0.125 below 0.01 and 0.241514*log10(x+0.00873)+0.598206 above, which the curator's recomputation matches to the published 10-bit codes 128/433/602; V-Gamut primaries are R (0.730, 0.280), G (0.165, 0.840), B (0.100, -0.030) with D65 white, and the manual gives XYZ, BT.709 and ACES conversion matrices and Varicam clip levels.
• articleWhat are Sony's published S-Log3 encode/decode formulas and code values, and how do S-Gamut3 and S-Gamut3.Cine differ in intent?
  Sony's S-Log3 encodes scene-linear reflection as (420 + 261.5*log10((x+0.01)/0.19))/1023 above 0.01125 with a linear toe below; the curator's recomputation reproduces the published 10-bit codes 95/420/598 for 0/18/90 percent reflection and confirms continuity at the breakpoint. S-Log3 is full range; S-Gamut3.Cine is slightly wider than DCI-P3 and S-Gamut3 near camera native and suited to ACES and BT.2020. Numeric primaries are not in the PDF's text.
• articleWhere do LibRaw, RawTherapee and darktable document deviating from or only partly implementing the DNG colour and opcode model?
  LibRaw 0.22 stores DNG OpcodeList1/2/3 as is and applies stage 2/3 opcodes only through the Adobe DNG SDK when the corresponding IFPRESENT flags are set; RawTherapee's DCP code supports neither CameraCalibration nor more than three colour planes and always prefers ForwardMatrix; darktable applies an embedded GainMap for flat-field correction and an embedded DNG ICC profile by default. Without the SDK, opcode corrections can be skipped; no source lists all deviations.
• articleWhat does the HTML Living Standard say about canvas premultiplied storage and getImageData/putImageData round-trip loss, and what values would a round trip give?
  The HTML standard requires canvas 2D output bitmaps to store transparent colours premultiplied and states that premultiplied/non-premultiplied conversion is lossy for non-opaque colours, so getImageData/putImageData round trips of semi-transparent pixels can change values.
• articleDoes libvips resize premultiply alpha, and what pixel-centre offset does it apply?
  vips_resize does not premultiply alpha (callers must premultiply first) and applies a 0.5*(1-1/scale) centre-sampling shift except for nearest-neighbour.
• articleWhich pixel-centre convention and alpha handling does OpenImageIO use in resize, resample and warp, and does resize premultiply?
  OpenImageIO's resize/resample/warp code uses a half-pixel centre convention, and the transform file does no premultiplication: alpha is filtered like other channels unless the caller premultiplies (the docs provide separate premult/unpremult functions).
• articleHow is EXIF/TIFF Orientation defined, which tools apply it, which strip it, and how does an image get rotated twice?
  Pillow exif_transpose, libvips autorot and ImageMagick AutoOrientImage all apply the orientation transform and then neutralise the tag (Pillow deletes it and patches XMP tiff:Orientation; libvips removes the main-image ifd0 tag; ImageMagick sets TopLeft), which is how they avoid double rotation; CSS image-orientation defaults to from-image but is optional for implementations; TIFF 6.0 defines values 1-8 (TIFF not re-read).
• articleWhere does middle grey (18%) land in LogC4 and Log3G10, and does the exposure index change the curve?
  ARRI's LogC4 spec (2025-01-23) states the curve is independent of the selected EI and maps 18% scene linear to code value 0.2784; RED's Log3G10 places 18% grey at 1/3 and reaches 1.0 at 10 stops above grey (184.32). Curator arithmetic from the published constants reproduces 0.278396, 0.333333 and 0.999999.
• articleHow is an HDR still stored as an SDR JPEG plus gain map (Ultra HDR / Adobe gain map / ISO 21496-1), and what colour-profile and metadata rules decide what a reader reconstructs?
  Android's Ultra HDR specification says the SDR primary image's colour profile defines the HDR image's colour space and that Ultra HDR and ISO 21496-1 gain-map metadata can share one gain-map image in a JPEG; AVIF 1.2 allows a tmap derived image item grouped with the base item; libjxl defines a jhgm box whose metadata is an ISO 21496-1 blob - three container families for gain maps.
• articleEquation by equation, does the OpenEXR repository's TheoryDeepPixels.rst match the 2018-amended PDF, and where does it differ from the 2013 text?
  The rst follows the 2018 form at equations 6-7, omits author/date/amendment context, uses 11 Sphinx labels instead of the PDF's numbered equations, and keeps the merge case-4 typo ('alpha_a=1 and alpha=1'), which implementers should read as alpha_b=1.
• articleWhat does Hillman's original paper contain that OpenEXR's current TheoryDeepPixels web page does not show, and are the formulas the same?
  The OpenEXR website's TheoryDeepPixels.rst (69b2604f, titled 'Theory of Deep Samples', SPDX BSD-3-Clause) follows the 2018 amendment of Hillman's paper at equations 6-7 (t = T^(1/n)) and keeps the derivation structure, but carries no author, organisation, date or amendment note.
• articleWhat is lost or silently changed when converting a LUT between CLF and .cube (ordering, domain, bit depth, interpolation, precision), and how could it be tested with three small files?
  Copying a 3D table verbatim between CLF (blue-fastest) and Adobe Cube (red-fastest) transposes the red and blue axes; OCIO's Iridas reader (10a43ec1) converts from red-fastest order and turns DOMAIN_MIN/MAX into a min/max op, while its baker writes only LUT_3D_SIZE and six-decimal data with no DOMAIN lines, so baked .cube files carry no input-domain information (static reading).
• articleWhat do ITU-R BT.2100, BT.2408 and BT.2446 specify for PQ/HLG, HDR reference white and HDR-to-SDR conversion, and how do BT.2446 methods A, B and C differ?
  ITU-R BT.2100-3 (Feb 2025) defines PQ as an absolute EOTF up to 10,000 cd/m2 and HLG with a display-dependent system gamma of 1.2 at a 1,000 cd/m2 nominal peak, and sets HDR reference white (100% reflectance card) at 203 cd/m2; Report BT.2408-8 (2024) marks that level as 75% HLG / 58% PQ on a waveform and discusses conversion at a 1,000 cd/m2 reference condition; Report BT.2446-1 (2021) describes static HDR-to-SDR methods (Method B using a 291 cd/m2 nominal peak) and notes that adaptive or dynamic methods exist.
• articleWhich aces-core commit introduced the peak-scaled lower-hull gamma (1.14 + 0.07*log_peak) in the ACES 2.0 CTL, and what did its message or PR say?
  In aces-core, commit cd5017c5 (Scott Dyer, 30 Aug 2024) changed lowerHullGamma from the constant 1.14 to 1.14 + 0.07 * log_peak to improve the inverse at higher peak luminance; the 2 Sep 2024 Developer Release 3 changelog records it and says SDR outputs reduce to the former value; the formula is still present (as lower_hull_gamma) at 069b0bc3 (Sep 2026). Documentation stating a constant 1.14 therefore lags the code from at least 30 Aug 2024.
• articleWhat colour information survives export to PNG/web, which chunk wins when several are present, and what is assumed when an image is untagged?
  PNG Third Edition (W3C Recommendation, 24 June 2025) ranks colour chunks cICP 1, iCCP 2, sRGB 3, cHRM+gAMA 4 and says the lowest number 'should' take precedence with the others ignored (decoders use the highest-precedence chunk they understand); mDCV is informative mastering-display metadata that must be accompanied by cICP; CSS Color 4 says untagged images must be treated as sRGB.
• articlePoly Haven, ambientCG and Kenney all say CC0: what do their own pages actually say about commercial use, redistribution, modification, attribution and AI training, and which site-level terms sit outside the CC0 asset licence?
  At the access time below, the three libraries each state CC0 for their assets and say commercial use needs no credit. Only Poly Haven addresses AI training in its own words (FAQ: yes). Poly Haven also keeps separate website and API terms that are not the CC0 asset licence, and its FAQ states a "re-license" limit that the CC0 legal code does not contain. ambientCG and Kenney pages read say nothing about AI/ML training; that is a bounded absence, not permission or prohibition.
• articleWhere do the lens-distortion models of matchmove and compositing tools (Nuke, SynthEyes, OpenCV, Blender/libmv, COLMAP, 3DE, OpenTrackIO) disagree, and what parameters must travel with a shot for the distortion to be reproduced?
  Reading pinned vendor docs and source, the models disagree in at least five ways: direction (Blender division applies x/(1+k r^2) from ideal normalised to image; Nuke Classic and COLMAP SIMPLE_DIVISION use the same form from distorted to ideal), the meaning of k4 (OpenCV: a rational denominator term; Blender Brown: an r^8 polynomial term), the roles of p1 and p2 (Blender Brown is swapped relative to OpenCV, COLMAP and Blender Polynomial, from code reading), the normalisation (OpenCV by z with focal in pixels; Nuke width/height/diagonal/maximum; Blender Nuke model by half the larger image side; OpenTrackIO offsets in mm), and pixel origin conventions. For the shot to be reproducible the record must carry model name, direction, coefficient order and units, normalisation, centre/offset, sensor size and resolution, focal length and the focus/zoom state; an STMap or projection screen is the model-free alternative with storage and precision costs. 3DEqualizer model equations were not read...
• articleWhat did Unreal Engine 5.1's documentation say about the OpenColorIO plugin and HDR display output for cinematics and virtual production?
  In Unreal 5.1 documentation, OCIO came through one OpenColorIO Configuration Asset used by the viewport/Play-in-Editor, Composure, Blueprints, nDisplay and Movie Render Queue, and the engine supported OCIO v1 configs only. Turning on the viewport OCIO display disables the Tone Curve, and MRQ's Color Output can apply an OCIO config and disable the Tone Curve, so whether written frames include the tone curve depends on that setting (see CA-B374 for MRQ file encodings). HDR display output was limited to 1000/2000-nit paths and D3D11 exclusive fullscreen. Confirm the engine release before relying on these limits.
• articleWhat technical objections and independent re-implementations of APCA are recorded in the W3C wcag3 issue tracker?
  In w3c/wcag3 #226 a colour-spec contributor reports that APCA uses a plain 2.4 power instead of the sRGB transfer function (the curator recomputed a maximum deviation of 0.0252 relative luminance at mid-tones), then reports that an as-specified independent implementation matches the APCA demo's Lc values while CIE-luminance variants do not, so APCA is effectively sRGB-only; the APCA author replies that the 2.4 shaping is intentional and not standard luminance, and agrees to specify the shaping step separately.
• articleWhat do the Common LUT Format, the Adobe .cube specification and OCIO's .cube readers define for LUT size, ordering, domain, bit depth and interpolation?
  ACES CLF v3.0 (aces-docs 7c34c210) requires linear interpolation for LUT1D (at most 65536 entries recommended), defaults LUT3D interpolation to trilinear (tetrahedral optional) and orders LUT3D entries with the third (blue) component fastest, whereas the Adobe Cube LUT Specification 1.0 (Sept 2013) orders red fastest, defines DOMAIN_MIN/MAX (default 0-1), and says table values are set for tetrahedral 3D interpolation. The Cube document's licence sentence names CC Attribution Non-Commercial 3.0 but links the by-nc-sa/3.0 (ShareAlike) URL.
• articleHow do open-source film-emulation tools encode manufacturer datasheet curves, and what unit and provenance traps does that introduce?
  In spectral_film_lut at 6307a98, film records store datasheet curves with an explicit exposure base (default 10): the Fuji Eterna 500 record uses base 2 and an x range of about -6.2 to +6.3 (consistent with stops), the Kodak 5219 record base 10 and -3.9 to +0.9 (consistent with log exposure), so mixing records without the base would misplace exposure. Provenance gaps: the Fuji grain curve is copied from Kodak 5207 and the Kodak rms is a computed value. MIT covers the code but says nothing about the datasheet-derived numbers. Fujifilm describes its digital Film Simulation as not merely replicating film.
• articleWhat is lens metadata, which values do Cooke /i lenses and ARRI cameras give per frame, and should I rely on the 'focal length' value as a camera solve input?
  In the ARRI SDI Metadata white paper dated 25 July 2023, ALEXA 35 SUP 1.2 changes add Lens Effective Focal Length (LDI26) and Lens Entrance Pupil Position (LDI27) alongside the existing Lens Focal Length (LDI04, 1/1000 mm).
• articleFor a newcomer: which of GIMP, Krita and Inkscape handle more than 8 bits per channel and colour-managed (ICC) work, and which version should I assume?
  As observed on the project listings on 2026-10-21/22, GIMP 3.2.6 (released 2026-09-10) and Krita 5.3.4 / 6.0.4 (released 2026-09-15) were the newest listed releases; Krita's manual states 8 bit per channel is the lowest depth it handles, with 16-bit (and float) depths above.
• articleWhich Kodak documents say Status M densitometry is used for ECN-2 materials and LAD, and do they define how it relates to other density encodings or to a specific datasheet edition?
  Kodak H-61A gives the camera-negative LAD standard patch nominal Status M densities of 0.80 R, 1.20 G, 1.60 B; this lab-control LAD is a different context from H-387's digital-recorder printing-density LAD (CV 685), and neither document converts between the two.
• articleWhat do Kodak's Cineon/DPX documents and the ACES ADX transforms define for printing-density encoding (0.002 density per code value, D-min 95, LAD 685), and which number comes from which document?
  Kodak H-387 (Digital LAD, 2011) defines printing density as 0.002 x 10-bit code value with the digital LAD patch at code value 685 = printing density 1.370, states those are printing (not Status M) densities, and also tabulates the corresponding Status M values for the recorded intermediate stock.
• articleDo the S-Log3, V-Log and Canon Log 2/Log 3 constants in the manufacturers' documents match those in OpenColorIO's built-in camera transforms and the ACES CTL colourspace transforms, and where do the implementations add something the documents do not say?
  At OCIO 10a43ec1 and ACES aces-input-and-colorspaces 29b722bc, the S-Log3 (261.5, 420, 0.01125, 171.2102946929), V-Log (0.01, 0.00873, 0.241514, 0.598206) and Canon Log 2 (0.24136077, 0.092864125, 87.099375, x0.9 scaling) literals are present as reported; the ACES V-Log CTL carries the explicit linear segment (5.6, 0.125, cut 0.181) that the OCIO Panasonic parameter list read does not spell out.
• articleWhat does cinematographer Ava Berkofsky say about exposure level, light quality and rules of thumb for lighting dark skin on Insecure?
  In a 2017 Mic interview, cinematographer Ava Berkofsky (Insecure) describes the conventional ~70 IRE skin-tone target and says raising dark skin to 50-70 IRE makes the rest of the image look wrong; she says film school did not teach lighting nonwhite people.
• articleWhat was the Kodak Shirley card and why is it said to matter for how skin tones are exposed and printed?
  A 2014 NPR report (WNYC copy) describes Shirley cards as print-lab reference images for setting skin tone, quotes a lab technician on their use, relays Lorna Roth's view that film dynamic range was biased toward white skin, and reports later multiracial reference cards.
• articleFor DCP picture and sound essence, which checks do libdcp's verifier and ClairMeta actually run (read from the check bodies), where do their limits disagree, and what is not checked by either?
  RDD 52:2020 7.3 requires 48 kHz audio essence; libdcp (891facc8) flags any other sampling rate and any bit depth other than 24, while ClairMeta (b3b66a02) settings accept 48000 and 96000.
• articleAt libultrahdr v2.0.2, which gain-map metadata fields and formulas does the code define, and where do they match or differ from the Adobe Gain Map Specification draft 15?
  libultrahdr v2.0.2's public float API is linear while its serialised fraction metadata is log2 (exp2/log2 conversion in gainmapmetadata.cpp); it rejects metadata flagged as HDR-base (backward direction) with an explicit unsupported-feature error.
• articleWhere is full vs limited range recorded in a file (MP4 nclx, MOV nclc, H.264/HEVC VUI, codec atoms), and what goes wrong when it is wrong?
  Range can live in several places. In FFmpeg movenc.c (pin 9047fa1b) MP4/AVIF colr nclx has a range bit, while MOV colr nclc has none; the H.264/HEVC bitstream filters set video_full_range_flag in VUI; DNxHD in MOV gets a separate ACLR atom with a full/legal range marker. Filters (setparams, scale) can mark or convert range. A practitioner says Rec.709 should never be full range and reports crushed/clipped results when it is; BT.709-6 as read defines 219/224 quantisation but the word "full range" does not occur in its text (searched, two spellings).
• articleWhat do players assume when an MP4 has no colour tags (including files from video-generation tools), and what should an agent do about it?
  Players assume different things for untagged video. Apple documented (2011) that untagged QuickTime media is treated as SMPTE-C; Chromium (commit 44e7da44) guesses BT.709 with limited range when nothing is set; a user report shows mpv showing bt.709 for a stream ffprobe called unknown. No inspected source says what any video-generation tool (e.g. Sora, Veo, Kling, Runway) writes: that part is a hypothesis and must be checked per file with ffprobe/mediainfo.
• articleWhy does the same Rec.709-tagged file look different in QuickTime/Safari, Chrome and VLC, and what are the numbers (1.96, 2.2/sRGB, 2.4)?
  Rec.709 (BT.709-6) specifies the camera-side encoding function; the display-side reference is BT.1886 (gamma 2.404), and BT.709-6 says production judges the look on that reference. Players then differ in which display curve they apply to a 1-1-1 file: Chromium (commit 44e7da44) renders BT709-tagged video with the sRGB curve in its generic path and carries a separate Apple curve with exponent 1.961 for macOS decode; Apple documents ColorSync playback lowering contrast for brighter surround. Practitioner posts quote 1.95, 1.96, 1.976 and 2.4 for the "right" figure and disagree on which is the specification.
• articleWhat do the colour-tag numbers (primaries, transfer, matrix, range; e.g. 1-1-1 for Rec.709) mean, and which of them does a file really need?
  A video colour tag is up to four independent facts: colour primaries, transfer characteristics, matrix coefficients (the three H.273 / ISO 23091-2 code points, which Apple writes as an nclc triple in that order, 1-1-1 for HD Rec.709) and a separate full/limited range flag. Code 2 means unspecified in each. The code values here are read from the FFmpeg header that says it matches H.273 and from Apple TN2227; the H.273 PDF itself was over the fetch cap, so the numbers are not compared to the standard text.
• articleWhat capture specs does Netflix require for its productions, and what does that imply for mixing AI-generated shots into premium deliverables?
  Netflix (rendered 2026-10-23) requires 90% of a program's final runtime to be captured on approved cameras (more flexible for nonfiction). Minimum capture attributes for approval consideration: at least 3840 photosite width (spherical); lightly compressed or uncompressed RAW, or intraframe codec with 4:2:2 or better; 10-bit or greater; at least 240 Mbps at 24 fps; scene-referred colour space (e.g. S-Gamut3, ALEXA Wide Gamut, REDWideGamut) and transfer function (S-Log3, LogC, Log3G10, V-Log); timecode jammable to an external source and written as metadata. The page lists 69 approved camera entries across ARRI, Canon, Panasonic, RED, Sony, Blackmagic and DJI, with anamorphic approval flagged per camera. Best practices: aspect ratio is a creative choice to agree with Netflix (framing calculator provided); anamorphic may need extra resolution; test each format's colour transform into the working space (ACES introduced); avoid clips spanning camera cards; discuss film capture and externa...
• articleWhat byte layout does a second independent ISO 21496-1 implementation (libavif) use for gain map metadata, and does it agree with libultrahdr's min_version 0 layout?
  libavif (commit b1e4d339) and libultrahdr v2.0.2 (commit e5f5a022) write the same first four bytes of the ISO 21496-1 gain-map metadata and the same top two flag bits (bit 7 multi-channel, bit 6 use-base-colour-space, confirmed in libultrahdr's gainmapmetadata.h). libavif writes and reads the remaining six bits as reserved without checking them, while libultrahdr assigns flag values 4 (backward direction) and 8 (common denominator, which switches the body layout). Bytes match the producer pins, re-read 2026-10-22. That files written by one library could be misread by the other is an unexecuted inference.
• articleWhich implementation details (resizing, JPEG, quantization, data_range, feature layer) are documented to change image-quality metric values?
  The clean-fid authors report that resizing FFHQ with non-antialiased bicubic implementations (OpenCV, PyTorch, TensorFlow) yields FID of 6 or more against PIL-bicubic, while other PIL filters stay at 0.75 or below, and that JPEG compression strongly shifts FID; pytorch-fid lets users pick Inception feature layers (64/192/768/2048 dims, default 2048) whose scores are not comparable. Component terms differ: clean-fid code MIT, its Inception wrapper derived from Apache-2.0 pytorch-fid, the Inception-v3 weights originally Apache-2.0 via TensorFlow Models.
• sourceLPIPS (Learned Perceptual Image Patch Similarity)
• sourceNetflix VMAF and libvmaf
• sourceImage-Adaptive 3D LUT (PAMI)
• sourcelibplacebo
• sourceColour (colour-science) for Python
• sourceHDRTVNet (SDRTV-to-HDRTV, ICCV 2021)
• sourceArgyllCMS
• sourceACES Core Transforms (aces-core, formerly aces-dev)
• sourceOpenColorIO-Config-ACES
• discussionCan design tokens (DTCG) describe a production's visual identity (palette, type scale, motion timing) across graphics, titles and generated assets?

More