Feature Request - Add support for sixel graphics protocol as an alternative to kitty image protocol

[VarLad]

Hello!
I was wondering if it would be possible to add support for sixel protocol, as thats supported by a much wider range of terminals compared to the kitty graphics protocol, to render images.

[JacobCrabill]

Thanks for your interest! I hadn't previously heard of this protocol; I think the iTerm protocol might be a more useful addition than this, but I'll take a look to see how difficult it would be to add as a fallback option.

[VarLad]

@JacobCrabill If you're not against an external C lib dependency, Chafa library would be a great option as well. It supports most protocols (ITerm2, Sixel *faster and higher quality implementation than libsixel or ImageMagick, Kitty, Octants <from Unicode 16.0 specification>)
It has a C API as well.

[JacobCrabill]

That does look interesting, but I tend to stay away from (L)GPL-licensed code if I can avoid it. Sixel also looks like a decent option, and I was able to hack together a build.zig pretty quickly, but it relies on a lot of auto-generated files from the autoconf system, which would make it really annoying to package up nicely. It also seems to rely on system libraries (although maybe those are optional?), which really goes against my software philosophy for projects like this.

I'd be happy to review any PR's you're willing to put together, but for right now, this just isn't a priority for me.

[VarLad]

It also seems to rely on system libraries (although maybe those are optional?), which really goes against my software philosophy for projects like this.

Thats understandable. Though its a C project so Zig can probably compile it if we include it as a dependency in build.zig.zon, but I'd prefer to keep chafa support fully optional and leave it up to packagers.
That being said can you share the build.zig that you created? :)

[VarLad]

Hey, by the way, for what its worth, ideally I'd also like support for Iterm2 image protocol and Octants as well. Chafa can provide support for all of these (including sixels and Kitty Graphics Protocol), so it could be nice to have one interface to all of these. :)

[JacobCrabill]

Yeah, it should be possible to create an interface for image rendering (like how the Allocator interface works) that can be swapped out via options passed into the renderer.

[JacobCrabill]

As for the libsixel build.zig:

const builtin = @import("builtin");
const std = @import("std");

const CFlags = &[_][]const u8{""};

pub fn build(b: *std.Build) !void {
    const optimize = b.standardOptimizeOption(.{});
    const target = b.standardTargetOptions(.{});

    const sixel = b.addStaticLibrary(.{
        .name = "sixel-image",
        .optimize = optimize,
        .target = target,
        .link_libc = true,
    });
    sixel.addIncludePath(b.path("include"));
    sixel.addIncludePath(b.path("src"));
    sixel.addIncludePath(.{ .cwd_relative = "/usr/include/" });
    sixel.addIncludePath(.{ .cwd_relative = "/usr/include/x86_64-linux-gnu/" });
    inline for (SOURCE_FILES) |file_path| {
        sixel.addCSourceFile(.{ .file = b.path("src/" ++ file_path), .flags = CFlags });
    }
    b.installArtifact(sixel);
}

const SOURCE_FILES = &[_][]const u8{
    "allocator.c",
    "chunk.c",
    "decoder.c",
    "dither.c",
    "encoder.c",
    "frame.c",
    "fromgif.c",
    "frompnm.c",
    "fromsixel.c",
    "loader.c",
    "malloc_stub.c",
    "output.c",
    "pixelformat.c",
    "quant.c",
    "scale.c",
    "status.c",
    "stb_image_write.c",
    "tests.c",
    "tosixel.c",
    "tty.c",
    "writer.c",
};

Just note that I had to ./configure && make -j then copy some auto-generated header files around and search /usr/include/ for others in order for it to work.