Kitty Image Protocol: Nearest Neighbor Scaling

[bbb651]

Is your feature request related to a problem? Please describe. I want to be able to specify that scaling should be done in Nearest Neighbor when using r or/and c when displaying an image. This is how a scaled 7x7 sprite currently looks:

This is how I would like it to look (16x scaled):

Describe the solution you'd like A flag to control the type of scaling used. Maybe F for filtering or M for mode, something like: 0 - linear (default) 1 - nearest neighbor to preserve backwards compatibility with the current scaling and leave room for additional modes in the future

Describe alternatives you've considered Scaling the image myself in the application. This have several downsides:

• Makes the data transferred unnecessarily large
• Prevents possible reuse of the same at different scales
• Adds complexity for the application, it might not necessary know how to handle image scaling especially in the f=100 mode. It seems like a pretty minor change on the terminal emulator side

Additional context Environment: Gnome 46 (Wayland, proprietary nvidia driver) Kitty version: 0.33.1-3

Also for screenshots look slightly different from how they actually look in kitty, I'm not sure why but it shouldn't really matter

Side note: The protocol specification says:

If only one of either r or c is specified, the other one is computed based on the source image aspect ratio, so that the image is displayed without distortion.

I noticed it isn't the case, and it also breaks something with the positioning (all of these should be non intersecting, I'm passing a=T,f=24,s=7,v=7 and different r and c values), maybe it's a bug only affecting really small image sizes? This needs further investigation.

[kovidgoyal]

I'm not a fan of exposing this kind of implementation detail in the protocol. See #7070 for some discussion and when the default was changed from NN to linear. The default might change again in the future. If an application wants a particular resizing algorithm/quality it should resize itself. I cant think of that many use cases that the added complexity is worth it. Its not just adidng a flag, applications cant rely on that flag and there is no way to test for support for it and so on.

For the rest of the issues either open a new issue or continue to discuss here.