Performance optimizations + abstraction

[lntricate1]

Hopefully this is not too much stuff.

Changes

• Separated the logic of draw_direct into 4 functions: kitty_encode, kitty_encode_chunked, kitty_encode_compressed, and kitty_encode_chunked_compressed. Now it's possible to choose whether to use compression and chunking. All of these take an IO to write the image data to. draw_direct now calls kitty_encode_chunked with stdout.
• Added support for both RGB and RGBA formats, and other color spaces get converted to RGB or RGBA depending on whether they have an alpha channel.
• Wrote specific methods for base 64 encoding certain types of image data. Especially RGB can be encoded very efficiently because each pixel contains a multiple of 6 bits, and RGBA can be chunked efficiently because 768 pixels evenly fill 4096 base64 characters.

Benchmarks

On my machine using the mandril from TestImages (not counting the time to load the test image)

Original code draw_direct: 0.194233 seconds (8.37 k allocations: 8.906 MiB, 2.58% gc time)

RGB

• kitty_encode: 0.020691 seconds (37 allocations: 779.992 KiB)
• chunked: 0.022022 seconds (823 allocations: 816.617 KiB)
• compressed: 0.080171 seconds (75 allocations: 1.063 MiB)
• chunked_compressed: 0.075660 seconds (1.28 k allocations: 3.546 MiB)

RGBA

• kitty_encode: 0.033826 seconds (77 allocations: 1.047 MiB)
• chunked: 0.049188 seconds (1.48 k allocations: 1.108 MiB)
• compressed: 0.104464 seconds (78 allocations: 1.316 MiB)
• chunked_compressed: 0.132745 seconds (1.28 k allocations: 3.796 MiB)

I realized that if we make an interface similar to the one in Sixel.jl, it'll be possible to integrate this with ImageInTerminal.jl pretty easily. Maybe in the future things can be organized such that ImageInTerminal only handles the displaying logic and each image format package only handles reading and writing for their own format. Having a package that works for every terminal image format would be cool.

[simonschoelly]

Thanks for this. Unfortunately I have to deal with a broken laptop at the moment so it will take a few days until I get to review it.

[lntricate1]

No worries. While working on this I realized that Base64 itself has not been updated in 5 years and I've been working on a PR for that. Hopefully when that's done, the changes I made here can be simplified and made more readable without losing performance.