6affbf78c2
Some checks are pending
CI / Lagom (false, FUZZ, ubuntu-24.04, Linux, Clang) (push) Waiting to run
CI / Lagom (false, NO_FUZZ, macos-15, macOS, Clang) (push) Waiting to run
CI / Lagom (false, NO_FUZZ, ubuntu-24.04, Linux, GNU) (push) Waiting to run
CI / Lagom (true, NO_FUZZ, ubuntu-24.04, Linux, Clang) (push) Waiting to run
Package the js repl as a binary artifact / build-and-package (macos-14, macOS, macOS-universal2) (push) Waiting to run
Package the js repl as a binary artifact / build-and-package (ubuntu-24.04, Linux, Linux-x86_64) (push) Waiting to run
Run test262 and test-wasm / run_and_update_results (push) Waiting to run
Lint Code / lint (push) Waiting to run
Push notes / build (push) Waiting to run
TL;DR: There are two available sets of coefficients for the conversion matrices from XYZ to sRGB. We switched from one set to the other, which is what the WPT tests are expecting. All RGB color spaces, like display-p3 or rec2020, are defined by their three color chromacities and a white point. This is also the case for the video color space Rec. 709, from which the sRGB color space is derived. The sRGB specification is however a bit different. In 1996, when formalizing the sRGB spec the authors published a draft that is still available here [1]. In this document, they also provide the matrix to convert from the XYZ color space to sRGB. This matrix can be verified quite easily by using the usual math equations. But hold on, here come the plot twist: at the time of publication, the spec contained a different matrix than the one in the draft (the spec is obviously behind a pay wall, but the numbers are also reported in this official document [2]). This official matrix, is at a first glance simply a wrongly rounded version of the one in the draft publication. It however has some interesting properties: it can be inverted twice (so a roundtrip) in 8 bits and not suffer from any errors from the calculations. So, we are here with two versions of the XYZ -> sRGB matrix, the one from the spec, which is: - better for computations in 8 bits, - and official. This is the one that, by authority, we should use. And a second version, that can be found in the draft, which: - makes sense, as directly derived from the chromacities, - is publicly available, - and (thus?) used in most places. The old coefficients were the one from the spec, this commit change them for the one derived from the mathematical formulae. The Python script to compute these values is available at the end of the commit description. More details about this subject can be found here [3]. [1] https://www.w3.org/Graphics/Color/sRGB.html [2] https://color.org/chardata/rgb/sRGB.pdf [3] https://photosauce.net/blog/post/making-a-minimal-srgb-icc-profile-part-3-choose-your-colors-carefully The Python script: ```python # http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html from numpy.typing import NDArray import numpy as np ### sRGB # https://www.w3.org/TR/css-color-4/#predefined-sRGB srgb_r_chromacity = np.array([0.640, 0.330]) srgb_g_chromacity = np.array([0.300, 0.600]) srgb_b_chromacity = np.array([0.150, 0.060]) ## ## White points white_point_d50 = np.array([0.345700, 0.358500]) white_point_d65 = np.array([0.312700, 0.329000]) # r_chromacity = srgb_r_chromacity g_chromacity = srgb_g_chromacity b_chromacity = srgb_b_chromacity white_point = white_point_d65 def tristmimulus_vector(chromacity: NDArray) -> NDArray: return np.array([ chromacity[0] /chromacity[1], 1, (1 - chromacity[0] - chromacity[1]) / chromacity[1] ]) tristmimulus_matrix = np.hstack(( tristmimulus_vector(r_chromacity).reshape(3, 1), tristmimulus_vector(g_chromacity).reshape(3, 1), tristmimulus_vector(b_chromacity).reshape(3, 1), )) scaling_factors = (np.linalg.inv(tristmimulus_matrix) @ tristmimulus_vector(white_point)) M = tristmimulus_matrix * scaling_factors np.set_printoptions(formatter={'float_kind':'{:.6f}'.format}) xyz_65_to_srgb = np.linalg.inv(M) # http://www.brucelindbloom.com/index.html?Eqn_ChromAdapt.html # Let's convert from D50 to D65 using the Bradford method. m_a = np.array([ [0.8951000, 0.2664000, -0.1614000], [-0.7502000, 1.7135000, 0.0367000], [0.0389000, -0.0685000, 1.0296000] ]) cone_response_source = m_a @ tristmimulus_vector(white_point_d50) cone_response_destination = m_a @ tristmimulus_vector(white_point_d65) cone_response_ratio = cone_response_destination / cone_response_source m = np.linalg.inv(m_a) @ np.diagflat(cone_response_ratio) @ m_a D50_to_D65 = m xyz_50_to_srgb = xyz_65_to_srgb @ D50_to_D65 print(xyz_50_to_srgb) print(xyz_65_to_srgb) ``` |
||
---|---|---|
.devcontainer | ||
.github | ||
AK | ||
Base/res | ||
Documentation | ||
Libraries | ||
Meta | ||
Services | ||
Tests | ||
Toolchain | ||
UI | ||
Utilities | ||
.clang-format | ||
.clang-tidy | ||
.clangd | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
.gn | ||
.mailmap | ||
.pre-commit-config.yaml | ||
.prettierignore | ||
.prettierrc | ||
.swift-format | ||
.ycm_extra_conf.py | ||
CMakeLists.txt | ||
CMakePresets.json | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
flake.lock | ||
flake.nix | ||
ISSUES.md | ||
LICENSE | ||
README.md | ||
SECURITY.md | ||
vcpkg-configuration.json | ||
vcpkg.json |
Ladybird
Ladybird is a truly independent web browser, using a novel engine based on web standards.
Important
Ladybird is in a pre-alpha state, and only suitable for use by developers
Features
We aim to build a complete, usable browser for the modern web.
Ladybird uses a multi-process architecture with a main UI process, several WebContent renderer processes, an ImageDecoder process, and a RequestServer process.
Image decoding and network connections are done out of process to be more robust against malicious content. Each tab has its own renderer process, which is sandboxed from the rest of the system.
At the moment, many core library support components are inherited from SerenityOS:
- LibWeb: Web rendering engine
- LibJS: JavaScript engine
- LibWasm: WebAssembly implementation
- LibCrypto/LibTLS: Cryptography primitives and Transport Layer Security
- LibHTTP: HTTP/1.1 client
- LibGfx: 2D Graphics Library, Image Decoding and Rendering
- LibArchive: Archive file format support
- LibUnicode: Unicode and locale support
- LibMedia: Audio and video playback
- LibCore: Event loop, OS abstraction layer
- LibIPC: Inter-process communication
How do I build and run this?
See build instructions for information on how to build Ladybird.
Ladybird runs on Linux, macOS, Windows (with WSL2), and many other *Nixes.
How do I read the documentation?
Code-related documentation can be found in the documentation folder.
Get in touch and participate!
Join our Discord server to participate in development discussion.
Please read Getting started contributing if you plan to contribute to Ladybird for the first time.
Before opening an issue, please see the issue policy and the detailed issue-reporting guidelines.
The full contribution guidelines can be found in CONTRIBUTING.md
.
License
Ladybird is licensed under a 2-clause BSD license.