Transparent Sixel support is broken

[NSPC911]

2026-04-10.17-34-19.mp4

Image used (save as gracehopper.png)

Diff used:

diff --git a/textual_image/demo/renderable.py b/textual_image/demo/renderable.py
index 19937dc..c649878 100755
--- a/textual_image/demo/renderable.py
+++ b/textual_image/demo/renderable.py
@@ -25,7 +25,7 @@ from textual_image.renderable import (
     UnicodeImage as UnicodeRenderable,
 )
 
-TEST_IMAGE = Path(__file__).parent / ".." / "gracehopper.jpg"
+TEST_IMAGE = Path(__file__).parent / ".." / "gracehopper.png"
 
 RENDERING_METHODS = {
     "auto": AutoRenderable,
diff --git a/textual_image/demo/widget.py b/textual_image/demo/widget.py
index c9499d8..1f3c06a 100755
--- a/textual_image/demo/widget.py
+++ b/textual_image/demo/widget.py
@@ -18,7 +18,7 @@ from textual.widgets.option_list import Option
 from textual_image.widget import HalfcellImage, SixelImage, TGPImage, UnicodeImage
 from textual_image.widget import Image as AutoImage
 
-TEST_IMAGE = Path(__file__).parent / ".." / "gracehopper.jpg"
+TEST_IMAGE = Path(__file__).parent / ".." / "gracehopper.png"
 
 
 RENDERING_METHODS = {
@@ -330,7 +330,7 @@ class DemoApp(App[None]):
 
 def run(rendering_method: str = "auto") -> None:
     """Showcase textual-image's Rich renderables."""
-    app = DemoApp()
+    app = DemoApp(ansi_color=True)
     app.image_type = rendering_method
     app.run()

[lnqs]

Do you have an idea what the respon could be, @uriyyo ?

[uriyyo]

@lnqs Ahhh, I know where the issue is. I will open a PR with a fix.

[uriyyo]

@lnqs Opened PR with fix #98

[NSPC911]

There also seems to be an issue when running with textual-image>=0.10.0; there's just this green thing at the top, and i'm not sure why.

textual-image==0.9.0

textual-image==0.10.0

using pr #98

(it's transparent btw)

the image in question: https://raw.githubusercontent.com/NSPC911/rovr/refs/heads/master/docs/src/assets/houston.webp

[uriyyo]

Thanks for reporting, I will take a look

[uriyyo]

@NSPC911 What terminal are you using? I tried to test on my terminal (Windows Terminal via WSL), here is the result:

[uriyyo]

@NSPC911 I pushed a small fix, could you please check on your side 🙏

[NSPC911]

I'm currently using wezterm (wezterm 20260117-154428-05343b38), the issue still persists after applying your fix.

No issues on windows terminal though, very weird

[NSPC911]

I find it quite weird that other apps (like yazi and superfile) use kitty image protocol, but textual-image's kitty unicode placeholder doesn't work on wezterm.

[j4james]

@NSPC911 Unicode placeholders were not included in the original kitty graphics protocol, so a lot of the early adopters (like WezTerm) don't have that functionality. The last time I tested, Ghostty was the only terminal I could find (other than kitty) that supported them. I think they might also be supported by iTerm2, but I don't have a mac to test that.

[j4james]

As for the bright green at the start of those images, there's a bug in WezTerm's implementation of the color command that is likely to blame for that.

When you execute a color definition, like #1;2;255;0;0 that should define #1 as red, but also select #1 as the active color. However, WezTerm does not perform the second step, so unless you explicitly follow that up with another #1, you'll be left with the default color, which in WezTerm is bright green.

As a simple test case, this should produce a red line, but in WezTerm it'll be green:

echo -e '\eP9;1q#1;2;255;0;0!100~\e\\'

But this example should work in WezTerm, because the #1 is selected explicitly:

echo -e '\eP9;1q#1;2;255;0;0#1!100~\e\\'

[NSPC911]

That is very very weird, what if this explicit fix is set as default?

[uriyyo]

As for the bright green at the start of those images, there's a bug in WezTerm's implementation of the color command that is likely to blame for that.

Yup, I believe this is exact issue that we see and it's related to changes that I made when was trying to optimize sixel encoding.

One of optimizations was to lazily emit color palette when color was used first time rather than define whole pallet on the beginning of sixel payload. It allowed to save some bytes by using fact that color should be actived after it was defined, but looks like in case of wezterm it's not expected behavior.

I guess fix can be to add new option to SixelOptions to explicitly chose color after it was defined.

[uriyyo]

@NSPC911 I pushed fix, could you please validate on your side that it's working when you use SixelOptions(explicit_color_select=True)?