Split the TransferFn trait and add lookup tables for sRGB
#279
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Benchmark for 50df92eClick to view benchmark
|
|
Oh, right, the throughput still breaks it. 😫 |
Benchmark for edf7b81Click to view benchmark
|
Benchmark for edf7b81Click to view benchmark
|
|
Some of those benchmark results don't make sense. I'll give them another spin and see if they are less noisy... But I may also reconsider the float -> byte conversion. The improvement wasn't so large anyway. |
Benchmark for edf7b81Click to view benchmark
|
|
It's interesting how it's consistently severely slower. I'll have to double check and see if I measured it correctly later. |
|
I had measured it in some weird way. 🤔 I have simply replaced my hack solution with |
Benchmark for c2360e5Click to view benchmark
|
Benchmark for ce26b32Click to view benchmark
|
|
bors r+ |
|
Build succeeded: |
Ogeon
changed the title
TransferFn trait and add lookup tables for sRGB
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This changes how the transfer functions work a bit:
TransferFnhas been split intoFromLinearandIntoLinear.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 betweenu8and eitherf32orf64). In addition to that, I made those special cases faster by usingfast-srgb8, and a similar lookup table forf64.Closed Issues
Breaking Change
TransferFnhas been split intoFromLinearandIntoLinear.{Rgb, Luma}::{from, into}_linearand{Rgb, Luma}::{from, into}_encodingare now allowed to change the output type. This changes the API and type inference. The solution for the type inference is usually to removeinto_formatfrom the call chain.{Rgb, Luma}::{from, into}_encodingwill only convert from linear encoding, not "cross convert" between encodings.'staticlifetime were removed fromRgbStandard,LumaStandardandRgbSpace.