3rd
Forcing image aspect ratio to align with terminal grid
Continuing conversation from #20.
To recap, the current implementation forces images to alight with the grid. So let's say you have a grid size of 5px wide by 10px tall. and an image that is 5px by 14px, the image would be displayed as a 5px by 10px image, as it's forced to align with the cell. This effect becomes less and less noticeable as images get larger, but it's still been very noticeable for me in regular use.
It would be great if we could just not force the image into the terminal grid. So if an image was (like in the example from above) 4px taller than a cell, it would take up an extra vertical cell, but only use 4 pixels of it.
I'm not too familiar with image protocols, but I'd imagine they're able to do this by just padding the edge of an image with transparent pixels.
Yep, we'd need to patch them with a transparent padding (https://sw.kovidgoyal.net/kitty/graphics-protocol/#controlling-displayed-image-layout), but the magick rock doesn't seem to support that, or at least I couldn't find a way to make it work :|
It's also pretty darn slow at everything, thinking of shipping an alternate CLI tool. We only just convert from a format to another, scale and crop the images. Such a tool could also add the padding, but it's gonna take some time, and I'm not sure if people will be willing to install it.
I don't see anything on that page that suggests the image must conform to the terminal grid.
You can also specify extra X=3 and Y=4 pixel offsets to display from a different origin within the cell.
This actually seems to indicate that they don't have to be.
Currently we're cropping the image manually to exactly line up with the grid. I wonder what happens if we just don't do that, although you might have already tried that and it might break horribly.
Also not sure how Uberzug would handle this
Hello, given https://github.com/kovidgoyal/kitty/issues/7380 is closed, I think we don't need to rescale the image for now as kitty natively support it? I haven't test it though.
If that's possible we may also drop magick support in favor of simpler libraries?
I think we still need it, we need to convert from other image formats to PNG and also support ueberzug. In the rewrite I'm adding a magick cli-only mode to work around the rock being not good. Personally I don't like having to use imagemagick at all and I'd like to have a separate utility that does all image processing in rust/go, but opinions vary https://github.com/3rd/image.nvim/issues/124
You don't actually need to do the conversion. Kitty's image protocol accepts matricies of pixels.
We'd have to read the pixels for all the supported image formats in Lua, which wouldn't be feasible, but even if we did have a way to do it, it would probably be slower than asking Kitty to read the png file directly. And we need to support ueberzug as well.