[Libreoffice-bugs] [Bug 114719] New RYB based standard palette: cleanup assigned RGB values and color names (result comment 44)
https://bugs.documentfoundation.org/show_bug.cgi?id=114719 V Stuart Foote changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=12 ||1683 -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 114719] New RYB based standard palette: cleanup assigned RGB values and color names (result comment 44)
https://bugs.documentfoundation.org/show_bug.cgi?id=114719 --- Comment #56 from Flora Canou --- (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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 114719] New RYB based standard palette: cleanup assigned RGB values and color names (result comment 44)
https://bugs.documentfoundation.org/show_bug.cgi?id=114719 --- Comment #55 from V Stuart Foote --- Created attachment 143677 --> https://bugs.documentfoundation.org/attachment.cgi?id=143677=edit 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 -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 114719] New RYB based standard palette: cleanup assigned RGB values and color names (result comment 44)
https://bugs.documentfoundation.org/show_bug.cgi?id=114719 --- Comment #54 from Flora Canou --- (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? -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 114719] New RYB based standard palette: cleanup assigned RGB values and color names (result comment 44)
https://bugs.documentfoundation.org/show_bug.cgi?id=114719 V Stuart Foote changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #53 from V Stuart Foote --- (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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 114719] New RYB based standard palette: cleanup assigned RGB values and color names (result comment 44)
https://bugs.documentfoundation.org/show_bug.cgi?id=114719 --- Comment #52 from Flora Canou --- (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 -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 114719] New RYB based standard palette: cleanup assigned RGB values and color names (result comment 44)
https://bugs.documentfoundation.org/show_bug.cgi?id=114719 --- Comment #51 from V Stuart Foote --- (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: > > > > > 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 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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 114719] New RYB based standard palette: cleanup assigned RGB values and color names (result comment 44)
https://bugs.documentfoundation.org/show_bug.cgi?id=114719 Flora Canou changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #50 from Flora Canou --- After checking this color palette I find it dissatisfactory for its inaccuracy in some extreme cases. In particular, when it comes to dark colors: 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? -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 114719] New RYB based standard palette: cleanup assigned RGB values and color names (result comment 44)
https://bugs.documentfoundation.org/show_bug.cgi?id=114719 V Stuart Foote changed: What|Removed |Added Summary|New RYB based standard |New RYB based standard |palette: cleanup assigned |palette: cleanup assigned |RGB values and color names |RGB values and color names |(comment 45)|(result comment 44) -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
