Error Parsing Palette

[j0z]

Version: tattoy 0.1.1
Platform: Fedora 42 / KDE Plasma
Terminal: Konsole 25.04.2
Shell: fish

When running tattoy --capture-palette I receive the following error:
Error: Couldn't parse palette, screenshot saved to: "/tmp/.tmp8HLSQwtattoy-screenshot.png". You may also make your own screenshot and provide it with tattoy --parse-palette screenshot.png.

Here are the contents of the screenshot:

I've tried the following:

1. Making Konsole fullscreen and then taking the screenshot.
2. Taking a manual screenshot of just the palette.

Each failed with the same error.

Also, it would always screenshot my primary monitor, not the Konsole window itself or the monitor where Konsole resided.

[tombh]

Thanks for the detailed error report! Even though the screenshot is PNG it has lost some colour definition. For instance the long red column on the left is supposed to be #ff0000, but in your screenshot it's coming out as #ff0906. I wonder if you can change the quality settings of the screenshot?

Also I've come across that bug before where it screenshots the wrong monitor, so I've reopened the old issue for it: #41

[j0z]

This is the screenshot that tattoy generated, not my custom screenshot. I can confirm that my own screenshot does exhibit the same color shift. I thought that this might be an issue with this specific terminal theme (Solarized Dark), but trying several other themes had the same failure.

Looking at the source code, it isn't printing pure red to the terminal:
parser.rs:139

// Print the pure(ish) red that indicates the start of a valid palette row.
Self::print_2_true_colours_in_1((255, y * 2, 0), (255, (y * 2) + 1, 0));

While the palette state machine is looking for:
state_machine.rs:93
let redish_row_start = xcap::image::Rgba::<u8>([255, self.row_index, 0, 255]);

I'm not familiar with Rust, so this might be a red herring, in which case ignore.

[tombh]

A red herring! Nice 😏

You found exactly the right code there. Tattoy does shift the pure red a little to encode the palette row, but only by a single u8 integer. So this bug is more likely to do with how the screenshotter works. And yes good point that Tattoy is the one taking the screenshot, it calls out to the system's window manager and request a screenshot over DBUS. So there must be something about how KDE saves screenshots, that it's doing some optimisations.

I wonder what happens if you were to use some third-party screenshotter, like say https://flameshot.org for example?

[tombh]

Oh BTW if you didn't already see, you can press d when Tattoy asks for confirmation about taking a screenshot and that will install a default Tokyo Night palette, if you just want to play around with Tattoy.

[j0z]

I tried using a flameshot screenshot with the same results.

I'll play around using the default palette, and will update this issue if I find any workarounds for the custom palette generation.

Thanks for the help!

[gryffyn]

I have the same issue.

Version: 0.1.1
Platform: Archlinux / X11 / i3 with picom
Terminal: xfce4-terminal
Shell: zsh

For me, it's because I'm using picom. Disabling the compositor lets the palette be detected properly, whether I use flameshot or scrot with --parse-palette or just do it via tattoy itself.

[tombh]

Also, on Hacker News a couple of commentators mentioned disabling night mode.

More generally though it looks like there's actually an ANSI code to query the true colour values of the palette, namely OSC 4. So then we'll have 2 methods for parsing the palette.

[loewenheim]

I'm experiencing the same problem with the builtin screenshot tool under MacOS 15.4.1.

[hhsw2015]

same problem here

[tombh]

Try the latest release, v0.1.3. Tattoy now supports a completely automatic method for parsing the palette (using terminal ANSI codes, namely the OSC 4 queries).

The screenshotting method is still supported as a fallback method, so in practice this issue still stands. But hopefully you should at least now be able to get Tattoy running.

Please let me know if both methods are failing for you.