Skip to content

Color-arithmetic should _probably_ be done in linear-color space and not sRGB #17

Open
Open
Color-arithmetic should _probably_ be done in linear-color space and not sRGB#17

Description

@Wunkolo
Wunkolo
opened on Mar 24, 2023

I believe right now all image-arithmetic is operating upon image color values that are within the non-linear sRGB color-space. So operations upon them like sums and averages and conversions may not be indicative to the actual underlying linear color values and may have to be converted from sRGB into linear color space before producing the DCT, and then back into sRGB when intended to be presented to the user.

Ex, sections of code like here should probably be converting the sRGB pixel data into linear before converting into LPQA:

thumbhash/rust/src/lib.rs

Lines 41 to 51 in df761ae

// Convert the image from RGBA to LPQA (composite atop the average color)
for rgba in rgba.chunks_exact(4) {
let alpha = rgba[3] as f32 / 255.0;
let r = avg_r * (1.0 - alpha) + alpha / 255.0 * rgba[0] as f32;
let g = avg_g * (1.0 - alpha) + alpha / 255.0 * rgba[1] as f32;
let b = avg_b * (1.0 - alpha) + alpha / 255.0 * rgba[2] as f32;
l.push((r + g + b) / 3.0);
p.push((r + g) / 2.0 - b);
q.push(r - g);
a.push(alpha);
}

The default behavior for many image-loading libraries is to provide image-data in the sRGB color-space with no conversions as well.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions