Libsixel forked

[dnkl]

This is just an FYI: Arch's libsixel AUR package just switched to a libsixel fork. Mentioning this since I know you've opened issues in the original libsixel project.

More info: saitoha/libsixel#154

[dnkl]

... and just saw you're co-maintining it :)

[dankamongmen]

yep =] i'm also packaging it for Fedora, or at least am halfway through doing so. i aborted the effort when i decided not to use it, but will likely pick it back up now. just made a bug on this: libsixel/libsixel#11

i'd like to use it, for general code-reuse and capability-pooling reasons.

related bugs: #639, #641, and #1391

as i recall, libsixel primarily wants to work by you pumping in pixels, and it giving you back a sixel-encoded string. that's kinda suboptimal for us; i'd have to write a sixel decoder. not a difficult thing by any means, but that functionality probably belongs in libsixel. what i'd ideally get back (in addition to the string) is a matrix of palette indices (size defined by number of color registers, or some max size) and a matrix of equal dimensions (single bit values) for transparency. obviously this is trivially built if one decodes the generates sixel string, but it's probably faster (at least for large images) to generate it while generating said string, due to better cache behavior in a single-pass approach.

tagging @ctrlcctrlv so he has visibility.

[dankamongmen]

i'd also, of course, need it to be on all our supported platforms.