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

Refactor Color Rounding Logic for Enhanced Flexibility and Consistency #161

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ankiiisharma
Copy link

I’ve made some tweaks to our color handling logic. I added a COLOR_FN parameter to the incrementalRoundValue function, which gives us more flexibility when working with different color modes.

image

I’ve made some tweaks to our color handling logic. I added a COLOR_FN parameter to the incrementalRoundValue function, which gives us more flexibility when working with different color modes.
@ankiiisharma
Copy link
Author

@ai , please check. thanks

@@ -159,29 +159,51 @@ function round2(value: number): number {
}

function round4(value: number): number {
if (typeof value !== 'number') {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you remove this check? We use TypeScript to check argument type.

This warning take big part of JS bundle and never will be called.

let precision = i === 0 ? 0 : Math.min(i, maxIterations);
let roundedValue: LchValue = {
a: round2(value.a),
c: round2(value.c),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure, that we should use the same round on each L, C, H on every step.

The problem is that L is 0-100, while C is 0-1. So it better to use different round level for C on every step.

Otherwise, the incrementalRoundValue will keep too many digits after , for L, because algorithm can’t round C anymore.

return value;
}

function isMatch(value: LchValue): boolean {
Copy link
Member

@ai ai Oct 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. You check only the fact that sRGB didn’t go to P3. But we need also to check that P3 color will not go to Rec2020. Check the origin algorithm https://github.com/evilmartians/oklch-picker/blob/main/stores/current.ts#L196
  2. Do we need to replace the origin algorithm? Seems like right now we have 2 different checks and spend resources twice https://github.com/evilmartians/oklch-picker/blob/main/stores/current.ts#L195-L200

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

Successfully merging this pull request may close these issues.

2 participants