Add support in Windows Terminal for Kitty&#39;s Graphics Protocol #11561

@WSLUser commented on GitHub (Nov 24, 2020):

Could it be a possible extension idea then? Though based on what I saw from the extension PR, not sure if this is something that could be extended under current spec.

@WSLUser commented on GitHub (Nov 24, 2020): Could it be a possible extension idea then? Though based on what I saw from the extension PR, not sure if this is something that could be extended under current spec.

claunia commented

@WSLUser commented on GitHub (Jul 9, 2021):

@j4james Since Sixel is looking like it's not currently feasible, would Kitty's protocol be more easily adopted/implemented?

@WSLUser commented on GitHub (Jul 9, 2021): @j4james Since Sixel is looking like it's not currently feasible, would Kitty's protocol be more easily adopted/implemented?

claunia commented

@zadjii-msft commented on GitHub (Jul 9, 2021):

@WSLUser What makes you believe that sixel isn't feasible?

@zadjii-msft commented on GitHub (Jul 9, 2021): @WSLUser What makes you believe that sixel isn't feasible?

claunia commented

@WSLUser commented on GitHub (Jul 9, 2021):

https://github.com/microsoft/terminal/issues/448#issuecomment-853424240 and also seems to be more to it here: https://github.com/hackerb9/lsix/issues/41

@WSLUser commented on GitHub (Jul 9, 2021): https://github.com/microsoft/terminal/issues/448#issuecomment-853424240 and also seems to be more to it here: https://github.com/hackerb9/lsix/issues/41

claunia commented

@zadjii-msft commented on GitHub (Jul 9, 2021):

That doesn't sound like "not feasible" to me. That sounds like "more complicated to be fully compatible than you might think". I'm pretty sure the entire saga of PRs (e.g. #10011) that @j4james has been working on has been a long steady march towards sixel support (he can correct me if I'm wrong).

@zadjii-msft commented on GitHub (Jul 9, 2021): That doesn't sound like "not feasible" to me. That sounds like "more complicated to be fully compatible than you might think". I'm pretty sure the entire saga of PRs (e.g. #10011) that @j4james has been working on has been a long steady march towards sixel support (he can correct me if I'm wrong).

claunia commented

2026-01-31 02:51:13 +00:00

@WSLUser commented on GitHub (Jul 9, 2021):

Yeah I said currently. I'm hoping for us to have at least something to use and seems like getting Sixel support will be a long way aways as we're waiting for these bugs in other terminals and Sixel applications to be resolved. Since he made it clear he's not really interested in trying to support it further at this time, I thought/hoping he may be interested in trying to support this other protocol instead, which technically is superior to Sixel anyways.

@WSLUser commented on GitHub (Jul 9, 2021): Yeah I said currently. I'm hoping for us to have at least something to use and seems like getting Sixel support will be a long way aways as we're waiting for these bugs in other terminals and Sixel applications to be resolved. Since he made it clear he's not really interested in trying to support it further at this time, I thought/hoping he may be interested in trying to support this other protocol instead, which technically is superior to Sixel anyways.

claunia commented

@j4james commented on GitHub (Jul 10, 2021):

There are two issues involved here:

Propagating images over conpty. The conclusion I reached was that the most practical long-term solution would be a pure pass-through implementation of conpty. And this would likely be necessary for any image protocol. I'm not saying it's impossible to achieve with the current conpty implementation, but that would require buffering the images on the conhost side, and then regenerating partial image slices on the fly as the screen was updated. It's complicated, inefficient, and would probably depend on proprietary VT extensions.

Another approach would be to pass just the image protocol through directly, and hope it doesn't get erased by a subsequent refresh of the text buffer. This might work some of the time, e.g. if you're just outputting an image from the command line, but any reasonably complex application involving a mix of text and images is almost certain to break at some point.
The sixel image protocol itself. Personally I would like our sixel implementation to be a true emulation of the original hardware terminals, just with simple backward-compatible extensions (like support for a larger palette size, and optional per-image palettes). Most open source terminals, however, implement a format that (as Douglas Adams would describe it) is almost, but not quite, entirely unlike sixel. And the problem is that at least some modern sixel applications rely on the behaviour of these pseudo-sixel terminals.

I was hoping there might be a way we could implement the protocol that was both compatible with the original hardware, and also capable of supporting modern sixel applications, but that's not looking promising at the moment. And while I'd personally be quite happy with just a standard version of sixel, I don't think the rest of the WT userbase would necessarily agree, and our users tend to be abusive when they don't get what they want, so I'd rather avoid that fight.

So right now I'm working on point 1, since that I think is a necessity for any image protocol. On point 2, I've put the coding side of things on hold for now, but I'm still working in the background to try and nudge other terminals an apps in the right direction. And even if I don't get my way, there's no reason someone else with different priorities couldn't put together a sixel implementation that is good enough for modern usage.

As for the Kitty Graphics Protocol, I have zero interest in implementing that myself, but if someone did want to take that on, we still need to resolve point 1 first, so it's in no way a quick fix.

@j4james commented on GitHub (Jul 10, 2021): There are two issues involved here: 1. **Propagating images over conpty.** The conclusion I reached was that the most practical long-term solution would be a pure pass-through implementation of conpty. And this would likely be necessary for any image protocol. I'm not saying it's impossible to achieve with the current conpty implementation, but that would require buffering the images on the conhost side, and then regenerating partial image slices on the fly as the screen was updated. It's complicated, inefficient, and would probably depend on proprietary VT extensions. Another approach would be to pass just the image protocol through directly, and hope it doesn't get erased by a subsequent refresh of the text buffer. This might work some of the time, e.g. if you're just outputting an image from the command line, but any reasonably complex application involving a mix of text and images is almost certain to break at some point. 2. **The sixel image protocol itself.** Personally I would like our sixel implementation to be a true emulation of the original hardware terminals, just with simple backward-compatible extensions (like support for a larger palette size, and optional per-image palettes). Most open source terminals, however, implement a format that (as Douglas Adams would describe it) is almost, but not quite, entirely unlike sixel. And the problem is that at least some modern sixel applications rely on the behaviour of these pseudo-sixel terminals. I was hoping there might be a way we could implement the protocol that was both compatible with the original hardware, and also capable of supporting modern sixel applications, but that's not looking promising at the moment. And while I'd personally be quite happy with just a standard version of sixel, I don't think the rest of the WT userbase would necessarily agree, and our users tend to be abusive when they don't get what they want, so I'd rather avoid that fight. So right now I'm working on point 1, since that I think is a necessity for any image protocol. On point 2, I've put the coding side of things on hold for now, but I'm still working in the background to try and nudge other terminals an apps in the right direction. And even if I don't get my way, there's no reason someone else with different priorities couldn't put together a sixel implementation that is good enough for modern usage. As for the Kitty Graphics Protocol, I have zero interest in implementing that myself, but if someone did want to take that on, we still need to resolve point 1 first, so it's in no way a quick fix.

claunia commented

2026-01-31 02:51:13 +00:00

@smprather commented on GitHub (Dec 22, 2024):

FWIW, gnuplot 6.x supports KGP.

New terminals kittygd and kittycairo provide in-window graphics for terminal emulators that support the kitty protocol.

@smprather commented on GitHub (Dec 22, 2024): FWIW, gnuplot 6.x supports KGP. [New terminals kittygd and kittycairo provide in-window graphics for terminal emulators that support the kitty protocol.](http://www.gnuplot.info/ReleaseNotes_6_0_1.html)

claunia commented

2026-01-31 02:51:13 +00:00

@j4james commented on GitHub (Dec 22, 2024):

@smprather FYI, gnuplot also supports Sixel, so you can already use it with the preview version of Windows Terminal.

@j4james commented on GitHub (Dec 22, 2024): @smprather FYI, gnuplot also supports Sixel, so you can already use it with the preview version of Windows Terminal.

claunia commented

@LemonBreezes commented on GitHub (Jan 26, 2025):

I would love to see the Kitty protocol on the Windows Terminal.

@LemonBreezes commented on GitHub (Jan 26, 2025): I would love to see the Kitty protocol on the Windows Terminal.

claunia commented

@smprather commented on GitHub (Jan 29, 2025):

I know Kovid can be a bit... much? (ask the tmux team; or ask me). But I gotta hand it to the guy. He's moving the ball downfield.

@smprather commented on GitHub (Jan 29, 2025): I know Kovid can be a bit... much? (ask the tmux team; or ask me). But I gotta hand it to the guy. He's moving the ball downfield.

claunia commented

@jessey-git commented on GitHub (Feb 6, 2025):

Now that sixel is out of preview, been wondering about kitty graphics myself as I'd like to use vv, a full-resolution, HDR capable, image viewer.

Would support be easier to implement now that the graphics pipeline seems mature?

@jessey-git commented on GitHub (Feb 6, 2025): Now that sixel is out of preview, been wondering about kitty graphics myself as I'd like to use [vv](https://github.com/wolfpld/vv), a full-resolution, HDR capable, image viewer. Would support be easier to implement now that the graphics pipeline seems mature?

claunia commented

@j4james commented on GitHub (Feb 6, 2025):

Would support be easier to implement now that the graphics pipeline seems mature?

I'm afraid not. I did briefly look at it, but the kitty graphics protocol doesn't work anything like the standard DEC image protocols, most obviously in the way it interacts with text. The Sixel code would probably be a good starting point for implementing other DEC image protocols (e.g. ReGIS), but with kitty we'd essentially be starting from scratch - I don't think there's any overlap.

@j4james commented on GitHub (Feb 6, 2025): > Would support be easier to implement now that the graphics pipeline seems mature? I'm afraid not. I did briefly look at it, but the kitty graphics protocol doesn't work anything like the standard DEC image protocols, most obviously in the way it interacts with text. The Sixel code would probably be a good starting point for implementing other DEC image protocols (e.g. ReGIS), but with kitty we'd essentially be starting from scratch - I don't think there's any overlap.

claunia commented

@j4james commented on GitHub (Feb 9, 2025):

@jessey-git FYI, if you build vv yourself from the latest commit, it should now work in Windows Terminal using Sixel, at least good enough for previewing images, even if it's not pixel-perfect HDR.

@j4james commented on GitHub (Feb 9, 2025): @jessey-git FYI, if you build `vv` yourself from the latest commit, it should now work in Windows Terminal using Sixel, at least good enough for previewing images, even if it's not pixel-perfect HDR.

claunia commented

@jessey-git commented on GitHub (Feb 9, 2025):

Ah indeed! A tremendous thank you! I take it you may have had a hand in poking that project there. This is probably decent enough for now I suppose. At least I can view the types of files I need in an ok capacity (OpenEXR, tiff, raw).

For folks stumbling here, the vv project requires linux to build but is easy to run from the windows side of things using wsl:
wsl --exec <path to the built vv binary> <an appropriate linux path to the image file>

@jessey-git commented on GitHub (Feb 9, 2025): Ah indeed! A tremendous thank you! I take it you may have had a hand in poking that project there. This is probably decent enough for now I suppose. At least I can view the types of files I need in an ok capacity (OpenEXR, tiff, raw). For folks stumbling here, the `vv` project requires linux to build but is easy to run from the windows side of things using wsl: `wsl --exec <path to the built vv binary> <an appropriate linux path to the image file>`

claunia commented

@ymich9963 commented on GitHub (Nov 11, 2025):

Any chance this would get implemented at some point or will Windows Terminal fall behind?

@ymich9963 commented on GitHub (Nov 11, 2025): Any chance this would get implemented at some point or will Windows Terminal fall behind?

claunia commented