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.

Sign up for GitHub

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

Jump to bottom

Improve the (non-)linear transfer function trait #245

Closed
Ogeon opened this issue Jul 17, 2021 · 0 comments · Fixed by #279
Closed

Improve the (non-)linear transfer function trait #245

Ogeon opened this issue Jul 17, 2021 · 0 comments · Fixed by #279

Comments

@Ogeon
Copy link
Owner

Ogeon commented Jul 17, 2021

Description

We should try to split the TransferFn trait into at least FromLinear and IntoLinear. That should cover cases where it's not so trivial, or even impossible, to reverse the process.

I have also considered baking in number type conversion to allow possibly better quantization quality and conversion speed, but I have to read up some more on that. That could perhaps be covered separately with a more precise IntoComponent option.

Motivation

The current setup assumes both that the process can be reversed and that the output type should be the same as the input type. That may not always be the case.
@Ogeon Ogeon changed the title Improve the RGB transfer function trait Improve the (non-)linear transfer function trait Jul 17, 2021
@Ogeon Ogeon mentioned this issue Apr 3, 2022
Merged
bors bot added a commit that referenced this issue Apr 9, 2022
@bors @Ogeon
Merge #279
03a31f1 
279: Split the TransferFn trait and add lookup tables for sRGB r=Ogeon a=Ogeon

This changes how the transfer functions work a bit:

* `TransferFn` has been split into `FromLinear` and `IntoLinear`.
* The two traits take two type parameters; one for the linear encoding and one for the non-linear encoding.

The split is useful for cases when a conversion is irreversible, as mentioned in #245. The two type parameters makes it possible to convert between number types while encoding and decoding. This makes it possible to skip `.into_format()` in some cases (currently when converting between `u8` and either `f32` or `f64`). In addition to that, I made those special cases faster by using [`fast-srgb8`](https://crates.io/crates/fast-srgb8), and a similar lookup table for `f64`.

## Closed Issues

* Closes #126.
* Closes #245.

## Breaking Change

* `TransferFn` has been split into `FromLinear` and `IntoLinear`.
* `{Rgb, Luma}::{from, into}_linear` and `{Rgb, Luma}::{from, into}_encoding` are now allowed to change the output type. This changes the API and type inference. The solution for the type inference is usually to remove `into_format` from the call chain.
* `{Rgb, Luma}::{from, into}_encoding` will only convert from linear encoding, not "cross convert" between encodings.
* The number type parameter and `'static`lifetime were removed from `RgbStandard`, `LumaStandard` and `RgbSpace`.



Co-authored-by: Erik Hedvall <erikwhedvall@gmail.com>
@bors bors bot closed this as completed in #279 Apr 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Split the TransferFn trait and add lookup tables for sRGB Ogeon/palette
1 participant
@Ogeon