Re: [dev] [st] Colors slightly different hue than in xterm
2014-05-22 1:57 GMT+04:00 Roberto E. Vargas Caballero k...@shike2.com:
Read this: http://www.4p8.com/eric.brasseur/gamma.html
We need to generally re-think the algorithm used here. I hate the idea
of being conformant to this or that terminal emulator and instead
prefer an implementation according to how it's defined (!).
I like this idea, but I don't know how it could be implemented.
The obvious idea is to convert a colour to HSV/HSL, increase
brightness, and convert it back
(One cannot help but notice that such a calculation is a matter of
initialization, since appropriate bright colours may be calculated for
all built-in colours in advance. Therefore, one possible solution may
be to modify dc.col (also xloadcols and xsetcolorname) to have
structures, containing normal and bold variants for a colour.)
After this point, dragons lie.
In HSV model, there are notions of Value, which is equal to maximum
among colors, and Saturation, which is 1 - Max/Min. Thus, Max = V, Min
= V (1 - S).
Then,
R = r * Max + (1 - r) * Min = V * (r + (1 - r) * (1 - S)),
G = g * Max + (1 - g) * Min = ..., and so on, and r, g, b depend only
on Hue. It is then trivial to see that a change in Brightness is a
trivial rescale: R_{new} = V_{new} * R_{old}/V_{old}. (In linear
space, not gamma space.) It's a simple calculation indeed, but, as
XTerm cube contains a lot of colours close to pure, it may not look
appropriate.
In HSL model, there are notions of Saturation and Lightness.
Saturation is calculated as (Max - Min)/(1 - |1 - (Max + Min)|), and
Lightness as (Max + Min)/2. Thus, reverse calculations of Max and Min
are a little more involved, but the general truth remains the same:
all colour components are convex combinations between Max and Min,
whose coefficients depend only on Hue.
Thus, for R coordinate for example, R_{new} = (R_{old} - Min_{old}) /
(Max_{old} - Min_{old}) * (Max_{new} - Min_{new}) + Min_{new}. It's
the same rescaling but with two points instead of one.
(I cannot emphanise enough that we DO NOT need luminance or perceived
brightness here. These define the brightness of all colours to come
common reference point, whereas lightness/value define brightness
relative to a reference color of the same hue. Which is exactly what
we need. Default colors are of different brightnesses, and this is not
our concern.)
Let us now estimate how precise should we be in our tables of sRGB -
linear conversion. Let's say that, for the simplicity, we use the
evenly-spaced table and linear interpolation. (Dreadful.) The error is
estimated thus by h^2 * 1/8 max(f''(x)). for sRGB-linear, the
constant is 3.429/8 = 0.428. Let's say we want the precision of 2e-16,
which is totally reasonable considering that we use 16-bit color
model. And I might say, is ain't so bad! We merely need ~170 data
points. Let's go big and make it 257. (Then, the index for a 16-bit
integer is just number8.)
As for the reverse transofrmation, there we experience a big uprise
around zero. In fact, the second derivative peaks at ~-2300, which is
indeed true: the function curves a lot there, and interpolating it is
the world of trouble, requiring ~4300 points, which is distressingly
only slightly more than 4096. Makes things even worse.
Fortunately, we happen to know the reverse function for this one,
which is not only pretty smooth - but we also have a table for it! So
the task results in binary search in aforementioned table (of size
257, I might remind you, so it's more or less instant) and doing a
linear interpolation afterwards. Slower, but saves us a lot of
trouble!
Thus, the proposal requires addition of:
- the table of 16-bit integers of size 257;
- the function of interpolating y given x1, x2, y1, y2 and x;
- the function of increasing a given color's brightness;
- possibly changes to dc.col, depending on how costly it will be to do
such calculations on the fly vs in the initialization.
--
Best regards,
Alexander Sedov.
Re: [dev] [st] Colors slightly different hue than in xterm
I thought I'd re-read this thread, as it was brought up again recently. Quoth Eric Pruitt: On Mon, Dec 02, 2013 at 10:54:54AM +0100, Christoph Lohmann wrote: Brilliant! I feel silly for not noticing it only affected the bold colors. The fix was simple, and I've attached a patch in the event other people prefer the xterm behavior. No, fix xterm to brighten all colors. I won’t reduce the features of st because of compatibility to a sloc beast. [snip] That said, I don't really think the current method of increase the color number actually guarantees the replacement color will actually be brighter outside the grayscale range This seems like a reasonable point to me. If increasing brightness of coloured text isn't something we can do accurately by changing the colour, in the limitations of 256 colour, doing as this patch does sounds sensible to me.
Re: [dev] [st] Colors slightly different hue than in xterm
On Wed, 21 May 2014 16:21:05 -0400 Nick suckless-...@njw.me.uk wrote: This seems like a reasonable point to me. If increasing brightness of coloured text isn't something we can do accurately by changing the colour, in the limitations of 256 colour, doing as this patch does sounds sensible to me. Read this: http://www.4p8.com/eric.brasseur/gamma.html We need to generally re-think the algorithm used here. I hate the idea of being conformant to this or that terminal emulator and instead prefer an implementation according to how it's defined (!). Cheers FRIGN -- FRIGN d...@frign.de
Re: [dev] [st] Colors slightly different hue than in xterm
Read this: http://www.4p8.com/eric.brasseur/gamma.html We need to generally re-think the algorithm used here. I hate the idea of being conformant to this or that terminal emulator and instead prefer an implementation according to how it's defined (!). I like this idea, but I don't know how it could be implemented. Regards, -- Roberto E. Vargas Caballero
Re: [dev] [st] Colors slightly different hue than in xterm
2013/12/2 Eric Pruitt eric.pru...@gmail.com: On Mon, Dec 02, 2013 at 10:54:54AM +0100, Christoph Lohmann wrote: No, fix xterm to brighten all colors. I won’t reduce the features of st because of compatibility to a sloc beast. I'm not asking you to apply the patch to tip, I'm simply posting the patch for other people that may also like their existing color scheme to remain unchanged. That said, I don't really think the current method of increase the color number actually guarantees the replacement color will actually be brighter outside the grayscale range, and on my monitor, the change in color by brightening them is too drastic for me to consider many of the replacements the same color as the unadulterated values; in the screenshot I posted, what was once green became yellow, and what was once blue purple. Although colors are a very subjective thing, perhaps a more sophisticated method could be used to brighten colors that makes this less of an issue. Eric Hello, it seems that st uses one of color-cube colors to introduce bold brightening. Clearly, for a color in xterm color cube, there is almost never a color with the same hue, but another lightness. Probably modifying color components, like with ATTR_INVERSE, would be better? -- Best regards, Alexander.
Re: [dev] [st] Colors slightly different hue than in xterm
2013/12/3 Alexander S. alex0pla...@gmail.com: Hello, it seems that st uses one of color-cube colors to introduce bold brightening. Clearly, for a color in xterm color cube, there is almost never a color with the same hue, but another lightness. Probably modifying color components, like with ATTR_INVERSE, would be better? Err, MODE_REVERSE, of course.
Re: [dev] [st] Colors slightly different hue than in xterm
Greetings. On Mon, 02 Dec 2013 10:54:54 +0100 Eric Pruitt eric.pru...@gmail.com wrote: On Mon, Dec 02, 2013 at 01:40:12AM +0100, Markus Teich wrote: Heyho, Seems to be related to the colors of bold/bright text. --Markus Brilliant! I feel silly for not noticing it only affected the bold colors. The fix was simple, and I've attached a patch in the event other people prefer the xterm behavior. No, fix xterm to brighten all colors. I won’t reduce the features of st because of compatibility to a sloc beast. Sincerely, Christoph Lohmann
Re: [dev] [st] Colors slightly different hue than in xterm
On Mon, Dec 02, 2013 at 10:54:54AM +0100, Christoph Lohmann wrote: Brilliant! I feel silly for not noticing it only affected the bold colors. The fix was simple, and I've attached a patch in the event other people prefer the xterm behavior. No, fix xterm to brighten all colors. I won’t reduce the features of st because of compatibility to a sloc beast. I'm not asking you to apply the patch to tip, I'm simply posting the patch for other people that may also like their existing color scheme to remain unchanged. That said, I don't really think the current method of increase the color number actually guarantees the replacement color will actually be brighter outside the grayscale range, and on my monitor, the change in color by brightening them is too drastic for me to consider many of the replacements the same color as the unadulterated values; in the screenshot I posted, what was once green became yellow, and what was once blue purple. Although colors are a very subjective thing, perhaps a more sophisticated method could be used to brighten colors that makes this less of an issue. Eric
Re: [dev] [st] Colors slightly different hue than in xterm
Eric Pruitt wrote: The most notable difference is in the keywords if, else, and continue but for and NULL are also slightly different colors despite both screenshots using the same Vim color scheme. Heyho, Seems to be related to the colors of bold/bright text. --Markus
