diff options
author | bptato <nincsnevem662@gmail.com> | 2024-09-24 23:25:07 +0200 |
---|---|---|
committer | bptato <nincsnevem662@gmail.com> | 2024-09-24 23:55:43 +0200 |
commit | 1c9277343140effcc9eee8845757afd1eed4f4bd (patch) | |
tree | 7a902dc2aebce67ee5749442129176b0683cf60f /doc/image.md | |
parent | 0c738c94e14c213562f69ff6e376c19fb0487201 (diff) | |
download | chawan-1c9277343140effcc9eee8845757afd1eed4f4bd.tar.gz |
sixel: support transparency
Sixel can only represent transparency for fully transparent (alpha = 0) and fully opaque (alpha = 255) pixels, i.e. we would have to do blending ourselves to do this "properly". But what do you even blend? Background color? Images? Clearly you can't do text... So instead of going down the blending route, we now just approximate the 8-bit channel with Sixel's 1-bit channel and then patch it up with dither. It does look a bit weird, but it's not *that* bad, especially compared to the previous strategy of "blend with some color which hopefully happens to be the background color" (it rarely was). Note that this requires us to handle transparent images specially in term. That is, for opaque ones, we can leave out the "clear cells affected by image" part, but for transparent ones, we must clear the entire image every time.
Diffstat (limited to 'doc/image.md')
-rw-r--r-- | doc/image.md | 33 |
1 files changed, 17 insertions, 16 deletions
diff --git a/doc/image.md b/doc/image.md index e9232686..7a3455ee 100644 --- a/doc/image.md +++ b/doc/image.md @@ -47,22 +47,23 @@ to find a terminal that supports it. Known quirks and implementation details: -* XTerm needs extensive configuration for ideal sixel support. In particular, - you will want to set the "decTerminalID", "numColorRegisters", - and "maxGraphicSize" attributes. See `man xterm` for details. -* We assume private color registers are supported. On terminals where they - aren't (e.g. SyncTERM or hardware terminals), colors will get messed up with - multiple images on screen. -* We send XTSMGRAPHICS for retrieving the number of color registers; on failure, - we fall back to 256. You can override color register count using the - `display.sixel-colors` configuration value. -* For the most efficient sixel display, you will want a cell height that - is a multiple of 6. Otherwise, the images will have to be re-coded several - times on scroll. -* Normally, Sixel encoding runs in two passes. On slow computers, you can try - setting `display.sixel-colors = 2`, which will skip the first pass. -* Transparency is currently not supported; you will get strange results with - transparent images. +* XTerm needs extensive configuration for ideal sixel support. In + particular, you will want to set the decTerminalID, numColorRegisters, + and maxGraphicSize attributes. See `man xterm` for details. +* We assume private color registers are supported. On terminals where + they aren't (e.g. SyncTERM or hardware terminals), colors will get + messed up with multiple images on screen. +* We send XTSMGRAPHICS for retrieving the number of color registers; + on failure, we fall back to 256. You can override color register count + using the `display.sixel-colors` configuration value. +* For the most efficient sixel display, you will want a cell height + that is a multiple of 6. Otherwise, the images will have to be re-coded + several times on scroll. +* Normally, Sixel encoding runs in two passes. On slow computers, you + can try setting `display.sixel-colors = 2`, which will skip the first + pass (but will also display everything in monochrome). +* Transparency *is* supported, but looks weird because we approximate an + 8-bit alpha channel with Sixel's 1-bit alpha channel. ### Kitty |