#2156 Wrong background with sixel truecolor terminal

[Anonymous]

$ gnuplot --version
gnuplot 5.2 patchlevel 6

I'm running Arch Linux, and I'm running gnuplot in an xterm invoked as:

$ xterm -ti vt340

In gnuplot, if I run

gnuplot> set term sixelgd
gnuplot> plot sin(x)

I get a nice plot with a white background. If I now run:

gnuplot> set term sixelgd truecolor
gnuplot> plot sin(x)

I get a horrible plot with a purple background. Changing the terminal's background color doesn't seem to work. For example, doing

gnuplot> set terminal sixelgd truecolor background '#000000'

results in a darker purple background, while

gnuplot> set terminal sixelgd truecolor background '#0f0f0f'

results in an almost black background.

[Ethan Merritt]

This is not a limitation in gnuplot, but in the xterm color support.
To the best of my knowledge xterm does not support 24-bit RGB (truecolor). At any rate xterm-327, which is the most recent I have the source for, does not. There are other terminal emulators that do support 24-bit RGB, but they mostly do not support sixel graphics. So if you really need RGB color and sixel output, you may have to search to find a suitable terminal emulater. Here is what it says in the gnuplot sixelgd terminal documentation:

The terminal has been sucessfully tested with the xterm, mlterm and mintty
 terminals.  The later two support the `truecolor` mode using 256 sixel
 colors out of box. Distributed copies of xterm may or may not have been
 configured to support sixel graphics and may be limited to 16 colors.

You might also be interested in gnuplot's svg/dom terminal, which acts similarly to the sixel terminal in that it displays in-line on a terminal emulator. Instead of requiring sixel emulation, however, it requires svg support. See for example: http://domterm.org

[Ross Combs]

XTerm supports any number of colors for sixel graphics, if configured. For example, with 4096 colors:

XTerm*numColorRegisters: 4096

The colors are always indexed, so there's no true color support. I'm somewhat doubtful about the utility for such a thing: any true color palette in 256 bits would have to be something painful like 3 bits red, 3 bits green, 2 bits blue.

The default palette just has 16 colors matching those on the VT340 if in vt340 mode, but I recommend setting any colors used and not relying on the default.

It's possible to query the maximum color count, but that's probably too messy and there could be a GnuPlot terminal setting for it instead.

[Ethan Merritt]

I have never had any luck building xterm to support additional colors.
Here is a screenshot of

  set term sixelgd truecolor
  test palette

using mlterm rather than xterm. It supports truecolor (32-bit) out of the box.

I also find the color handling quite decent used with yaft as a linux console terminal. And to be fair, the color dithering by xterm in "16 color" mode is not bad either.

[Ross Combs]

Like I said though, it doesn't support truecolor (which would effectively
give a large predefined palette), but it supports arbitrary numbers of
colors with that X resource setting (no compilation flags needed).

Do you have a reference for the truecolor spec? I can look into adding it
to XTerm. It wasn't in DEC's sixel implementation.

-Ross

[Ethan Merritt]

A bit of history here:
https://utcc.utoronto.ca/~cks/space/blog/unix/X11TruecolorHistory?showcomments
Basically it just means 24 bits of color information, one byte each of R G B. "Truecolor" was more of a marketing term than a separate standard.

Back when I was initially trying to get this to work I corresponded with the current xterm maintainer, Thomas Dickey. He was open to accepting patches if needed, but I could never get it to work even with his help. Eventually I decided that the version configured with 256 colors was good enough for my purposes and that's what I've been using ever since. There are other terminal emulators and other gnuplot terminals if I really need 24bit color or an alpha channel.

Gnuplot did have code at one point to create indexed RGB color on demand. I.e. you could specify full 24bit colors one by one until you ran out of index slots, say 256, and after that you would get "closest previously requested color". The first part of that worked fine but "closest color" turns out to be largely useless. I think that code should still be in the history somewhere, even if not used in recent versions.

[Ross Combs]

I'm aware of the X visual types. To me, TrueColor isn't about the number
of bits in the representation of the color. The meaning is that each
component of the color (RGB for color displays) is a separate part of the
representation, so the pixel value can be computed from them in a
predictable (and linear) manner. No need to consult a lookup table.

XTerm can run on displays which are DirectColor, TrueColor, PseudoColor,
and all of the grayscale equivalents. It has some internal color
management and tracking, but it basically boils down to code asking for a
color by RGB and color system finding a close match from existing colors,
or allocating a new color if possible.

But the Sixel and ReGIS code also have another layer of color management
because they are simulating the indexed color (PseudoColor in X11
nomenclature) implementation on the DEC terminals. It should be possible
to add some kind of direct mapping support, which is basically equivalent
to saying there's a fixed color-cube in the colormap.

The problem with this is twofold: one, the sixel format kind of assumes
indexed colors. So we can say there are a huge number of indices, but not
actually use them as such internally. I'm guessing this is what the other
terminal emulators are doing.

But the actual implementation of colors in XTerm's ReGIS and Sixel code
assume there are less than 32k color indices, so that would mean only 32
colors in each dimension: a cube with 2^5 red, 2^5 green, and 2^5 blue for
a total of 2^15 colors. On a TrueColor display these could be very close
matches, and on PseudoColor displays they would be dynamically allocated
out of the available colors and unallocated colors. 32x32x32 isn't enough
to avoid banding, but will look better than 256 color images in most cases.

The other problem is how to know if a sixel should be interpreted this way,
or the original way.

Apologies for the lengthy response, but it is definitely interesting to
figure out how to support this use case in XTerm and I don't see another
place to discuss it.

-Ross

[Ethan Merritt]

It's been several years since I looked at this. I will have to refresh my memory. Why don't you start by reading through the discussion that led to the sixelgd code we have now:
https://sourceforge.net/p/gnuplot/patches/742/

[Ross Combs]

I just tried gnuplot 5.4.0 with the sixelgd driver with xterm 331 and it seems to work for me with both "test" and "plot sin(x)". The output seems to initialize each color before using it, so I'm not sure how this is different than normal sixel output.

$ xterm -ti vt340 -xrm 'XTerm*numColorRegisters: 256'

Output attached below.

On the other hand, the other sixel driver (sixeltek) seems to miss setting the foreground color in some cases.

[MBaz]

Thanks for your help (I'm the OP). For some reason, I thought that xterm had the ability to map 24-bit color to 256 colors internally. Please, close this ticket.

[Ethan Merritt]

Both xterm and gnuplot itself make some attempt to accomodate RGB colors by reserving some of the 256-color space for whatever RGB values are requested by the user. So the first few requests are satisfied exactly, but as index slots are used up any new color requests are satisfied only by approximation to one of the colors already occupying a slot.