Updating color palette of dots. #7
Open
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
I did a little testing with the RGB palette and noticed that the closer the values are in relative to each other the closer the color is to a grayscale palette(EX. R = 140, G = 140, B = 140; R = 24 G = 24, B = 24, etc. So to avoid that, I added new integers "p,w,v" that represent the difference between the RGB values to vary by at least 80. These "p,w,v" values are then inputted into the while parameter. Example: if R was at a value of 200, the green and blue value being outputted cannot be anything over 120, and if otherwise the values will be "re-rolled" at another value until the parameters are met. Additionally, addressing the dot.isRGBNotWhite's parameters, since the greater the RGB values are the darker it is, these parameters are to avoid darker colors? I personally like that as an extra precaution to get rid of the grayscale colors in the darker area to avoid a "near-black" color. So in addition to parameters values of over 220, perhaps we can also add parameters that are less than something like 50 (or a smaller value) as they represent more of the "lighter" palette? If we go through those changes of both not white, nor black, or a grayscale color in that matter LOL. Maybe we can rename the boolean function to like "isRGBNotGrayscale" or something like that.
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.
I did a little testing with the RGB palette and noticed that the closer the values are in relative to each other the closer the color is to a grayscale palette(EX. R = 140, G = 140, B = 140; R = 24 G = 24, B = 24, etc. So to avoid that, I added new integers "p,w,v" that represent the difference between the RGB values to vary by at least 80. These "p,w,v" values are then inputted into the while parameter. Example: if R was at a value of 200, the green and blue value being outputted cannot be anything over 120, and if otherwise the values will be "re-rolled" at another value until the parameters are met.
Additionally, addressing the dot.isRGBNotWhite's parameters, since the greater the RGB values are the darker it is, these parameters are to avoid darker colors? I personally like that as an extra precaution to get rid of the grayscale colors in the darker area to avoid a "near-black" color. So in addition to parameters values of over 220, perhaps we can also add parameters that are less than something like 50 (or a smaller value) as they represent more of the "lighter" palette?
If we go through those changes of both not white, nor black, or a grayscale color in that matter LOL. Maybe we can rename the boolean function to like "isRGBNotGrayscale" or something like that.