The names of "Violet" and "Purple" on the new "standard" colour palette seem counter-intuitive. Admittedly there's a lot of confusion regarding these two terms (at least when not speaking of electromagnetic spectrum), but most sources that do distinguish them, seem to agree that purple is closer to red and violet is closer to blue. (We can ignore violet being a "real colour" at one end of the visible spectrum, since on RGB colourspace it's not.) Wikipedia: "In the traditional color wheel used by painters, violet and purple are both placed between red and blue. Purple occupies the space closer to red, between crimson and violet. Violet is closer to blue, and usually less intense and bright than purple." (https://en.wikipedia.org/wiki/Purple#Purple_vs._violet) See also https://en.wikipedia.org/wiki/Line_of_purples, https://jakubmarian.com/difference-between-violet-and-purple/, https://www.quora.com/What-is-the-difference-between-violet-and-purple Note that the colours themselves in the palette are fine, only their names should be switched. Applies also to "Light/Dark Violet/Purple".
So the RYB color wheel[1] on wikipedia has violet as the secondary color between red and blue, while other references have purple as the secondary color[2][3][4]. Stuart, Heiko, Adolfo: what is your take on this. [1] https://simple.wikipedia.org/wiki/Color_wheel#RYB_color_wheel [2] http://visualfocus.org/wp-content/uploads/2015/08/Ch5-28-colorwheel-Reference-S-03.jpg [3] https://i.pinimg.com/736x/01/40/5e/01405e89866555b95db805967707415f.jpg [4] http://web.archive.org/web/20170425072744/http://color-wheel-artist.com/basic-color-wheel.html
Another RYB colour wheel that shows both purple (between red and blue) and violet (between purple and blue): https://en.wikipedia.org/wiki/Color_wheel#/media/File:Color_star-en_(tertiary_names).svg (the "magenta" there is rather misnamed, though)
After reading through the references I agree with Mihkel to exchange the color names Purple and Violet.
(In reply to Heiko Tietze from comment #3) > After reading through the references I agree with Mihkel to exchange the > color names Purple and Violet. Sorry, as noted the actual colors are fine. What is labeled as Violet is Violet, what is labeled as Purple is Purple. So we would be "swapping" their column placement on the 12 col x 10 row matrix.
(In reply to V Stuart Foote from comment #4) > What is labeled as Violet is Violet, what is labeled as Purple is Purple. What is labelled as Violet should be labelled as Purple, and what is labelled Purple should be labelled Violet.
Created attachment 138734 [details] swapped columns (In reply to Mihkel Tõnnov from comment #2) > Another RYB colour wheel that shows both purple (between red and blue) and > violet (between purple and blue): > https://en.wikipedia.org/wiki/Color_wheel#/media/File:Color_star- > en_(tertiary_names).svg (the "magenta" there is rather misnamed, though) The image caption says "RGB color wheel". :D (In reply to V Stuart Foote from comment #4) > Sorry, as noted the actual colors are fine. What is labeled as Violet is > Violet, what is labeled as Purple is Purple. Noted by whom, as Mihkel is saying the labels should be swapped and i believe they likely shouldnt be based on the many color wheels in comment 1. > So we would be "swapping" their column placement on the 12 col x 10 row > matrix. Swapping the columns isnt the correct solution as that would break the color gradient flow.
(In reply to Yousuf Philips (jay) from comment #6) > Created attachment 138734 [details] > swapped columns > > (In reply to Mihkel Tõnnov from comment #2) > > Another RYB colour wheel that shows both purple (between red and blue) and > > violet (between purple and blue): > > https://en.wikipedia.org/wiki/Color_wheel#/media/File:Color_star- > > en_(tertiary_names).svg (the "magenta" there is rather misnamed, though) > > The image caption says "RGB color wheel". :D Err, no it doesn't?! And even if its caption *would* say it's RGB (which, again, it doesn't), then the image itself is clearly RYB (as red, yellow, blue are the primary colours there, and not red, green, blue). > (In reply to V Stuart Foote from comment #4) > > Sorry, as noted the actual colors are fine. What is labeled as Violet is > > Violet, what is labeled as Purple is Purple. > > Noted by whom, as Mihkel is saying the labels should be swapped and i > believe they likely shouldnt be based on the many color wheels in comment 1. I frankly didn't expect this to be such a controversial topic. I don't challenge the position of both purple and violet between red and blue (when not talking about "real colour" violet, which is beyond the blue spectre). It's just that violet is "bluer" than purple by most definitions. For reference, "purple": "1. any color having components of both red and blue, such as lavender, especially one deep in tone. /.../ 6. deep red; crimson." [1] "b (1) : tyrian purple (2) : any of various colors that fall about midway between red and blue in hue" [2] "a dark reddish-blue colour" [3] "1. A colour intermediate between red and blue. /.../ 2. A crimson dye" [4] [1] http://www.dictionary.com/browse/purple?s=t [2] https://www.merriam-webster.com/dictionary/purple [3] https://dictionary.cambridge.org/dictionary/english/purple [4] https://en.oxforddictionaries.com/definition/purple And "violet": "5. reddish-blue, a color at the opposite end of the visible spectrum from red, an effect of light with a wavelength between 400 and 450 nm." [5] "2 : any of a group of colors of reddish-blue hue, low lightness, and medium saturation" [6] "a bluish-purple colour" [7] "2. A bluish-purple colour seen at the end of the spectrum opposite red." [8] [5] http://www.dictionary.com/browse/violet?s=t [6] https://www.merriam-webster.com/dictionary/violet [7] https://dictionary.cambridge.org/dictionary/english/violet [8] https://en.oxforddictionaries.com/definition/violet Notable parts: * both purple and violet are "reddish-blue" (which they are; however such definition leaves much playroom and doesn't specify their position relative to each other) * purple is "about midway between red and blue" * purple has also a sense of crimson * violet is "bluish-purple" - meaning it's in the bluer part of aforementioned "reddish-blue" space. As far as RGB/RYB colour model is concerned, we can ignore the statement that violet is "at the end of the spectrum opposite red" - although in a way it does make it (much) closer (physically speaking) to blue than it is to red. I hope this explanation helped :) > > So we would be "swapping" their column placement on the 12 col x 10 row > > matrix. > > Swapping the columns isnt the correct solution as that would break the color > gradient flow. Please no-one swap the columns! :)
Purple and Violet are kind of a mess, as Jay shows reversing the columns would not work--we've got a really bad base color for both in the standard.soc--but then most of the base colors are off Hue. We are bouncing all over the hues of the RGB additive color wheel. How theoretically correct should the standard.soc be? None the less, we've set Purple to HSV (268°, 69%, 57%) and Violet to HSV (310°, 79%, 64%). The RGB additive color theory suggests we have this wrong if we accept the Wikipedia definitions: Purple: RGB #800080 (128, 0, 128), HSV (300°, 100%, 50%) Violet: RGB #7F00FF (128, 0, 255), HSV (270°, 100%, 100%) Woring with RGB HSV/B -- the Violet(s) should be out the 270° radial, and the Purple(s) out the 300° "Magenta" radial. And build a We do pickup the 270° color hue for Violet in the tonal.soc--matching theory at the 68% saturation, but interestingly in the html.soc the X11/HTML/SVG Violet is out the 300° radial with most of the "Purple, violet, and magenta colors".
Sorry, but don't we heavily bikeshed here? No one challenged the color palette itself, the question just boils down whether purple is more of a red color or rather blue. In my opinion Mihkel is right with red, he gave a lot of references to proof this. German combines the two terms to "Purpurrot" (purple red), I never heard about "violet red". (And I've not seen a good argument in this thread against swapping names.)
(In reply to Mihkel Tõnnov from comment #7) > > The image caption says "RGB color wheel". :D > > Err, no it doesn't?! And even if its caption *would* say it's RGB (which, > again, it doesn't), then the image itself is clearly RYB (as red, yellow, > blue are the primary colours there, and not red, green, blue). Sorry that was my mistake, as i ended up looking at this[1] after going through the page. :D [1] https://en.wikipedia.org/wiki/Color_wheel#/media/File:RBG_color_wheel.svg But clearly in the image, it shows that purple is a secondary color between red and blue, which is how the current color palette has, and voilet is the color between purple and blue, while the current color palette has indigo in the position. So as Stuart was mentioning in comment 8, the main issue is that we are not using standard base colors in the palette, which is causing problems in the naming. So having Purple (secondary color) follow Red (primary color) breaks the RYB color scheme that the palette follows. (In reply to Heiko Tietze from comment #9) > ... the question just boils down whether purple is more of a red > color or rather blue. In my opinion Mihkel is right with red, he gave a lot > of references to proof this. I dont see this as the issue, as according to RYB purple is a mix of red and blue and voilet is a mix of purple and blue. But if you check RGB, voilet is also a mix of magenta and blue.
Created attachment 138758 [details] RYB color palette generated with Gossett & Chen, and correctly assigning RYB Primary, RYB Secondary and traditional Tertiary names Swap in the attached standard.soc palette, used the Gosett & Chen algorithim based converter put up by Dave Eddy, https://bahamas10.github.io/ryb/about.html https://bahamas10.github.io/ryb/ at -180, -130, -80, -30, 0, +30, +80, +130, +180 Color names are the correct RYB Primaries: Red, Yellow, Blue; and the correct RYB Secondaries: Orange, Green, Purple. With example George Field RYB Tertiaries found in https://en.wikipedia.org/wiki/Tertiary_color So, I used the traditional: Magenta rather than our Brick Violet rather than our Indigo Chartreuse rather than our Lime Amber rather than our Gold Vermilion rather than our Brick but they could be changed back without fuss. This layout and color assignment is correct for a RYB based palette. What we had for standard.soc was a mess. The "levels" of the scales may need to be adjusted--but simple to set a brightness level -255 -> 0 <- +255, higher are lighter.
(In reply to V Stuart Foote from comment #11) > > https://bahamas10.github.io/ryb/ > > at -180, -130, -80, -30, 0, +30, +80, +130, +180 > To use this for generating an RYB based palette as for our standard.soc: --need to rotate to wheel to Yellow, so 105°. --take the default 12 divisions (generating Primaries, Secondaries, Tertiaries). --then reduce the ring count to 1. --finally set the brightness as needed for the SOC palette variant. The resulting wheel represents values for one row of our RYB palette. Save/download as SVG format. Then extract the fill="#HEX" for each of the 12 color values--they are positional in the downloaded SVG--keep them in the correct order when building the SOC palette draw:color stanzas for each row. Change the brightness for each new row of values in the palette. Generate, download and extract the color in RGB #HEX from the SVG--repeat. I probably should have used -200, -150, -50, 0, 50, 100, 150, 200 brightness--beyond that the colors are seem dark or too light. But I think this is a technically correct (and reproducible) way to generate the RYB based color palette that standard.soc now represents. It eliminates some of the arbitrary color choices that had made their way into the palette.
Created attachment 138760 [details] original RYB palette used in new standard.soc, with color names added Jay, * So looking at the commit [1] where we switched from HLV to set RYB colors, noticed this PNG https://bug-attachments.documentfoundation.org/attachment.cgi?id=111095 I've annotated the color names (of course the Tertiary could be the modern rather than the traditional) onto it, but if folks are happy with the RGB color representations pulled from this--we could just correct the labeling which got mixed up. So were you picking RGB from the image, or were they directly computed? =-ref-= [1] https://gerrit.libreoffice.org/#/c/36202/
(In reply to V Stuart Foote from comment #11) > Created attachment 138758 [details] Not bad but I prefer our coverage of red as Vermillion and Red are very close compared to Brick vs. Red. And the hue variation in the lower light area (light 2 and 1 to dark 1) is also quite small. If we change the color palette again, all subsidiary patches have to be redone. For example the patch for gradients, which is still pending a review (https://gerrit.libreoffice.org/#/c/46428/), makes no sense with different color values. Even worse when we would have started to update the Sky Tango Blue to whatever transition for the hard-coded values. I still wonder what arguments speak against just swapping the color names.
(In reply to V Stuart Foote from comment #13) > So looking at the commit [1] where we switched from HLV to set RYB colors, > noticed this PNG > https://bug-attachments.documentfoundation.org/attachment.cgi?id=111095 The old color palette was something heiko came up. > So were you picking RGB from the image, or were they directly computed? They were picked directly from the image.
Created attachment 138766 [details] original RYB palette with modern names (In reply to Yousuf Philips (jay) from comment #15) > > So were you picking RGB from the image, or were they directly computed? > > They were picked directly from the image. OK so that is a technical issue with the colors--and using the the generator directly would result in a more correct rendering of a RYB palette--but at this point the only actual "error" is our labeling of Magenta as "Violet". Look at the attached image, the Indigo scale is correctly also know as Violet. Fixing this we would leave the RGB Hex values as are, but need to change all the standard.soc Violet names to Magenta... and would also need to tweak Gabor's work on translation strings (.hxx, .hrc)[1] Not sure if the new gradients need any attention. =-ref-= [1] https://gerrit.libreoffice.org/#/c/41330
I guess the other point to make is that, when corrected to use the Magenta tertiary, the standard.soc (and any derived gradients) would not have a "Violet" color label. We've switched to the modern RYB tertiary name of "Indigo". Do we want Indigo or Violet?
Created attachment 138777 [details] stuart palette vs current palette (In reply to V Stuart Foote from comment #11) > Created attachment 138758 [details] Colors are definitely richer as they are standard colors compared to our hued colors, but the colors in rows 2 and 6 are pretty much identical (yellow = ff000, light yellow 1 = ffff0a), and row 7 isnt much darker to row 2, though it is called dark **** 1. (In reply to V Stuart Foote from comment #16) > OK so that is a technical issue with the colors--and using the the generator > directly would result in a more correct rendering of a RYB palette--but at > this point the only actual "error" is our labeling of Magenta as "Violet". If the color fits Magenta, then this would be the correct fix. (In reply to V Stuart Foote from comment #17) > Do we want Indigo or Violet? I'd stay with Indigo.
Created attachment 138791 [details] generated RYB color palette with adjusted brighness and "modern" tertiary color names (In reply to Yousuf Philips (jay) from comment #18) > > Colors are definitely richer as they are standard colors compared to our > hued colors, but the colors in rows 2 and 6 are pretty much identical > (yellow = ff000, light yellow 1 = ffff0a), and row 7 isnt much darker to row > 2, though it is called dark **** 1. OK, attaching another standard.soc, this one also using the Eddy's Gosett & Chen based RYB => RGB converter [1] but with row brightness adjusted to -180, -160, -130, -80, 0, +80, +130, +160, +180 0 brightness is row 2 holding the base RYB colors: Yellow, Amber, Gold, Orange, Brick, Red, Magenta, Purple, Indigo, Blue, Teal, Green, Lime using modern tertiary names. Seem to have a little more distinct gradient by dropping the brightness 30 increment and adding the 160. =-ref-= [1] https://bahamas10.github.io/ryb/
Created attachment 138792 [details] screenclip current standard palette vs a generated RYB palette (attachment 138791 [details])
(In reply to V Stuart Foote from comment #19) > 0 brightness is row 2 holding the base RYB colors: Yellow, Amber, Gold, > Orange, Brick, Red, Magenta, Purple, Indigo, Blue, Teal, Green, Lime using > modern tertiary names. Sorry, traditional Amber was replaced by modern Gold--its not included.
(In reply to V Stuart Foote from comment #19) > OK, attaching another standard.soc, this one also using the Eddy's Gosett & > Chen based RYB => RGB converter [1] but with row brightness adjusted to > -180, -160, -130, -80, 0, +80, +130, +160, +180 Dark colors 2-4 are almost the same, and since the pastel tones are underrepresented I would move the spectrum two steps. There is no good reason to have equidistant luminescence values.
Created attachment 138825 [details] generated RYB color palette regenerated a RYB => RGB standard.soc adjusting brightness sequence: 0 -> base RYB 185 -> light 4 160 -> light 3 130 -> light 2 90 -> light 1 -65 -> dark 1 -120 -> dark 2 -150 -> dark 3 -180 -> dark 4
Created attachment 138826 [details] generated RYB color palette (rev 2) revised RYB => RGB scale Brightness values 185, 160, 130, 90, 0, -65, -120, -150, -180 0 is row 2 then, descending light 4 -> dark 4
(In reply to V Stuart Foote from comment #23) > Created attachment 138825 [details] Still too dark. The palette has two rows of very dark and muted colors but only one with pastel tones. I would make the brightest colors almost white like the dark are almost black. When using as fill color on large areas those colors make a lot of sense. And what I liked on the current standard palette, the nice green/blue coverage has changed into a better representation of yellow/red. But that was your intention, I guess.
(In reply to Heiko Tietze from comment #25) > (In reply to V Stuart Foote from comment #23) > > Created attachment 138825 [details] > > Still too dark. The palette has two rows of very dark and muted colors but > only one with pastel tones. I would make the brightest colors almost white > like the dark are almost black. When using as fill color on large areas > those colors make a lot of sense. OK. Can do that. But maybe give me a brightness level you would like for each of the light and dark values by using the generator: https://bahamas10.github.io/ryb/ (set the rings count to 1 to see a full slice of the color) The 180, 160, 130, 90, 0, -65, -120, -150, -180 brightness values are what I've used for revision 2. > > And what I liked on the current standard palette, the nice green/blue > coverage has changed into a better representation of yellow/red. But that > was your intention, I guess. Yes, but the current standard palette is a technically corrupt representation of RYB--and because we picked the colors off the PNG image we are not able to adjust it. Whereas using the generator and setting its brightness values, we generate theoretical RYB palette colors consistently at each selected brightness level--as represented here.
(In reply to V Stuart Foote from comment #26) > OK. Can do that. But maybe give me a brightness level you would like for > each of the light and dark values by using the generator: > > https://bahamas10.github.io/ryb/ An option would be 200, 170, 140, 110, 80, 0, -60, -120, -180 but the typical distribution is non-linear. Some formulas can be found with "relative luminance", such as from CIELAB, where I let others understand the math.
Created attachment 138862 [details] generated RYB color palette (rev3) Heiko's (In reply to Heiko Tietze from comment #27) > An option would be 200, 170, 140, 110, 80, 0, -60, -120, -180 but the > typical distribution is non-linear. Some formulas can be found with > "relative luminance", such as from CIELAB, where I let others understand the > math. Attached. And in the standard.soc now have light 1-5 and dark 1-3.
Created attachment 138863 [details] generated RYB color palette (rev 3) standard.soc not ready to merge, has some of the other brightness rows still included but commented out
Created attachment 138864 [details] 10 row version of RYB palette
Created attachment 138865 [details] 10 row standard.soc +200 > -180, 5 light 3 dark
Created attachment 138868 [details] ODT table with the rev3 palette as requested at 2018-01-03 design meeting, a larger table with the rev3 palette with brighness levels: 200, 170, 140, 110, 80, 0, -60, -120, -180 and Light 5 - 1, and Dark 1 -3.
Created attachment 138871 [details] ODT table with the rev3 palette (corrected Dark Lime 2 cell)
The last step is too big and I would also increase the 80 step. So my update: 200,170,150,110,60,-50,-100,-160 also based on the W3 standard formula POWER((x + 0.055) / 1.055; 2.4), which would be more like 200,180,160,130,90,-30,-100,-180.
Created attachment 138879 [details] 10 row standard.soc +200 > -160 (rev4) 10 row standard SOC with RYB brightness +200, +170, +150, +110, +60, 0, -50, -100, -160. Note: this file is not ready to merge as it has these additional RYB brightness rows commented out: +185, +180, +160, +140, +130, +90, +80, -60, -65, -80, -120, -130, -150, -180
Created attachment 138880 [details] ODT with table showing rev4 palette, 5 light, 3 dark and base RYB
Noc changes required from my side. Great work, Stuart.
(In reply to V Stuart Foote from comment #36) > Created attachment 138880 [details] > ODT with table showing rev4 palette, 5 light, 3 dark and base RYB The difference between +60 and base or base and -50 is quite negligible, especially with the base colors. Having 5 light variants still feels like overkill to me and think the 4 light and 4 dark is the better option, else we reduce it to 3 light and 3 dark like google docs.
Created attachment 138995 [details] sample with the rev4 palette (In reply to Yousuf Philips (jay) from comment #38) > The difference between +60 and base or base and -50 is quite negligible, > especially with the base colors. Having 5 light variants still feels like > overkill to me and think the 4 light and 4 dark is the better option, else > we reduce it to 3 light and 3 dark like google docs. Assume we would have to keep the "0" brightness as the base RYB color (from Itten's Color theory work)--but beyond that is the row count even an issue, as we move the base to the top below the grayscale? We would not want to go over 10 rows (triggers the scrollbar in the picker) but if not 10, then sure 9 or 8 would also work. Jay, what would be your splits?
Created attachment 138997 [details] sample with rev4 palette
Created attachment 138998 [details] ODT with table showing rev4 palette, 5 light, 3 dark and base RYB
(In reply to V Stuart Foote from comment #39) > Assume we would have to keep the "0" brightness as the base RYB color (from > Itten's Color theory work)--but beyond that is the row count even an issue, > as we move the base to the top below the grayscale? > > We would not want to go over 10 rows (triggers the scrollbar in the picker) > but if not 10, then sure 9 or 8 would also work. Well the ideal row count is to have 10 (1 grayscale, 1 base colors, 8 base color variants), as that is what we decided was the best size based on the tonal and standard palettes and not to trigger the scrollbar. > Jay, what would be your splits? My split has always been 4 light and 4 dark so that it fills the necessary 10 rows, as we have today, and would cover more of the base color variant spectrum, but if we cant find 4 suitable dark colors, then we should reduce it to 3 light and 3 dark. We initially had 4 light and 3 dark as found in the color wheel, but added the 4th dark when we decided to go for 10 rows and heiko felt the wheel missed darker colors which he had in his color palette[1] that came with LO 5.3. In the 5.3 and 5.4 color palettes, the base color variants adjusted both brightness and saturation, and maybe we add saturation to the mix for the suggested new color palette to have more differences between the colors. [1] https://design.blog.documentfoundation.org/wp-content/uploads/sites/2/2016/12/Figure3-1.png
Created attachment 139003 [details] rev5 -- standard.soc - Grayscale, Hues, 4 tints (30%, 45%, 60%, 75% white added), 4 shades (20%, 40%, 60%, 80% black added) OK another stab at the RYB color theory. Itten work suggests lightning the Hues adding white produces "tints", and darkening the Hues adding black are "shades". And Eddy's Gossett and Chen implementation seems to be handling "brightness" along the White/Black diagonal of the tesor, fully saturated base hue at 0 tints as white value increases shades as black value increases. So keeping 4 tints, 4 shades and the base RYB hues give a nice Itten centric palette. In this rev 5 of standard soc have generated 4 tints 30% (77), 45% (115), 60% (153) and 75% white (191); and 4 shades 20% (-51), 40% (-102), 60% (-153), 80% black (-204). So back to 4 light and 4 dark, plus base Hue, plus grayscale for 10 rows. Attaching sample ODT and screen clip.
Created attachment 139004 [details] sample with rev5 palette
Created attachment 139005 [details] ODT with table showing rev5 palette -- tints and shades of hues
(In reply to V Stuart Foote from comment #43) > along the White/Black diagonal of the tesor ... s/tesor/tensor/ as in the tensor needed for trilinear interpolation the algorithm performs to assign RGB values.
This blog post presents a practical and concise demonstration of why structuring a "Itten" centric RYB palette for standard use is so appealing if we get it right: https://99designs.com/blog/tips/color-the-world-create-compelling-color-schemes/ Turns out the Itten hues are simple, but holding the tints and shades at correct levels--a bit more of a challenge.
Created attachment 139006 [details] standard.soc (rev5) - Grayscale, Hues, 4 tints (30%, 45%, 60%, 75% white added), 4 shades (20%, 40%, 60%, 80% black added)
heiko tietze committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bbde6eeae5c0ca5e106eec53dc7882361897a616 tdf#114719 RYB based color palette It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
After checking this color palette I find it dissatisfactory for its inaccuracy in some extreme cases. In particular, when it comes to dark colors: <draw:color draw:name="Dark Blue 4" draw:color="#362413"/> <draw:color draw:name="Dark Teal 4" draw:color="#302709"/> If I interpret the numbers correctly (like R36, G24, B13), this is not blue but is an orange/brown color. The problem is probably rooted in this RYB color space. The space is generated by something like a translation from an RGB color space, where every color is mapped in a certain way with a little orange in order to obtain yellow as the primary color. One of the consequences is the general decrease of saturation in blue--green colors. Actually the gray scale turns orange too (Clearly 7f7f7f becomes 9c744a by the transformation in https://bahamas10.github.io/ryb/). Since turning the brightness off base naturally reduces saturation, in extreme cases the blue itself is overriden by the translation of the space. With scientific minds, modern standard color spaces should be either RGB (for screen) or CMYK (for print). A reduced-saturation version of them can be more favorable. Why do we bother to use an RYB instead and get all the messes?
(In reply to Flora Canou from comment #50) > After checking this color palette I find it dissatisfactory for its > inaccuracy in some extreme cases. In particular, when it comes to dark > colors: > > <draw:color draw:name="Dark Blue 4" draw:color="#362413"/> > <draw:color draw:name="Dark Teal 4" draw:color="#302709"/> > > If I interpret the numbers correctly (like R36, G24, B13), this is not blue > but is an orange/brown color. > > The problem is probably rooted in this RYB color space. The space is > generated by something like a translation from an RGB color space, where > every color is mapped in a certain way with a little orange in order to > obtain yellow as the primary color. One of the consequences is the general > decrease of saturation in blue--green colors. Actually the gray scale turns > orange too (Clearly 7f7f7f becomes 9c744a by the transformation in > https://bahamas10.github.io/ryb/). Since turning the brightness off base > naturally reduces saturation, in extreme cases the blue itself is overriden > by the translation of the space. > > With scientific minds, modern standard color spaces should be either RGB > (for screen) or CMYK (for print). A reduced-saturation version of them can > be more favorable. Why do we bother to use an RYB instead and get all the > messes? True, see attachment 139004 [details] for where the 80% shade ends up a bit smeared--but then that is exactly the outcome of doing additive colors isn't it? The model holds nicely. And simply put, majority of our LibreOffice casual users prefer a RYB for additive color design for their default standard palette. Using a Tensor based algorithm to generate colors may have flaws--but its use offers consistency--so if rather than the 80% shade (i.e. 204/255 on the white black diagonal), a user could generate a set of 65% shades that might have a bit more RGB accuracy to parent hue. But the reality is we can not support CMYK nor HSL color models in the LibreOffice document canvas--so an algorithmicly generated RYB color palette is just as viable. And, we could tweak the dark end of the gradient 70% rather than 80%, lightening the colors and aligning them more with the hue--beyond that deviating from the algorithm's generated values is really not justified.
(In reply to V Stuart Foote from comment #51) > ... The flaw consists in the algorithm. If we must keep an RYB-based palette, it is favorable to find one that does not go wrong in dark colors. This palette also looks generally too warm in my eyes. Maybe I'll try developing an RGB-based standard palette as an extension
(In reply to Flora Canou from comment #52) > (In reply to V Stuart Foote from comment #51) > > ... > > The flaw consists in the algorithm. If we must keep an RYB-based palette, it > is favorable to find one that does not go wrong in dark colors. > OK will close as there is no better RYB palette generator. But as indicated still may move the 4th shade from 80% to ~70%, but Shades are always going to drift from the hue--even mixing paint in real world... => RF > > This palette also looks generally too warm in my eyes. Maybe I'll try > developing an RGB-based standard palette as an extension Looking forward to it, but would suggest you not name extension as standard palette (standard.soc); rather if you compose a RGB (HSV based) you like, loading the extension can swap it in for the standard.soc palette if that is your goal. Just watch out for Light Blue 2 and Dark Blue 1 as those values are hard coded in the unit tests.
(In reply to V Stuart Foote from comment #53) > Looking forward to it, but would suggest you not name extension as standard > palette (standard.soc); rather if you compose a RGB (HSV based) you like, > loading the extension can swap it in for the standard.soc palette if that is > your goal. Just made the standard RGB color palette, using the name "Standard RGB". It's currently available here: https://github.com/FloraCanou/standardrgb-palette-loext (since the official extension site is rather slow). I'm also trying to develop an optimized RYB-RGB conversion algorithm. I can't catch the 6.1 release though. > Just watch out for Light Blue 2 and Dark Blue 1 as those values are hard > coded in the unit tests. I don't quite understand this. Could you please note in detail what I need to do about it?
Created attachment 143677 [details] color picker palette Standard & Tonal and a RBG palette using Canou-Zheng Improved HCI (In reply to Flora Canou from comment #54) > > Just made the standard RGB color palette, using the name "Standard RGB". > It's currently available here: > https://github.com/FloraCanou/standardrgb-palette-loext (since the official > extension site is rather slow). The gradient is smooth, and RGB colors quite acurate, it looks nice, unfortunately the full palette tends toward the pastels. The same issue as with the freecolour-HLC CIELAB reference palette. Need more highly saturated RGB colors. For example the "tonal" technical palette--perhaps alligh the name/color pairings (from the tonal 58% row) across these two RGB centric palettes adjusting the starting point. But if just an extension--your call on that stylistic facet. Also, to simplify things for translators should this be added to core, I would suggest you adopt the color naming from the tonal palette of Spring Green and Chartreuse rather than the non-standard Lime and Turquoise you've assigned. > I'm also trying to develop an optimized RYB-RGB conversion algorithm. I > can't catch the 6.1 release though. > 6.1 is string and feature frozen, we are committed to a RYB palette. But improving the RGB/HSI color correctness for RYB hue, tints and especially the shades would be a valid patch for the release. Looking forward to see if you can improve on the Gosett & Chen algorithm used by Eddy. > (In reply to V Stuart Foote from comment #53) > > Just watch out for Light Blue 2 and Dark Blue 1 as those values are hard > > coded in the unit tests. > > I don't quite understand this. Could you please note in detail what I need > to do about it? IIRC several unit tests pick up the defined COL_DEFAULT_SHAPE_FILLING and COL_DEFAULT_SHAPE_STROKE [1] and automated qa unit tests break when we've removed those specific values from the standard.soc, or have changed their assigned values in the xdef.hxx... Heiko? =-ref-= [1] https://opengrok.libreoffice.org/xref/core/include/svx/xdef.hxx#81
(In reply to V Stuart Foote from comment #55) > ... > The gradient is smooth, and RGB colors quite acurate, it looks nice, > unfortunately the full palette tends toward the pastels. The same issue as > with the freecolour-HLC CIELAB reference palette. > > Need more highly saturated RGB colors. For example the "tonal" technical > palette--perhaps alligh the name/color pairings (from the tonal 58% row) > across these two RGB centric palettes adjusting the starting point. But if > just an extension--your call on that stylistic facet. I've looked into this issue and decide to keep the current state, because (1) it already has three rows of fully saturated entries (the 2nd row, the 85% row and the 15% row), (2) _tonal_ is there, and (3) IMO slightly neutral color set looks better for documents. > Also, to simplify things for translators should this be added to core, I > would suggest you adopt the color naming from the tonal palette of Spring > Green and Chartreuse rather than the non-standard Lime and Turquoise you've > assigned. I've changed _lime_ to _chartreuse_ since I find _lime_ is a quaternary for standard RGB. _Turquoise_ is kept because (1) _spring green_ is two words and thus sounds dumb, (not to mention it's almost a homophone of "dumbass" in my mother tongue (Chinese Mandarin)) (2) translation/interpretation can always be done on the color and not the wording. Now that some say it's impossible to produce pure black by RYB blending, I somehow accept the current algorithm -- it's defected by nature and showing nature is fine. Studying for a better algorithm is costly. I'll try though.