I also recall that we had discussions on the check_contrast flag, and something something it felt obsolete now that we have better logic for telling if colors the right salience. I think I said...
For now, you can try using the salience colorspace at different salience.sampling configs. Try out the options balanced, distributed, and high. low is kind of unstable for general use...
Good enough to merge and start using it to finetune salience weighting and calculations.
@explosion-mental Did you figure this one out yet? To get just the number you would call the underlying delta_e functions.
This also depends on what you would consider dominant.
Not much is missing, at least for what is core to the idea of testing. If you think it's good enough to merge then it's good.
Final thing I would probably want to do left is to be able to toggle which row gets printed on the table below the colors, as it can get bloated, especially when the user has many rows of colors....
Here's that thing to try to figure out the best values for Jmh.
Just a heads up, if you're waiting for this before moving on with #195, don't worry about it unless you want salience calculations to be "perfect." I think what we have right now works "good...
That is a good point... I'll transfer the script over to that.
Plans to do another refactor on weights, separating unit tests for de vs sal vs sal_naive, and offset vs random modes of color generation.