Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gamma/non-linearity question #1

Closed
virtualritz opened this issue Jan 22, 2022 · 3 comments
Closed

Gamma/non-linearity question #1

virtualritz opened this issue Jan 22, 2022 · 3 comments

Comments

@virtualritz
Copy link

virtualritz commented Jan 22, 2022

Could you comment on the linearity of the sRGB values the functions take?

8bit/component sRGB is usually non-linear (baked-in 2.2 gamma) because 8bit is not enough to store colors without visible banding.

Does the code take non-linearity into account? I.e. when mixing colors in RGB this matters as mixing non-linear colors simply leads to (subtly) wrong results.

What about the float variants then?

I.e. can you update the README to clearly state what gamma the sRGB values should have in both cases? I think it would also help to mention this in the paper.

On that note, it is extremely uncommon (can't think of a single case I came across in the wild) to have 32bit/component sRGB values that are not linear.

I.e. float sRGB is commonly sRGB linear. sRGB primaries & white point but with a linear (1.0) gamma. Aka: no baked-in transfer function.

@virtualritz
Copy link
Author

To clarify – the expectation of a user of this lib would commonly be:
unsigned char – input/output data is non-linear sRGB with a 2.2 gamma
float – input/output data is linear sRGB (no gamma)

This was referenced Jan 28, 2022
@virtualritz
Copy link
Author

Bump. Can you clarify this, pretty please? 😀

@scrtwpns
Copy link
Owner

All functions in Mixbox 1.x expected non-linear input values and produced non-linear outputs. The internal lookup table is precomputed with this in mind and it takes the non-linearity into account. This means the pigment mixing is carried in the proper linear fashion and the result is non-linearized before output.

We realized the way we named the functions was not ideal and could have lead to some confusion where, e.g., someone would pass linear values as input by mistake. This is why we decided to use new naming for Mixbox 2.0 which hopefully makes the distinction between linear and non-linear more explicit.

There are now 3 versions of each function:

  1. takes 8-bit non-linear rgb (0-255)
  2. takes non-linear 32-bit float rgb (0.0-1.0)
  3. takes linear 32-bit float rgb (0.0-1.0)

For example:

  • mixbox_lerp() takes non-linear 8-bit rgb
  • mixbox_lerp_float() takes non-linear float rgb
  • mixbox_lerp_linear_float() takes linear float rgb

The latent vectors are always in the same linear space and the non-linearity is taken into account when converting to/from the latent space.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants