Life In 19x19

lovego wrote:The new version is great! The image recognition speed is very fast, but the accuracy needs to be improved, I found that sometimes there will be extra pieces on the edge of the board. In addition, whether it can support the recognition of 9 or 13 board!

1) Your example
The decision whether an intersection is empty or occupied by black or occupied by white, is done by a neural network. This network was only trained with "unmarked" stones, so it doesn't handle numbered stones well. That's why the result is so terrible in your example.
Numbered stones introduce much more variety, so you would need a much more complex network even to differentiate between empty, black and white. So the detection would take much longer. Therefore, I'm not sure if it's worthwhile to try that. Moreover, images with numbered stones are usually generated from an sgf file anyway, so it would be easier to load that one directly into BadukAI.

2) Extra pieces on the edge of the board
I suspect that the reason for this is similar to (1): Stones on the edge look different, because there is no complete intersection. So they have to be trained. But if you generate stone images for training from a board, you get 289 interior stone images and only 72 edge stone images. So the latter are trained too little, therefore the detection on the edge is worse. But that's only a theory yet. I still have to check it.

3) Partial images (9x9, 13x13, corners/sides for tsumego)
I'm working on that ...

Wow, I look forward to that!
And is there an updated acceleration weight? Now the strongest is kata1-b40c256-s10499183872-d2559211369

I'm curious if anyone else's going to find it interesting, but could you make a one color mode? So you can play with bot like the usual, but all the stones would be white or black. That would be really cool!

Zeed wrote:I'm curious if anyone else's going to find it interesting, but could you make a one color mode? So you can play with bot like the usual, but all the stones would be white or black. That would be really cool!

At least godave89 will also find it interesting (well ... unless you are godave89). I will add that in the next version.

No idea who that is, but thanks, can't wait for it.
Also, when switching networks the position on the board resets so you need to save it every time before switching, is it possible to switch the network but remain the position without saving and downloading sgf every time?

lovego wrote:Wow, I look forward to that!
And is there an updated acceleration weight? Now the strongest is kata1-b40c256-s10499183872-d2559211369

I published an accelerated version here: https://github.com/aki65/aki65.github.i ... ag/v1.12.1

Zeed wrote:No idea who that is, but thanks, can't wait for it.
Also, when switching networks the position on the board resets so you need to save it every time before switching, is it possible to switch the network but remain the position without saving and downloading sgf every time?

You can use "Load sgf", then "Load last game" to get back the last position (created by playing or editing), so no need to save sgf.

It looks like the autosaved SGF doesn't include all the moves in order, just the final board state. Would it be possible to implement this?

getseclectic wrote:It looks like the autosaved SGF doesn't include all the moves in order, just the final board state. Would it be possible to implement this?

The drawback of saving all moves is that re-loading the game (and jumping to the final position to continue with it) takes much longer than the current implementation which saves and loads only the final position.

But I agree, sometimes it's desirable to keep all the moves to obtain a complete game record. So I will do something about this in the next version (possibly offering the loading of all moves as an additional option).

Something changed in BadukAI? Previously optimized 40 blocks weights worked without a problem on Snapdragon 845. Now they make KG crash (normal non-optimized weights are still functioning).

veikko wrote:Something changed in BadukAI? Previously optimized 40 blocks weights worked without a problem on Snapdragon 845. Now they make KG crash (normal non-optimized weights are still functioning).

which version and which network?

And wrote:

veikko wrote:Something changed in BadukAI? Previously optimized 40 blocks weights worked without a problem on Snapdragon 845. Now they make KG crash (normal non-optimized weights are still functioning).

which version and which network?

BadukAI 1.12 / kata1-b40c256-s104991

Unfortunately I don't remember which BadukAI version was the last functioning. This issue began months ago.

v1.12.0
"In particular, all this means, that loading an external optimized network (which consists of two files) now requires you to select both files, one after the other."
https://github.com/aki65/aki65.github.io/releases
do you do that?

And wrote:v1.12.0
"In particular, all this means, that loading an external optimized network (which consists of two files) now requires you to select both files, one after the other."
https://github.com/aki65/aki65.github.io/releases
do you do that?

Yes, I've selected both *.bin.gz and *.tflite.

in this case, only akigo will probably help

Unfortunately I don't own a phone with SD 845, so I can't analyze the problem. Thus I can only hint at a few potential reasons for this:

1) Model structure
The code in BadukAI for running KG models hasn't changed for a long time, but the models themselves have (including structural changes). I wouldn't expect these to break compatibility with SD 845, but you never know. To check that, you could load the first published 40b model (from https://github.com/aki65/aki65.github.i ... tag/v1.4.1) and check if that one works.

2) Permissions
There are a lot of different file access permission models on different android versions, so accessing external model files can always be a problem. To check that, you could load the internal 20b network (it's also optimized) and check if that one works.

3) Operating system
Did you receive a system update from your phone's manufacturer recently ? I'm asking because BadukAI needs to access the neural processing unit (NPU) to run the optimized models. The interface, that it uses on SD 845 (and many other chipsets) to do so, was recently discovered to have some security flaws in rare circumstances. Some vendors took the easy way out: Instead of fixing the problem, they blocked the interface completely. I had this on one of my own phones some time ago. Very annoying, but nothing to be done about it.
If that also happened on your phone, it would explain the crash.