RELEASE Version 1.1.0: Raw colors

[GuardKenzie]

Summary

Added support for raw color values in the canvas and improved detection for Sixels capable terminals.

New stuff

• 📟 Added a function chafa.get_device_attributes that returns a list of the device attributes returned by the control sequence \e[c on xterm.
• 🖨️ The TerminalCapabilities class now has a printable representation and can be compared using == with two TerminalCapabilites being equal if both their canvas_mode and pixel_mode attributes match
• 🎨 Added raw_bg_color and raw_fg_color properties to CanvasInspector. These allow users to specify raw color values, (0xRRGGBB in truecolor mode or e.g. integer from [0-255] in INDEXED_256 mode)
• 🔨 Building from source is now available again. You just have to make sure glib-2.0 and libchafa are on your path.

Bugs squashed

• 🐛 The TermInfo.detect_capabilities() funciton now more accurately detects Sixels capable terminals. (specifically it detects those that have a 4 in their device attributes emitted by \e[c)
• 🐛 The TermSeq, ColorSpace and ColorExtractor enumerators can now be imported properly.
• 🐛 Indexing the Canvas with negative x or y values is no longer broken.

Full Changelog: v1.0.2...v1.1.0

If you are having trouble, head over to the discussions and if you find a bug, please open an issue.

Have fun
❤️

---

This discussion was created from the release Version 1.1.0.

[clort81]

I thought sixel was always max 256-color...

[jerch]

It's a bit surprising, since re-paletting won't work with hardware palettes, which limits it to modern TEs.

It also does not work with xterm -ti 340, as it emulates the terminal-wide shared palette with late indexed coloring during screen output as a vt340 would do (but xterm increased max colors at some point, I think 1024 is the upper bound).
While all other terminals I have tested do immediate coloring, so later palette changes do not affect already colored pixels anymore (this is more printer-like behavior). The immediate mode also renders palette animation useless (was told they were pretty famous in the old vt340 days).

When I discovered the hicolor setting of libsixel, it felt more like a hack misusing an implementation detail (of whatever TE they tested it on, certainly not xterm). The sixel spec as of DEC STD 070 does not mentioned anything like immediate vs. late coloring. But since most newer TEs implement it likewise, its prolly for the better outcome.

[hpjansson]

Yes, I'm pretty sure they neglected to clarify it in 1991 because that's how everyone implicitly agreed palettes worked back then. "What do you mean someone could get more colors by just issuing an arbitrary number of palettes? That's impossible, the display beam only does a single pass per frame."

Some systems did have display-synchronized coprocessors (the Amiga's Copper is a famous example) that would let you change palette colors not just during vertical blank, but on horizontal blank too. You did as many colors as you had time for (a lot fewer than 256) in the break as the beam was being aligned for the next row of pixels. Of course, those hacks would turn out to be less than portable, but the competitive advantage they offered could be decisive :-)

The situation today is the inverse. Retroactive palette changes create more work, not less, and there's obviously no advantage to be had by it anymore, so terminals simply omit it. And that creates an opening for a new kind of hack, namely libsixel's.

[jerch]

Yes, I'm pretty sure they neglected to clarify it in 1991 because that's how everyone implicitly agreed palettes worked back then.

Yeah good point, I think higher color resolutions were not a widespread thing until XGA/SVGA (beside special solution like on SGI boxes, and prolly amiga). Even VGA was still bound to an 8bit palette at a time.

Interesting that you mention amiga's line update behavior here. I have not tested, if libsixel would also spit out new colors within a sixel-row, or stays strictly between rows. Well the latter would be seriously flawed, as its perfectly possible to put more than 256 colors into a 6-pixel height row of a certain width. (Tbh I have not much trust in libsixel's code, there are way to many CVEs listed...)

[hpjansson]

It's a little hard to follow, but it seems to re-palette between vertical strips.

Regarding CVEs, I'm not so sure the count matters (openssh has 138 including a serious one just last month). The count is influenced by the project's age and how much (public!) scrutiny it gets. CLI tools and image libraries get more scrutiny as they're easy to set up fuzzing for.

I think what matters more is how security issues are handled: a project should have a security policy and respond quickly to new issues. Unfortunately, libsixel fails in that regard; it's not actively maintained since January 2020. It's a shame, since the maintainer made significant contributions to other projects as well. @saitoha, you are missed.

[jerch]

It's a little hard to follow, but it seems to re-palette between vertical strips.

Now I wonder what happens, if one puts more distinct colors in one stripe 🙈

Regarding CVEs, I'm not so sure the count matters (openssh has 138 including a serious one just last month).

Yes and no. A high CVE count per se says not much true, as it can rise by outside factors like software popularity or easy testing surface. It still reflects though, how good or bad devs have their code under control, if you start looking into the CVEs. Well we are all humans doing errors, so thats not what I am nagging about. The fact they are open for so long while libsixel gets delivered in almost all distros is what makes me shudder.

libsixel fails in that regard; it's not actively maintained since January 2020

Imho several peeps have tried to take over maintenance in https://github.com/libsixel/libsixel, no clue whats the state of that. (From the issue tracker it seems they struggle with several conceptual aspects of the lib.)

@GuardKenzie Sorry for highjacking the discussion.