FFmpeg-SIXEL VS melatonin_audio_sparklines

Also:

https://github.com/saitoha/libsixel

contains img2sixel, which lets you dump images to the terminal. It can also do animated GIFs.

Video:

https://github.com/saitoha/FFmpeg-SIXEL

GUI apps:

https://github.com/saitoha/SDL1.2-SIXEL

and more, linked from the libsixel repository.

> I don’t see why sixels couldn’t work.

Sixels will work: they are fast enough to allow youtube video playback !!!

https://github.com/saitoha/FFmpeg-SIXEL/blob/sixel/README.md

But the problem is NOT THE FORMAT, the problem is the lack of tooling. links and w3m are among the rare text browsers that can display images in the console.

It's just a matter of the browser sending the image to something in some format, but if that hasn't be thought about as a possibility (say, for text reflow issues) it's going to be far more complicated than just adding a new format, as you will have to work both on say the text reflow issues (ex: how do you select the size of the placeholder, when expressed in characters?), and the picture display.

Personally, I do not care much about sixels, kitty or iterm format - all I want is to see some kind of support.

Yes, it would be better if that support was for the option that has the greatest chance of succeeding, but even that is a second concern: in the worst case, we can write transcoders to whatever format people prefer!

But when there is no "input" to transcode, you have a much bigger problem!

> an off the shelf ASCII plotting library probably involves less custom tooling

With a terminal like msys2 or xterm, no custom tooling is required: just use the regular gnuplot after doing the export for the desired resolution, font, and font size.

gnuplot is far more standard than plotting library that often require special Unicode fonts on top of requiring you to use their specific format.

As a fan of Sparklines (and Tufte in general), I have to shout out to one of my favourite places that sparklines have been used - in sudara's Audio Sparkline library for the popular JUCE Audio processing framework:

https://github.com/sudara/melatonin_audio_sparklines

The reason this is such a nerd tickle, is that sudara even went as far as to teach lldb how to render arrays' using sparklines, meaning one can get a pretty useful clue about the contents of an audio buffer within the debugger:

https://forum.juce.com/t/new-audio-sparklines-module/46606

This, to me, aligns very much with the "Tao" of sparklines - although of course I've modified my local copy to use unicode fonts, which is either heinous or fabulous, depending on how much coffee I've had before I have to hit up lldb for details about why my day is going to be good/bad... ;)

You found the Achilles' heel of my project! I don't mind the fonts being different sizes or not monospaced, but the fact that there's a difference in height in the font rendering between ⎺ and ‾ on different platforms is a bummer. I have a flag in the C++ implementation so they can still be rendered "correctly" in IDEs like Xcode [1].

I felt doomed to Unicode in this case because of the number of places I wanted them to show up (CLion lldb integration, GitHub actions output, terminal). I would have loved to actually render graphics! I actually never thought about how they would render on a blog article, I wouldn't generally wouldn't use them for blogging...

1. https://github.com/sudara/melatonin_audio_sparklines/blob/ma...

Nice! I became obsessed with rendering sparkline representations of chunks of audio for the same reason: to inspect failures when writing tests / refactoring. https://github.com/sudara/melatonin_audio_sparklines