Support schemes in YAML format

[akx]

Description

This PR is a bit on the big side, sorry 'bout that!

Screenshot generator

1. Improves the new (Generate screenshot images programmatically #491) screenshot generator:
   • Changes the rendering to use a monochrome (not an antialiased grayscale) font at 4x the intended rendering size, and changes from the Lanczos filter (that may cause ringing, i.e. color distortion in our case) to the box filter, which was selected to look the best for this use case while retaining the palettes' intended colors in all text pixels.
   • Adds support for showing the selection and cursor colors in the screenshots, where available, sneakily in the upper-left corner where we had a couple extra pixels left.

Theme converter

1. Refactors the generator/converter to be more modern Python (more functional and dataclass-y). The functionality remains the same.
   • I think the "guint16" generation for Tilda is incorrect, but I didn't fix it since I don't have Tilda, and also didn't want all the Tilda files to get regenerated. There's a note about that in the code.
2. Adds support for themes specified as YAML. The format is an extension of the YAML format used by Gogh.
   • Where a YAML file is specified, an iTerm color scheme file (with an sRGB colorspace specified) will be generated from the YAML.

Themes

1. Updates the Dracula theme based on a YAML file based on the upstream Kitty Dracula theme (see 2490)
2. Regenerates Gruvbox Material schemes based on a YAML file based on the Ghostty theme from Sets correct gruvbox-material colors #499.

Misc.

7. Adds a makefile and documents this new malarkey.

---

This will make it easier to contribute themes without having a Mac at hand (see e.g. #502).

Users can still contribute themes in the iTerm scheme format, and things work just as they did before, but where a theme has a YAML file, that will be considered the source, and the similarly-named iTerm color scheme file will be generated from that YAML file.

Caution

The dark/light variants that had been in the Gruvbox Material iTerm color scheme are obliterated by this change. (We didn't support reading those into other scheme formats anyway.) Is that OK?

[akx]

Before I undraft this, could @Gelmo (from #490) and @Lira-tron (from #499) check that the Dracula and gruvbox-material screenshots (and schemes, if you can) look as they should?

[Gelmo]

Nice!

I noticed that the font used in the new screenshots differs from existing screenshots.

Here are my notes on Dracula as requested. These notes are in regard to the image, not the theme/scheme files themselves. I'm using the screenshot replaced in this PR instead of what you posted in the previous PR. I'm checking locally with GIMP's color picker and with https://imagecolorpicker.com to confirm, and comparing to https://spec.draculatheme.com. But based on what you said in the previous PR RE screenshots, I'm not sure this means much haha:

• Background is correct
• Foreground/White is correct
• Selection is correct
• Comment/BrightBlack is inconsistent, screenshot is too compressed
• Red is correct
• Orange isn't used, so I can't confirm
• Yellow is correct
• Green is correct
• Purple/Blue is correct
• Cyan is correct
• Pink/Magenta is correct
• Black is correct
• BrightRed is inconsistent, screenshot is too compressed
• BrightGreen is inconsistent, screenshot is too compressed
• BrightYellow is inconsistent, screenshot is too compressed
• BrightBlue is inconsistent, screenshot is too compressed
• BrightMagenta is inconsistent, screenshot is too compressed
• BrightCyan is inconsistent, screenshot is too compressed
• BrightWhite is correct

The Dracula.yml file looks to be correct when compared to https://spec.draculatheme.com/

Looking at the themes for Alacritty, Ghostty, and Kitty, which are all hex colors, those all seem to be correct as well.

[akx]

I noticed that the font used in the new screenshots differs from existing screenshots.

Yes, that happened in #491 :) Before that PR, screenshots were created by hand by contributors, so cropping was inconsistent from image to image and text could be squished in various ways.

What do you mean with "inconsistent" though, re the bright colors? 🤔

And thanks for double-checking!!

[Gelmo]

What do you mean with "inconsistent" though, re the bright colors? 🤔

Due to the high compression of the screenshots, the true color cannot be found in some of the printed characters; there is significant variance. Here is a screenshot of the BrightRed against the default background, zoomed in (from the image added in this PR):

The color #FF6E6E does not appear in any of the pixels in this screenshot, due to the heavy compression.

[akx]

Due to the high compression of the screenshots, the true color cannot be found in some of the printed characters; there is significant variance.

Ah! Gotcha – that's not (lossy) compression (they're PNGs), that's ringing artifacts which are caused by us resizing the screenshot down to the predetermined 600x300 size (especially since I poorly chose Lanczos resampling as the resampling algorithm).

Please find below the original, crisp, fresh and clean 1280x608 version of the screenshot (click through to open in full size, etc., etc.):

On a related note, which of these looks the best to you? (They're all the same image, just rescaled down using a different resampling algorithm.)

1. 
2. 
3. 
4. 
5. 
6. 

[ViViDboarder]

I recently stumbled on this colorspace issue when trying out Ghostty using the Wombat theme and noticing that my Neovim theme (wombat.nvim) that I wrote while using iTerm2 doesn't quite match.

Using a file specifying the color space seems like a good idea, but neither the iTerm2 or the Ghostty (or other derived themes) appear to actually respect the original colorscheme. Here as an example, here are the background colors:

• Original Wombat theme: #242424
• iTerm 2 theme here after loading in iTerm2: #1e1e1e
• Ghostty theme derived form iTerm2: #171717

As for wombat.nvim, it was matching the iTerm2 hex, but now I now have two variants, one matching the original hex and the derived Ghostty hex here.

Assuming this PR moves forward, what would be the recommended course of action? I'm thinking that since the vim colorscheme is the original source but doesn't have all terminal colors represented, I can create a YAML file using the hex values shown to me in iTerm2 after loading the scheme. I could update it as well to be more faithful to the original Vim colorscheme, but I'm thinking that may not be worthwhile since the original iTerm2 theme itself has a 14 year history.

[Gelmo]

Please find below the original, crisp, fresh and clean 1280x608 version of the screenshot (click through to open in full size, etc., etc.):

This looks perfect! I've confirmed that the colors that I previously couldn't confirm are indeed in the expected places in that image.

On a related note, which of these looks the best to you? (They're all the same image, just rescaled down using a different resampling algorithm.)

On my display and with my eyes, numbers 1 and 2 are the most appealing to me. They are practically indistinguishable from one another until zooming in on characters in front of light backgrounds.

Number 5 has easier to read characters against the darker backgrounds despite having brighter colors.

Looking closely in GIMP, number 6 is the only one that shows the correct colors, despite being the least visually appealing of the bunch.

In my opinion, I would go with number 6 since it accurately represents the themes. Maybe the look could be improved with a different font and/or font size. And maybe different characters than "qYw"

[Gelmo]

Assuming this PR moves forward, what would be the recommended course of action?

@ViViDboarder In my opinion, existing official scheme files should be ignored if that theme also has official specifications. Ideally everything here would be built to spec when possible unless requested by the upstream theme for a specific reason. Then themes generated here could be used to replace/update official schemes upstream if they have schemes that don't respect their specifications, if they desire.

[akx]

@Gelmo Thanks for the input! I realized one more thing regarding the font rendering to improve things – which one(s) do you prefer out of this batch?

1. 
2. 
3. 
4. 
5. 
6. 

[Gelmo]

@Gelmo Thanks for the input! I realized one more thing regarding the font rendering to improve things – which one(s) do you prefer out of this batch?

Sorry, went to bed after my last comment!

• Numbers 5 and 6 show the accurate colors
• Number 6 is atrocious on the eyes :P
• Number 4 is too blurry
• Number 3 seems washed out
• Numbers 1 is the most clear
• The letters on number 2 get fuzzy, looking at the w

I think number 5 is the way to go. It has similar blur to number 4 but it's still legible enough and it shows accurate colors of the represented theme. I assume it will not be trivial to get it to look better at that size while retaining the accurate colors.

Sorry for making you put in all this effort xD hopefully my eyes and your work will be beneficial to this project :P

[akx]

@Gelmo No worries, time zones are what they are (I'm based in Finland), and I'm also a sleep enthusiast in my free time 😂

I agree that number 5 looks good, so let's go with that...

[mbadolato]

Thanks! I'll try to review this over the weekend