Menu
▾
▴
#1556 line colors with pbm and sixel drivers
The pbm and sixel terminal drivers have color options. Previously (with 4.7 development versions) with the "test" command, lines automatically got different colors with these drivers. But with Gnuplot 5.0.0, these colors are all the same. Perhaps their "set_color" functions need to be adapted to new functionality, or should the new functionality be slightly differently implemented?
I'll look into it.
Meanwhile, this sequence of commands should get you back to the original colors for pbm.
unset for [i=1:10] linetype i
set for [i=1:10] linetype i linecolor i
Fixed in CVS for 5.0 and 5.1
Thank you for the fix! It works for the pbm driver, but not for the sixel driver. The reason is that the latter has a set_color function - while not extremely useful, it does allow for rgb specifications. Interestingly, the above workaround works also for the sixel driver. The question now is if the current fix can be extended, or should the set_color function be given up?
Huh. If the sixel driver responds correctly to RGB color request, why is there a problem in the first place? Are you sure the fault lies in the driver rather than in the sixel display emulator?
Is there a sixel terminal emulator somewhere that I can test with? The only sixel device I have (assuming I can even find it in the storage closet) is a pin-printer that ignores color commands. I have seen several claims that xterm will emulate a vt340 with color sixel graphics, but this turns out not to be the case for any xterm source I could find.
The Sixel driver uses the linetype as an index for its device palette, but with gnuplot 5 the use of linetype has changed a lot. However, the Sixel driver works with the above workaround, including rgb specifications.
The driver also supported different line colors with different types of dashed lines using the linetype, but that was perhaps non-standard.
The XTerm source includes support for Sixel graphics since patch 294 of 2013/07/05, but it was not compiled in by default. For various possibilities see section "Terminal requirements" at the libsixel page: https://github.com/saitoha/libsixel (showing awesome applications of Sixel graphics, including Gnuplot).
I have now looked at the routine SIXEL_set_color. It appears to implement something quite different from what the rest of the program is expecting. Rather than setting the current color, it redefines one of 16 linetype colors. This is mostly useless, as the core code makes a distinction between coloring by linetype and coloring by RGB or palette values.
The code is closer to being support for a 16-color palette (indeed the structure being manipulated is called SIXEL_palette), but if that is the intent then it needs to be implemented as a different terminal entry point, term->make_palette() rather than term->set_color(). I don't know if the sixel format itself supports 24-bit color, but even if it does I don't think you can get there using the current approach.
If you or any other volunteer is sufficiently interested to implement RGB + smooth palette coloring properly, it might be possible. Otherwise I think the best solution is to comment out the SIXEL_set_color routine.
Another possibility would be to repair the current index-based palette approach by expanding the palette size to a more useful 128 or 256 colors (16 is really too few) and writing a routine SIXEL_make_palette() to maintain it. The code in gd.trm might be useful as a model.
Thank you for the suggestion of a make_palette() function - I'll look into it.
It seems that when a driver has a make_palette function, it is not called with for example the
testcommand, so the colors of the lines at the right remain all the same. And when the set_color function is removed, the default colors are ok, but cannot be changed by specifications such as in for examplepl x lc rgb 'red'. Would you accept a patch to the set_color function so that this is again possible?I think you misunderstand what gnuplot's "palette" is used for. It is used to map a single-parameter gray scale onto a color representation. Typically it is used either to color 2D (x,y) data by a 3rd variable (z). Or to color a 3D surface (x,y,z) by a 4th variable. The 3D implementation is called "pm3d"; the 2D plot mode is often called "heat maps".
Aside from coloring 2D and 3D surfaces, the palette colors can be applied to individual objects (points, lines, circles, boxes, etc) using the color specification "palette z" or "palette frac".
See various demos like
http://gnuplot.sourceforge.net/demo_cvs/heatmaps.html
http://gnuplot.sourceforge.net/demo_cvs/complex_trig.html
As you note, palette coloring is not exercised by the "test" command. There is a separate command "test palette".
No, because that is not what the program uses the term->set_color entry point for. It is used to select an existing color, not to define a new one.
Note that the SIXEL_set_color() routine never did work correctly even in version 4.6, because each redefinition of a line color would negate all previous definitions. The bitmap terminal support works by storing an array of (OK, multiple bitplane arrays) of index values. Only at the end of the plot is the array read back and the index values converted to colors. So only the final mapping of index->color is relevant.
Example:
Think about what would happen if you say
set arrow from 0,0 to 1,1 lc "pink" front
plot x lt 1 lc "red", x**2 lt 1 lc "blue", x**3 lt 1 lc "green"
Three sets of pixels will be set to the value "1" (the linetype).
Mapping linetype 1 to red, then blue, then green is pointless because this mapping is not stored anywhere. The last thing drawn will be the pink arrow, and it will cause all the previous lines including the x, x2, and x3 curves to be rendered in pink.
According to the man page for xterm and ./configure --help it should be possible to build in support for a 256-color palette. However, I did not succeed in displaying more than 16 colors when I tried to build it with
Maybe I just don't understand how to access the full set of colors in sixel mode.
Last edit: Ethan Merritt 2015-02-27
A video terminal has for example (by a selection of the terminal type in XTerm) 16 color registers. These have default values, but may be changed via for example an RGB specification, and then the previous value is indeed lost. This was not too bad, because the image was written from top to bottom and in the meantime the colors could be redefined multiple times; however, indeed here the whole bitmap needs to be created first.
The aim is that a simple command such as
plot x,x*2results in two lines with different colors. Previously, this was possible because the linetypes were set to different values (unless overridden withlt), which could be used as an index to the color registers.With Gnuplot 5, the plot sends two different RGB values to the set_color function. These colors do not necessarily exist yet in any of the color registers, and if they would, the question is how to select the right registers. The patch that I have in mind keeps a mapping of the stored RGB values in color registers that have no previous redefinition (please see attachment; the majority of demos work, because 16 colors is enough for many types of plots). As an example, where the dashtype (dt) rather than linetype (lt) may be used for a dashed style:
The emulation of the historic Sixel devices can of course be extended to have much more color registers (and would allow for a palette); I'm not sure if this is implemented in XTerm.
There is now a related issue filed against the fig terminal (Bug #1579).
In looking at the fig terminal code it occurred to me that there is a relatively simple change that might work for both the fig and the sixel terminals.
I suggest that instead adding or modifying the term->set_color() routine, the current assignment of linetype colors should be implemented in term->init(). Thus whenever you say "set term sixel" or "set term fig", the current set of linetype definitions is used to redefine the terminals internal of linetype colors.
That has the benefit that you can set whatever colors you like during program initialization or manually, and they will be used by the terminal. It has the downside that any attempts to change the linetype colors after the terminal is already open won't work, or at least won't take affect until you reopen it.
Would that meet your needs?
Yes, that could be a reasonable compromise, and I would like to try and implement it. Then it would be helpful to know in which variables the line type definitions are stored for the init() routine to access?
OK, here's my quick stab at it. It combines the idea of loading the existing set of linetype colors into the palette with your previous approach of adding new colors so long as there is an empty slot in the palette.
Very light testing shows it basically it seems to work, but there are some glitches. Points don't get a color for some reason. linetype 0 is dotted (correct) but also linetypes 8, 16, etc (not correct). The result of trying to use an unsupported coloring scheme like palette colors can be unexpected. I don't know what's going on there.
I'm handing it back to you for testing and polishing.
If this seems like a workable approach, I'll see if it can be applied to the fig terminal also.
Thank you for this! Here is a version with some glitches removed and make_palette() added. The number of color slots (and planes) could be increased (in XTerm one constant change would be required or for example mlterm may be used). The state field is now "undefined", "defined" or "used" which seems to give some flexibility. The monochrome option is now less useful, but the old behavior may be set with the "set" command.
Looks good. I've put this version in cvs for both 5.0 and 5.1
On Tue, Mar 24, 2015 at 2:21 PM, Erik Olofsen olofsen@users.sf.net wrote:
Related
Bugs:
#1556