[meta] Add HDR support to Gecko
Categories
(Core :: Graphics: Color Management, enhancement)
Tracking
()
People
(Reporter: jya, Unassigned)
References
(Depends on 11 open bugs, Blocks 2 open bugs)
Details
(Keywords: meta)
This is a meta bug to track what it would take to support HDR content in Firefox/Gecko
Reporter | ||
Updated•6 years ago
|
Comment hidden (advocacy) |
Comment hidden (me-too) |
Comment hidden (me-too) |
Comment hidden (advocacy) |
Comment hidden (advocacy) |
Updated•4 years ago
|
Comment hidden (advocacy) |
Comment hidden (admin-reviewed) |
Updated•3 years ago
|
Comment hidden (advocacy) |
Comment 11•3 years ago
|
||
Is this meta-bug only for video, or are HDR still images (f.ex. in AVIF format) also in scope?
Many people today have OLED HDR-capable screens on their smartphone, and I think support for HDR video can be important among especially young people. But personally, I'm just as interested in still image support. HDR-capable desktop displays are probably not so common yet, but my guess is that the number of HDR-capable desktop display soon will start to climb pretty fast with increased interest in HDR images (and video) to follow as a consequence.
There's not much software yet to produce/process HDR still images, but just wanted to tip about the work Nicholas Hayes has started on his AVIF Photoshop plugin. Release notes from his latest beta-release:
Added support for loading and saving monochrome images as grayscale documents.
Added support for loading and saving some of the AVIF HDR formats.
The supported HDR transfer characteristics are Rec. 2100 PQ and SMPTE 428-1.
See the README for more details.
Removed the bit-depth restrictions on lossless compression.
10-bit and 12-bit images can now be saved using lossless compression.
Generate an ICC profile from supported NCLX profiles when loading images without an embedded ICC profile
Automatically convert the saved image to the Rec. 2020 or sRGB color space if necessary
Rec. 2020 is required for HDR images saved as Rec. 2100 PQ or SMPTE 428-1
SDR images without an embedded color profile will be converted to sRGB and tagged as such in the CICP metadata
Fixed a few issues with the plug-in scripting support
Known issues
The Rec. 2100 HLG transfer characteristic is not currently supported, these images will be loaded as SDR 16-bits-per-channel documents.
The discussion/issue that probably triggered Nicholas' latest development: https://github.com/0xC0000054/avif-format/issues/8
Comment 12•3 years ago
|
||
(In reply to Stig Nygaard from comment #11)
Is this meta-bug only for video, or are HDR still images (f.ex. in AVIF format) also in scope?
We'll use this metabug for HDR still image work, also. We probably haven't filed as many of those Bugs, and we definitely haven't connected them to this metabug, but they should be blockers.
Comment 13•2 years ago
|
||
Is there a roadmap for HDR photo support in FireFox? There is now true HDR support in Chrome, Brave, and Opera. Safari now supports tone mapping (currently in Tech Preview).
Bug for HDR images: https://bugzilla.mozilla.org/show_bug.cgi?id=1793091
Comment 14•2 years ago
|
||
(In reply to Stig Nygaard from comment #11)
There's not much software yet to produce/process HDR still images, but just wanted to tip about the work Nicholas Hayes has started on his AVIF Photoshop plugin. Release notes from his latest beta-release:
Adobe Camera RAW (ACR) v15.1 also added support to export HDR AVIF images. Here's an example of how to use ACR to create an HDR AVIF: https://gregbenzphotography.com/other/acr-v15-1-adds-avif-exports-and-hdro-support-for-windows/
ACR's exports include HDR metadata which helps provide improved tonemapping.
Example HDR metadata:
Ccv primaries xy : 0.7079,0.2920,0.1700,0.7970,0.1310,0.0460
Ccv white xy : 0.3127,0.3290
Ccv min luminance nits : 1.083943
Ccv max luminance nits : 932.613141
Ccv avg luminance nits : 59.356759
Support for this metadata was added in Chrome 110 back in February, and it shows clear benefits over the previous tone mapping approach (it matches the original image extremely well and avoids rendering the image a bit dark).
Comment hidden (advocacy) |
Comment hidden (me-too) |
Comment 17•1 years ago
|
||
So Windows has HDR, and Nvidia just came out with a new update to Their RTX drivers an "AI SDR to HDR" for video. Does that make it easier to get HDR video in Firefox? I think AMD has something similar. I don't do Intel CPUs so I don't know about them.
Comment 18•1 years ago
|
||
Gamescope and KDE Plasma now have some basic HDR support under Linux. Official Wayland implementation is currently in development
Comment hidden (off-topic) |
Comment 20•1 year ago
|
||
Using KDE Plasma 6 and would love to see Firefox support HDR on GNU/Linux
Comment hidden (me-too) |
Comment 22•1 year ago
|
||
Linux depends on HDR support on system level which is not ready yet:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
Comment hidden (me-too) |
Comment hidden (advocacy) |
Comment hidden (advocacy) |
Comment hidden (off-topic) |
Updated•1 year ago
|
Comment 27•1 year ago
|
||
Updated•1 year ago
|
Comment hidden (advocacy) |
Comment hidden (metoo) |
Comment 30•11 months ago
|
||
I offer to donate some volunteer coding time to create HDR tests (using my TestUFO engine).
I helped influence some web standards (committed a change to W3C HTML 5.2 standard for frame rate related stuff, which was accepted).
Contact me at standards [at] blurbusters.com as I am active in other communities
Updated•11 months ago
|
Updated•7 months ago
|
Comment 31•6 months ago
|
||
Sorry to bother, but we still have some color management issues even on SDR that really needs to be solved:
https://bugzilla.mozilla.org/show_bug.cgi?id=1939259
https://bugzilla.mozilla.org/show_bug.cgi?id=1834978
Comment 32•4 months ago
|
||
Update: WebGPU HDR test suite now works in Safari Tech Preview 125
https://webgpu.github.io/webgpu-samples/?sample=particles
Chrome: PASS (Version 129+) on both Windows and Mac
Edge: PASS (Version 129+) on both Windows and Mac
Safari: PASS (Technology Preview 125+)
FireFox: FAIL
Same pass/fails for the HDR AVIF and HDR JPEG XL's at the gregbenzphotography HDR test suite.
Comment 33•4 months ago
|
||
Update: I did some API & code research, and corroborated the DependsOn / Blocks trace. Apparently, it looks like we have a circular Bugzilla dependency situation. I am reading the definition of DependsOn and Blocks at Mozilla guidelines. https://wiki.mozilla.org/BMO/UserGuide/BugFields#dependson
The true bedrock genesis HDR item is item #1889288 that seems to have no true "Blocks" nor true "DependsOn" at least for the Windows and Mac platform. https://bugzilla.mozilla.org/show_bug.cgi?id=1889288
There's quite a few HDR open source software developers emerging from the forest suddenly contributing to the Webkit/Chromium trees, and we need to attract some of that talent; me thinks.
Comment 34•4 months ago
|
||
Helping Simplify Dependency Tree
This will help volunteer open source developers trying to find out where to start in implementing HDR. (TL;DR: Go to #1889288)
I know this is a META tracker. However, the dependancy tree seems messed up with lots of horses-before-carts from many people submitting different HDR bugzilla reports at different times in the past, confusing a lot of us what comes first. To help y'all (I may even throw in a cash bounty this summer, waiting for funding, but don't wait for me).
Allow me to clean up the dependency graph and show proofs that #1889288 is the main dependancy -- the mother of all bedrocks dependency --that blocks HDR sub-items and sub-features. Also from what I looked, a Mozilla developer to begin #1889288 (at least for Windows platforms) without waiting for any of the items in this meta tracker, because everything in this meta tracker depends on the more recently-created #1889288. So the egg happened before the chicken in this instance; creating a confusion for potential new Mozilla developers who don't know where to begin for HDR. HDR video is too bright on macOS (over exposure). Therefore, this reply is designed to reduce friction by helping disambiguate this messy HDR dependency tree:
On the outstanding items in DependsOn/Blocks:
DependsOn 1743824 - https://bugzilla.mozilla.org/show_bug.cgi?id=1743824
- "h264 video with pixel format yuv420p10le is either not played, played with visual glitches, or played perfectly, depending on the platform"
- That's not a HDR item.
- DELETE from HDR meta tracker
DependsOn 1793091 - https://bugzilla.mozilla.org/show_bug.cgi?id=1793091
- "HDR images are rendered extremely dark"
- My assessment of why: This is because HDR images are downconverted to SDR because the base Gecko framebuffer is not yet HDR, the goal of #1889288
- 1793091 is dependant on solving #1889288
DependsOn 1948317 - https://bugzilla.mozilla.org/show_bug.cgi?id=1948317
- "YouTube HDR Brightness Problem"
- My assessment of why: This is because HDR video are downconverted to SDR because the base Gecko framebuffer is not yet HDR, the goal of #1889288
- 1948317 is dependant on solving #1889288
- 1948317 does not depend on this meta item other than #1889288
DependsOn 1948583 - https://bugzilla.mozilla.org/show_bug.cgi?id=1948583
- "imageData does not support color space"
- Chrome imageData does not support colorspace even for Canvas2D HDR. And VIDEO/WebGPU HDR doesn't require imageData, nor AVIF embeds. Not a blocker for HDR!
- 1948583 does not depend on this meta item other than #1889288
DependsOn 1949088 - https://bugzilla.mozilla.org/show_bug.cgi?id=1949088
- "HEVC 10-bit playback washed out."
- My assessment of why: This is because HDR video are downconverted to SDR because the base Gecko framebuffer is not yet HDR, the goal of #1889288
- 1949088 is dependant on solving #1889288
- 1949088 does not depend on this meta item other than #1889288
DependsOn 1952603 - https://bugzilla.mozilla.org/show_bug.cgi?id=1952603
- "HDR video is too bright on macOS (over exposure)"
- This is usually a colorspace mismatch issue. Addressing the multiple HDR colorspaces in #1889288 is likely to fix this
- 1952603 does not depend on this meta item other than #1889288
DependsOn wr-video-color - https://bugzilla.mozilla.org/show_bug.cgi?id=1494381
- "[meta] [project] Proper colorspace support and color rendering for video playback"
- On many platforms, HDR video playback will depend on the entire Gecko browser framebuffer (for everything/text/images/video) supporting HDR. That's the purview of #1889288, I believe
DependsOn hdr-video-linux - https://bugzilla.mozilla.org/show_bug.cgi?id=1642854
- "https://bugzilla.mozilla.org/show_bug.cgi?id=1642854"
- Oh boy, yes. Linux will need lots of HDR catching up; and I'm glad to see very active work there. But it's not a blocker for continued Windows/Mac/Android/iOS/etc HDR implementations. The way it's bugzilla'd currently suggests Linux HDR support is blocking Windows/Mac; but that's not true. #1889288 can easily proceed on the Windows platform unfettered from the dependency hell at #1642854, from a quick check that I did
DependsOn hdr-video-windows - https://bugzilla.mozilla.org/show_bug.cgi?id=1902427
- "[meta] Add HDR video playback support on Windows"
- It has a few dependencies (1711812, 1750660, 1832971, 1898591) like distorted video, typically HDR misdownconverted to SDR and similar, which all seem mostly actually dependant on #1889288 except for the overlay technique at "Add HDR tone mapping for playing HDR through video overlay on Windows". However, most modern ways of playing videos on Windows do not necessarily use the video-overlay technique (except in certain situations, e.g. HDCP-protected video which is usually played fullscreen anyway). Most browsers including FireFox now use the GPU-accelerated compositor approach, where the final browser framebuffer contains a copy of the video frame composited within (that's why it's all screenshottable normally). Preserving HDR in video composited into the Gecko browser framebuffer requires solving item #1889288...
DependsOn hdr-images-windows - https://bugzilla.mozilla.org/show_bug.cgi?id=1918773
- "[meta] HDR image display on Windows"
- Obviously requires the HDR gecko compositor at #1889288
Blocks 1722790 - https://bugzilla.mozilla.org/show_bug.cgi?id=1722790
- "Support "Optimize video streaming while on battery" (Play HDR as SDR on battery)"
- This is a 4-year-old item that probably should be simplified as a HDR/SDR Gecko-wide efficiency mode switch, not video-specific. A Gecko-wide HDR/SDR switch would be handled by dependencies closer to #1889288
Blocks wr-hdr - https://bugzilla.mozilla.org/show_bug.cgi?id=1889288
- "[meta] [project] Implement WR functionality needed for HDR"
- Basically, the entire Gecko engine (framebuffer of Gecko) needing to support HDR, before you can composite HDR stuff into it (VIDEO buffers, WebGPU HDR buffers, HDR AVIF images, HDR JXL images, and other HDR pixels). Basically whenever the screen is in HDR mode, Gecko using a 48-bit final-compositor HDR framebuffer instead of 24-bit RGB framebuffer. Children elements may be in various colorspaces (including RGB) but the final window rectangle (framebuffer of the viewport) is all HDR 48-bit pixels in Chrome(129+)/Edge(129+)/Brave(129+)/Safari(TechPreview215+) -- because that essentially handles things this way to do high-performance HDR compositing, even doing SDR graphics within the HDR framebuffer (e.g. the text parts of a HDR page).
- I declare #1889288 the bedrock item for adding HDR support to Windows.
If any open source developers are deciding where to begin; then here we go!
I'm willing to contribute a paid bug bounty, how do I begin?
Comment 35•4 months ago
|
||
Happy 404 Day
One time manual-test special for State of Web HDR on Windows and Mac.
PASS = brighter than #FFFFFF hex white supported.
Recommended Display: Any OLED or MiniLED. (LCD HDR = crap)
HDR Support Per Browser Engine, 2025-04-04
HDR Feature | Chromium | Webkit | Gecko |
---|---|---|---|
VIDEO | PASS | PASS | x |
Images | PASS | Developer 215+ | x |
Canvas2D | Version 108+* | x | x |
WebGL | Version 129+ | x | x |
WebGPU | Version 129+ | Developer 215+ | x |
Legend
PASS = Brighter-than-#FFFFFF-white visible on HDR monitor on both Windows/Mac
Dev = Nightly Build (Chrome/Edge) or Tech Preview (Safari)
Chromium = Tested Chrome (Windows/Mac), Edge (Windows) Brave (Windows)
Webkit = Tested Safari (Mac)
Gecko = Tested FireFox (Windows/Mac)
Bold = Tested on both Windows and Mac
Italics = Limitation (Platform-specific or hidden behind chrome://flag)
(Linux not tested yet at this time; will add Linux test suites in 2026)
Test Suite (Manual Tests)
- Videos (Just play your favourite videos on a HDR youtube channel)
- HDR Images (AVIF, JXL, etc):
https://gregbenzphotography.com/hdr/ - HDR Canvas2D (my site):
https://testufo.com/hdr - HDR Canvas2D:
https://ccameron-chromium.github.io/webgl-examples/canvas-hdr.html - HDR WebGPU (change toneMappingMode to 'extended':
https://webgpu.github.io/webgpu-samples/?sample=particles - HDR WebGPU: (change to 'extended')
https://ccameron-chromium.github.io/webgpu-hdr/example.html - HDR WebGL (change HDR Headroom to '3.0'):
https://ccameron-chromium.github.io/webgl-examples/gamut.html
Comment 36•4 months ago
|
||
(Errata: WebGL HDR on Chromium requires chrome://flags Experimental Web Platform Features -> Enabled. However, none of the WebGPU HDR implementations are flagwalled; retail popular Chromium browsers has WebGPU HDR out of box.)
Comment 37•4 months ago
|
||
(Errata: Corrections made. Master copy is likely going to be at https://github.com/blurbusters/testufo-public/issues/4#issuecomment-2777570322 since that is editable. Mozilla Team, I hereby request Edit Priveleges to my posts on Bugzilla so I can delete these errata + edit my posts)
Comment 38•4 months ago
|
||
I'm willing to contribute a paid bug bounty, how do I begin?
Just joined Mozilla Foundation + added monthly donation. (More forthcoming if some action is expedited on successful end-to-end HDR support on Windows)
Comment 39•4 months ago
|
||
The HDR brightness and color is wrong on YouTube in Gnome48 with Developer Edition.
Comment 40•4 months ago
|
||
(In reply to laichiaheng from comment #39)
The HDR brightness and color is wrong on YouTube in Gnome48 with Developer Edition.
Linux HDR bugs goes to Bug 1642854, please report accordingly.
Thanks.
Comment 41•3 months ago
|
||
(In reply to Mark Rejhon from comment #34)
I'm willing to contribute a paid bug bounty, how do I begin?
I will also contribute. Is there a way to split this up?
Comment 42•22 days ago
|
||
(In reply to Mark Rejhon from comment #35)
Nice writeup, Mark. HDR development on Windows is somewhat fraught with peril, in my experience but you're correct that the long-term goal would be for Firefox to gain a fully HDR-clean composition pipeline. It would have to roll its own UI widgets; not possible to use e.g. WinUI 3 widgets in a clean way.
Short term, somebody could hack it in by lifting HDR imagery to a classic DirectComposition surface, but that wouldn't support all the layout and CSS that developers expect; it would be limited to surfaces that aren't obscured by anything, and don't attempt alpha blending.
Comment 43•21 days ago
|
||
but you're correct that the long-term goal would be for Firefox to gain a fully HDR-clean composition pipeline
An interim step is to simply incubate it incrementally -- by using the Chromium/Safari approach of a 64-bit framebuffer (rgba float16) in SDR colorspace. Make sure it looks the same as today's 32-bit framebuffer.
Comment 44•21 days ago
|
||
Certain things would have to be accounted for; alpha blending can have issues in colorspaces (like scRGB) that allow negative values. Certain alpha-blending modes defined by CSS, like screen
, may not be well-defined in an HDR colorspace. (Would be interesting to know how Chromium dealt with these questions.) More generally, every bit of effect code in the pipeline would have to be sure it doesn't just sample into an 8-bit buffer, do effects, and write back...
Comment 45•20 days ago
|
||
I'm planning to get things working with a sort of srgb-extended or rec2020-extended colorspace that is srgb transfer function with RGBA16F pixel format, because 10000 nits (a value a little shy of 50.0 in headroom terms) is still (barely) within the representation limits of f16, so we can do that to preserve the look exactly. It's higher priority to get HDR video and WebGL though.
A pro of rec2020-extended is that it doesn't need negative colors, just values 0.0 to 50.0 (which is a value around 11550 if using srgb transfer function) for 10000 nits HDR in Rec2100 standard terms.
Comment 46•20 days ago
|
||
(In reply to Ashley Hale [:ahale] from comment #45)
I'm planning to get things working with a sort of srgb-extended or rec2020-extended colorspace that is srgb transfer function with RGBA16F pixel format, because 10000 nits (a value a little shy of 50.0 in headroom terms) is still (barely) within the representation limits of f16, so we can do that to preserve the look exactly. It's higher priority to get HDR video and WebGL though.
A pro of rec2020-extended is that it doesn't need negative colors, just values 0.0 to 50.0 (which is a value around 11550 if using srgb transfer function) for 10000 nits HDR in Rec2100 standard terms.
In my opinion, using linear than srgb transfer would be better. As there are some controversy about sRGB transfer function(piece-wise or power 2.2). Also for BT2020, I don't think windows would accept BT2020 primaries + sRGB transfer.
Comment 47•20 days ago
|
||
(In reply to wiagn233 from comment #46)
As there are some controversy about sRGB transfer function(piece-wise or power 2.2).
That's something that Windows imposes on its own SDR-->HDR translation function. If you're not using that function, you can do what you want in terms of mapping SDR to an absolute HDR luminance level, but (a) if you want consistency with other SDR Windows apps running in HDR mode, you'd use the sRGB transfer function, and (b) if we reduce that controversy to the "Gamma 2.2 is correct" versus the "sRGB is correct" partisans, then neither "side" is telling the whole story:
Pure Gamma 2.2 does not even come close to correctly describing the near-black behavior (0x00 vs 0x01, and the next few code points) of any LCD panel I have ever worked with. (Strictly applied, gamma22ToLinear(0x01) would map to an absolute nits that is not visible on any real-world VA panel.)
sRGB, on the other hand, comes closer, but its mapping for e.g. 0x01 is noticeably brighter than a real-world VA panel such as the one in front of me. Ditto for OLED. But that probably doesn't hold true for IPS hardware (w/o miniLED) which is only capable of around 1000:1 contrast.
If you're Microsoft, and you decide you can only pick one transfer function, you pick sRGB because it at least preserves visibility.
Comment 48•20 days ago
|
||
(In reply to Nathan Bryant from comment #47)
(In reply to wiagn233 from comment #46)
As there are some controversy about sRGB transfer function(piece-wise or power 2.2).
That's something that Windows imposes on its own SDR-->HDR translation function. If you're not using that function, you can do what you want in terms of mapping SDR to an absolute HDR luminance level, but (a) if you want consistency with other SDR Windows apps running in HDR mode, you'd use the sRGB transfer function, and (b) if we reduce that controversy to the "Gamma 2.2 is correct" versus the "sRGB is correct" partisans, then neither "side" is telling the whole story:
Pure Gamma 2.2 does not even come close to correctly describing the near-black behavior (0x00 vs 0x01, and the next few code points) of any LCD panel I have ever worked with. (Strictly applied, gamma22ToLinear(0x01) would map to an absolute nits that is not visible on any real-world VA panel.)
sRGB, on the other hand, comes closer, but its mapping for e.g. 0x01 is noticeably brighter than a real-world VA panel such as the one in front of me. Ditto for OLED. But that probably doesn't hold true for IPS hardware (w/o miniLED) which is only capable of around 1000:1 contrast.
If you're Microsoft, and you decide you can only pick one transfer function, you pick sRGB because it at least preserves visibility.
This is why I advice to use linear space for framebuffer to host OS, this would get us a cross-platform consistency. Also currently on Wayland, Kwin and Weston are already using pure power 2.2 to replace sRGB piece-wise curve.
Comment 49•17 days ago
|
||
I'm planning to get things working with a sort of srgb-extended or rec2020-extended colorspace that is srgb transfer function with RGBA16F pixel format, because 10000 nits (a value a little shy of 50.0 in headroom terms) is still (barely) within the representation limits of f16, so we can do that to preserve the look exactly. It's higher priority to get HDR video and WebGL though.
A pro of rec2020-extended is that it doesn't need negative colors, just values 0.0 to 50.0 (which is a value around 11550 if using srgb transfer function) for 10000 nits HDR in Rec2100 standard terms.
Fantastic! How can I help on the tests side?
I'm willing to make custom modifications to any of my HDR websites (including testufo) to help FireFox testing.
Linear RGB definitely is easiest, but I had to also deal with non-linear RGB conversion issues and work around quirks:
I'd like to add that I got SDR looking identical in both SDR and HDR at beta.testufo.com in Chromium recently. When running a Rec2100-pq framebuffer, I had to apply a matrix formula to get my SDR GPU colors (shaders, etc) looking same in both SDR and HDR (rec2100-pq framebuffer in Chromium).
// This matrix works great for preserving SDR colors:
static MATRIX_sRGB_to_2020 = [
0.6274040, 0.3292820, 0.0433136,
0.0690970, 0.9195400, 0.0113612,
0.0163916, 0.0880132, 0.8955950];
static _applyMatrix(m, r, g, b)
{
return [m[0]*r + m[1]*g + m[2]*b,
m[3]*r + m[4]*g + m[5]*b,
m[6]*r + m[7]*g + m[8]*b];
}
static nits2pq(value)
{
const n = Math.pow(value / 10000, this._m1);
return Math.pow((this._c1 + this._c2 * n) / (1 + this._c3 * n), this._m2);
}
Then in my in-house colorspace-to-colorspace converter, I had to:
case this.REC2100PQ:
// Linear sRGB β Linear Rec.2020 gamut β nits β PQ
// Tested: β
Good WebGL=Canvas2D parity for drawing SDR colors into HDR canvas.
const conv = this.__applyMatrix(this.MATRIX_sRGB_to_2020, linearRGB[0], linearRGB[1], linearRGB[2]);
uniformRGB[0] = this.nits2pq(conv[0] * this.SDR_WHITE_NITS);
uniformRGB[1] = this.nits2pq(conv[1] * this.SDR_WHITE_NITS);
uniformRGB[2] = this.nits2pq(conv[2] * this.SDR_WHITE_NITS);
uniformRGB[3] = linearRGB[3];
return true;
Nontheless, colorspace conversion is a royal pain sometimes. Staying in linearized RGB is definitely easiest, but this is the hoop I jumped to make SDR look the same in both SDR and HDR colorspaces, especially when relaying color uniforms to a shader.
Comment 50•17 days ago
|
||
Forgot this constant:
static SDR_WHITE_NITS = 203.0; // BT.2100 reference white (SDR = 100% reflectance)
Either way, this code works the same on both PC and Mac, when I've created a rec2100-pq framebuffer in either Canvas2D or WebGL.
I hereby release this specific publicly-posted code snippets in compliance with Mozilla's source code license, should Mozilla utilize this code snippet to generate a consistent SDR appearance on Windows (on both PC and Mac).
Comment 51•16 days ago
|
||
Yes, alpha is the missing-specification problem (I couldn't find a specific spec about alpha conversion for SDR-HDR):
"alpha blending can have issues in colorspaces (like scRGB) that allow negative values. Certain alpha-blending modes defined by CSS, like screen"
Also alpha values in shader uniforms too. I haven't solved this part yet, so I just assign the alpha verbatim. I do notice a minor difference, but I would love to see a better definition of how alpha is compensated. In my experience, it seems alpha is linear in SDR, so that you need to apply a gamma correction to the alpha to simulate linear SDR in the non-linear HDR colorspace.
I'll probably do a bit more experimentation, but I have to concede that specifications are a wee bit missing for alpha -- except I learned that alpha seems to behave linearly (instead of gamma 2.2) when in SDR colorspace. With that clue, I suspect (untested) could simply do a SDR gamma correction on the alpha when using alpha on SDR colors, to make alpha look the same. But I don't know how that would behave with HDR colors (out of sRGB gamut).
Comment 52•16 days ago
|
||
Credit / Citations for Source Code
- My source code above is original code written by me, with the exception of matrix
References for matrix numbers (MATRIX_sRGB_to_2020 mentioned above)
- ITU-T standard (2 fewer significant digits) at page 4 of https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2087-0-201510-I!!PDF-E.pdf
- Howevr, I pulled better numbers (2 more significant digits) from a MIT license project that seemed to zero-out visual differences (byte exact SDR pixel colors).
This may or may not be useful to directly Mozilla source code, but aids in testing. It could help in reconciling certain kinds of testing, and in standards discussions between Chromium teams and Mozilla teams. It applies to the work needed to make SDR colors (sRGB / Rec.709) look the same in a Rec.2100pq framebuffer. (I believe MacOS does convert the Rec.2100pq colors to Display-p3 at the OS end, but at the Chromium canvas framebuffer level, it's still Rec.2100pq pixel format).
Comment 53•16 days ago
|
||
Besides, about scRGB-BT2020 choice, though BT2020 is easier to implement, seems some projectors can easily get larger colors space than it. So seems linear scRGB is still the best to implement.
Comment 54•14 days ago
|
||
Should I file a separate bug for any issues I am having with the existing gfx.wayland.hdr flag? It currently results in holes in my window on tile intervals if I have a scaled output.
Comment 55•14 days ago
|
||
(In reply to kode54 from comment #54)
Should I file a separate bug for any issues I am having with the existing gfx.wayland.hdr flag? It currently results in holes in my window on tile intervals if I have a scaled output.
gfx.wayland.hdr goes to Bug 1642854 but ALWAYS make sure you test latest nightly:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_Nightly_binaries
Thanks.
Description
•