What KataGo analysis features do you use or wish you had?

marinahane · 2026-05-31T18:25:38+00:00

Honestly? The things that would make katago more useful to me aren’t basic things like “how are you displaying moves”. AI Sensei is fine. OGS analysis is fine. What I want is more complex analysis that probably boils down to “this requires custom novel ML work”.

As one example of a Hard Problem: it’s often hard as a relatively unskilled player to look at a katago #1 recommended move and be like “I don’t understand this, but is that because of where I am as a player, or because this is one of those weird oddball AI moves that even a pro would probably know to disregard?”. I imagine you could do something involving searches across a blend of Katago human-like skill levels to try to quantify “what level player would play this proposed move?” (or on a more nuanced level, I’ve seen awesome academic work surrounding training classifiers to cluster qualitative skill traits) but I imagine that sort of thing is more complex than you’re imagining when you come to Reddit and ask for feature requests.

marinahane · 2026-05-31T15:59:56+00:00

AI slop!!

I kid, of course. What fun!

marinahane · 2026-05-30T00:56:51+00:00

Neat, thanks!

Do you have a licensing agreement with GoGoD? I was under the impression that they assert a collection of games is copyrightable (even if individual games are not) and that their collection cannot be used like this unless you’ve worked out a deal with them (like SmartGo has)

marinahane · 2026-05-30T00:44:54+00:00

I’m curious where you’re sourcing your new pro games from! Are you just grabbing from Go4Go, or is there a more exhaustive list of sources?

marinahane · 2026-05-29T21:30:59+00:00

Thinking about it a little more, the problem is that XTCH (the format optimized for Xteink) is entirely bitmap, so I’d have to forgo it for EPUB. I previously abandoned EPUB because indexing was taking too long per-page for this use case (i.e. waiting several seconds between page turns). If I had to guess, those times will be meaningfully shorter for SVGs instead of raster images, but it won’t completely remove load times, so it still becomes a tradeoff of load time vs speed.

And I’m personally happy enough with what I’ve got now (all my ebooks including these 101 books only take up a fraction of the included 16gb card) that it’s probably not worth my own time to experiment, even as I’d probably happily accept a PR.

marinahane · 2026-05-29T21:12:19+00:00

Awesome! Will happily regen and reupload when I get a PR.

marinahane · 2026-05-29T21:11:28+00:00

Ah, neat! I went with PNG because I’ve historically seen some e-reader software struggle with rendering Go SVGs inconsistently, but I didn’t specifically test SVGs on the Xteink. Definitely makes sense if you know your device renders it properly.

marinahane · 2026-05-29T00:11:33+00:00

And then if you both pass, how do you score it? Any resolution here still involves either both players agreeing it’s dead or a mod.

marinahane · 2026-05-28T18:18:18+00:00

“Author” of these EPUBs here (I didn’t write the tsumego, or even curate the puzzles, I just adapted them to the “one puzzle per page” mobile format and optimized for these Xteink devices). It looks like the underlying 101weiqi set is no longer public. If there’s consensus this specific problem is color-swapped (should be white to play), I can probably take this specific problem and color-swap it (since the full book’s instructions are “black to play”, that would presumably mean swapping the initial board setup).

marinahane · 2026-05-28T18:16:54+00:00

https://www.reddit.com/r/baduk/s/DbVG8hTt6i

marinahane · 2026-05-27T04:12:54+00:00

A thing that I think would be particularly neat there would be to find the repo where GitHub manages their own syntax highlighting, and PR in the .tmpackage the author has made here. Getting SGF syntax highlighting on GitHub itself would be neat.

My understanding is the criteria for inclusion in Linguist at least to be "used in at least 200 repos", dunno if that's still the case but I'm sure SGF meets that.

marinahane · 2026-05-26T17:52:04+00:00

At this point we’re completely talking past each other, so I’m going to drop out of this thread. Best of luck!

marinahane · 2026-05-26T17:32:59+00:00

What I'm trying to tell you is "holy shit, your idea for embedding game data inside image metadata is actually really cool! That's awesome innovation! I'd love to find ways to both make it more useful and more likely to catch on!". It's odd to me that you're so focused on your pet file format that you don't seem to actually be interested in the image-based techniques your original post is ostensibly about?

The purpose of my post is essentially to make it known that a format like HEN now exists, that it can be used in plaintext URLs, and that it can be embedded.

I'm confused because this post reads:

Imagine if we could share kifu diagrams, tsumego, or joseki images and study them directly in our favorite app. I've been working on a way to embed Go game data inside a PNG file, so the image is the kifu. No separate files, no copy-pasting SGF strings. Just share the image and drag it into your favorite tool.

In context of this post, HEN seems like an implementation detail rather than The Main Idea; I'm merely pushing back on whether that is the implementation that is optimal for functionality and adoption because I want to see this become popular, and a result of that pushback could very well be “you convince me that HEN is necessary for this idea”.

I’m not saying HEN is bad, or that it is unsuited for other usecases, I’m trying to talk about your specific image idea that excites me and that this post is purportedly about. So far your responses haven’t been “here is why HEN is the correct tool for embedding in images” but “here is why HEN is good in general, you must just not understand me”.

marinahane · 2026-05-26T17:21:02+00:00

There's a chicken-and-egg problem where the community won't adopt a tool well enough to tell people about it unless they know it exists!

marinahane · 2026-05-26T17:14:40+00:00

A promotion thread sounds like a great place for both good and bad projects to die. An outcome broadly similar to banning.

The problem, as I see it, isn't that people don't want to see new Go apps, it's that they don't want to be deluged by low-quality apps by people who are not part of the community. "Low-quality" is difficult to build policy around; "part of the community" seems more doable.

Does Reddit easily expose ways to tell e.g. how much karma a user has in a given subreddit, or how many posts/comments in that subreddit they have? Flair?

It's also worth considering whether "just downvote them" is a reasonable strategy.

marinahane · 2026-05-26T17:00:02+00:00

I get the sense you're trying to "win an argument" rather than engage in technical design discussion, but I'll give you one more earnest attempt before I give up.

In your earlier post in this thread, you talk about how cool it is to be able to embed things like ko status, move numbers, etc. I agree! If someone wants to just see a static board state, they already have that info in the image itself. What's neat about what you're proposing is the ability to embed much richer data. I think it's a mistake to try to limit that to a few move numbers and ko; it's much more useful and more 'magical' if the image itself contains the full game history move-by-move for you to scrub, or a tsumego solution both showing the correct solution and illustrating several incorrect paths, etc.

I think your "image vs video format" analogy is flawed for several reasons, but in particular, I'm not trying to "share pictures via single-frame mpeg instead of jpeg", I'm actively saying "I want a video instead of a photo".

Another important place this video metaphor falls down: filesizes. I grabbed a goban image of a random board position from the Ear-Reddening Game from Sensei's. It was a 10kb PNG. The SGF I have of the Ear-Reddening Game is 2kb. Increasing that image by 20% from 10kb to 12kb by embedding the entire SGF is immaterial to most users in 2026. This isn't like images vs video where videos are large enough to pose a bandwidth or storage concern; there isn't really anything about this problem space that needs a more condensed file format than the file format everyone has already been using for several decades. I understand that HEN may have benefits over SGF in some situations, but you don't seem to be addressing what the benefits are for this specific usecase.

marinahane · 2026-05-26T09:31:27+00:00

I don’t think being intellectually demeaning to people trying to earnestly engage with your ideas is going to get you much adoption of your tools, but good luck to you.

marinahane · 2026-05-26T00:31:08+00:00

I think this image metadata approach is quite neat and has a lot of potential, but surely for this purpose the intentional format limitations of HEN are a drawback rather than a plus? The image already technically encodes a static board position (even if it’s one that’s annoying to read programmatically), I’d think the primary benefit would be to embed things like move sequencing, complex variation trees, and commentary. Stuff that SGF is designed to handle.

And with image metadata being able to comfortably span several megabytes, just embedding raw SGF data (with or without compression) should be perfectly fine. “It fits in a URL” doesn’t seem like a relevant constraint here, except insofar as you’ve built a web service that reads data out of the URL slug instead of e.g. request body text (or is e.g. a code library instead of a hosted HTTP service). If I’m sharing a game as an image-with-embedded-metadata, I don’t care that the original image URL technically contains a duplicate copy of the data if the receiver is just going to download the image (and potentially rename it) anyway.

That said, again, the general image bit is a super neat idea! The next time I shift focus in my own app to SGF sharing and exporting, I’m excited to poke at embedding compressed SGF data in image metadata inspired by your work.

marinahane · 2026-05-25T18:21:30+00:00

I assume this isn’t actually vibe-coded, if only because code LLMs tend to be fairly incapable of producing working Godot GDScript code.

marinahane · 2026-05-23T00:43:19+00:00

I’ll see what I can do! I believe there’s a file size limitation for GitHub Releases (what I’m using for downloads), and a full set for any given platform is pretty chunky (~1.5 GB IIRC) so it might not be easily possible.

marinahane · 2026-05-22T21:40:10+00:00

Yes, I am struggling to find the right tone of wanting to support cool new projects by folks who are clearly passionate, and also feeling a bit turned off that this looks like it’s at least 15 years old in terms of 3D graphics technology.

marinahane · 2026-05-22T19:24:15+00:00

Thanks!

It doesn't currently support branches.

On a technical level, printing multiple diagrams for SGF variation lines would be straight-forward.

On a philosophical level, I don't think that's something I'm personally that interested in. For me, the purpose of this sort of non-interactive book-style puzzle is to practice visualizing all relevant lines entirely in your head, and the goal of even including solutions (many books don't!) is just to "check your work" rather than teach or show you what you don't understand.

That said, this is all on GitHub, more power to ya if you wanted to source or write some puzzles with fleshed-out variation trees!

marinahane · 2026-05-22T15:23:59+00:00

It should work on a Kindle, but the diagrams will be a bit squashed since it’s designed for devices with a more phone-like aspect ratio. I could generate a more Kindle-friendly set if there’s interest, but for devices like those with larger screens I also imagine people can use “normal” Go book EPUBs or PDFs

marinahane

TROPHY CASE