-
Notifications
You must be signed in to change notification settings - Fork 0
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
Set monochromatic colour maps to the same lightness range #4
Comments
We need to consider whether Cyan can still remain as one of the base monochromatic colourmaps once we rescale the lightness range. Cyan has the annoyance that it quickly moves into "teal" or "light blue" (subjective) as it moves into the darker regime. Either we keep |
I made the bright end of the Blue_1090 colour map closer to light blue, would that be enough? As for cyan, I'm happy to rename the current Cyan_1090 to teal, but I'm not sold on having an additional cyan map. If you could make a 10-90 version for me to see that would be great. |
Here are the colour names for Blue_1090 in 20 increments: Whereas before, our colours were ending in cyans. So I think Blue_1090 is now perfect. I will toy around with making a Cyan 10-90 map. |
I've added a Cyan_1090 colourmap to devel_robin, which looks reasonably good. I've managed to capture mostly cyan and turquoise colours with little contamination of teal. The named colours for this map are: |
I replaced the old colour maps and added both Teal and Cyan in version 0.6.0 (now live). |
Toying around with the new manipulation tools (#1 ) it became obvious that we should set as many of our colour maps to the same lightness range. Since we now have the tools to encourage the user to create new colour maps, they should mix together nicely, without jumps in lightness. I settled on a 0.1<L*<0.9 range as that is the most common among our colour maps, and made new versions for maps not using that range (Blue, Cyan, Green, Magenta, Orange, Stone and Yellow), with the .jscm files and visualisations in my development branch.
Discussing this with @AstroRobin there is no obvious reason to generate near-duplicate maps, so these would be replacing the current ones. I'm not including Garnet, Tropical and Ripe in this remake, as those have shortened dynamic ranges by design.
The text was updated successfully, but these errors were encountered: