Sixel Transparency

[AnonymouX47]

Hello!

I've had my eyes on this project for a while, being a developer of a similar project.

I recently started exploring various projects that have implemented their own sixel encoders hoping to find one I could use as a dependency instead of going straight ahead to write one from scratch. I only know of three such projects:

• libsixel
• chafa
• NotCurses

Of the three, this project is the only one still in active development/maintenance but there was on major setback I discovered, the lack of support for transparency. NotCurses is the only one with support for transparent sixels (tested it myself).

What's your take on the matter? Is there any chance of implementing this (at least, we know it's possible)?

@GuardKenzie, @danschwarz and I were discussing earlier (at ihabunek/toot#319) about the possibility of using chafa (via @GuardKenzie's chafa.py) as sort-of a render back-end (for more than just sixels though) and I'm willing to contribute in any way I can (I also program in C by the way).

Thank you 🙏🏾

EDIT: Jexer must've skipped my mind :(

[hpjansson]

Hey! Thanks for getting in touch. Sixel transparency should already be working -- I just tested it in mlterm to make sure, and it performed as expected. Maybe you're running into a bug or corner case, or we're talking about different things?

The way I've been testing it is by running chafa transparent.gif --bg red and observing that the background is white (mlterm's default). Then I add -t 1 to the command line to set the alpha threshold to max and turn the background opaque. It will then appear red. When you use text selection on the area, you will see the transparent background changes color, but the opaque one does not.

This may work differently in Kitty. I added a workaround there for #104.

The development pace varies according to the various demands on my time, but Chafa will be maintained and developed for the foreseeable future, so it should be safe to depend on. Having more eyes on the code is always good. I'm very interested in collaboration!

[AnonymouX47]

Oh, my bad! 🤦🏾‍♂️

I tested it on Konsole earlier. Seems Konsole is the one with an incomplete or buggy implementation of sixels. The same actually goes for all other graphics protocols "implemented" by Konsole, so I'm not surprised.

I just tested it on Xterm and Wezterm now and yes, transparency works just fine.

There was one slight issue on Xterm though. The transparent portions of a sixels don't overwrite existing sixels.

Actually, I would naturally expect this with transparency. So, I can't call it a bug, instead it's wezterm i would consider buggy. Anyways, I guess something ought to be done about this i.e within chafa to fix display of transparent GIFs.

Thanks for the clarification and sorry for the confusion/disturbance.

[hpjansson]

I think the semantics of sixel transparency aren't clear. It's a really underspecified format, so unfortunately different terminals do different things. E.g. mlterm clears the area before painting the picture over it.

The only safe solution from our perspective is probably to always paint opaque frames when it's an animation.

By the way you shouldn't worry, I don't mind answering questions at all. When in doubt, file an issue or discussion topic early. It's much better than the alternative.

[AnonymouX47]

It's a really underspecified format

That's true.

By the way you shouldn't worry, I don't mind answering questions at all. When in doubt, file an issue or discussion topic early. It's much better than the alternative.

Ok. Thanks.

[AnonymouX47]

This may work differently in Kitty. I added a workaround there for #104.

Yeah, I saw this issue earlier and I just might have something to contribute on that. Been quite busy.

The development pace varies according to the various demands on my time, but Chafa will be maintained and developed for the foreseeable future, so it should be safe to depend on. Having more eyes on the code is always good. I'm very interested in collaboration!

Great! 💪🏾

[hpjansson]

I think it might make sense to just do the same thing for every image protocol as we do for Kitty. I'd accept a PR to do that.

I'm working on code to detect the terminal's background color to make it blend in naturally. When that's done it'll look much nicer.

[AnonymouX47]

I'm working on code to detect the terminal's background color to make it blend in naturally.

Yeah, true. I think I also saw that earlier at #111.

I've actually implemented that but I don't use async I/O. From my experience, most terminal emulators (at least, anyone supporting a graphics protocol) actually responds in less that 0.05 seconds (on my humble laptop).

[hpjansson]

I want to have async support eventually, at least in the library backend. Terminals are often remote, and then latencies of over a second aren't too unusual (cf. connecting from South America to a European or Asian data center -- IP + TCP + SSL possibly with bloated buffers). It can't just fall apart randomly in those cases.

[AnonymouX47]

Hmm... True. The case of remote sessions almost always skips my mind.