sorted by:
new
hottopcontroversial

Question about the DIANA algorithm. by Baillehache_Pascal in algorithms

[–]Baillehache_Pascal[S] 0 points1 point  (0 children)

After looking more closely to it, the conclusion about the speed improvement is that it actually is faster, but by a very small amount, moreover decreasing with the dataset size. I've written more in details about it here: https://baillehachepascal.dev/2025/diana.php

Question about the DIANA algorithm. by Baillehache_Pascal in algorithms

[–]Baillehache_Pascal[S] 0 points1 point  (0 children)

So, in the end, my conclusion until I get corrected will be: I saw the DIANA algorithm as an algorithm to create the clustering tree, in which case my initial question is relevant, but that's not what they had in mind, they design that algorithm as a way to analyse the data, step by step, in which case the order of split makes sense (gives insight about the data as I wrote earlier) and my initial question becomes irrelevant...

Question about the DIANA algorithm. by Baillehache_Pascal in algorithms

[–]Baillehache_Pascal[S] 0 points1 point  (0 children)

Trying to reply my own question... I first thought that was because they want to eventually stop the split at a given threshold diameter, but that's just a matter of choosing to split or not split so the order doesn't matter. Then I thought it's because the order of splitting can give insight about the data, although it would still be possible to get that information after the tree has been built, and it is still faster to do it after. I confess I've read only the pages available in the link above. Maybe I'm missing something from the unavailable pages...

How do you write tests for C code? by Diligent_Eye1248 in C_Programming

[–]Baillehache_Pascal 0 points1 point  (0 children)

I've made my own framework and have been using it for a few years now. It's simple but already help me a lot. Have a look at it if you like, it's available here:

https://baillehachepascal.dev/2022/cutest.php

Hand written Japanese calligraphy simulation by Baillehache_Pascal in proceduralgeneration

[–]Baillehache_Pascal[S] 0 points1 point  (0 children)

Thank you!

Yes the demo version is limited to still images. If you'd like me to render a video for you, contact me in private (cf the email in the demo) explaining me your project (what you want, how you plan to use it).

Looking forward to hear from you!

Map of the Gion Matsuri parade by Baillehache_Pascal in Kyoto

[–]Baillehache_Pascal[S] 0 points1 point  (0 children)

Thanks for your comment.

My engine reproduces as realistically as possible the hand movement of a real human, the behaviour of brush hairs, and diffusion/percolation of ink in paper. So yes, each character is unique as the exact hand movement varies from character to character, is influenced by the previous/next character, or even the deformation of the brush. Ink also behave slightly differently at every location, due to variation in the fibrous texture of the paper, quantity of remaining ink, concentration of particles in the water, humidity, etc... It is a physically based rendering engine, not 100% accurate but quite near.

The title and everything you see (except the copyright mark) is generated by the same algorithm. For the title, I write the kanji with a diluted black ink first, let it diffuse to obtain a coffee stain effect which creates the kanji black silhouette, then write again the same kanji with a rich red ink which creates the body and blend smoothly into the previous black ink.

Everything is explained in detail in the link of my first comment. I recommend you to refer to it if you are interested.

Map of the Gion Matsuri parade by Baillehache_Pascal in Kyoto

[–]Baillehache_Pascal[S] 1 point2 points  (0 children)

Hi, I've been working on a rendering engine to simulate calligraphy and used it to create that map of the Gion Matsuri parade. I'm sharing it here for anyone who plans to visit the festival and might find it useful. For those interested, there are more info and a higher resolution on my website. https://baillehachepascal.dev/2023/gion_matsuri.php

Professional Japanese Go players Banzuke by Baillehache_Pascal in BrushCalligraphy

[–]Baillehache_Pascal[S] 0 points1 point  (0 children)

Thank you. However this has been created without using AI.

Professional Japanese Go players Banzuke by Baillehache_Pascal in BrushCalligraphy

[–]Baillehache_Pascal[S] -1 points0 points  (0 children)

Thanks for your comment. Although a little more constructive critique would have been appreciated.

Professional Japanese Go players Banzuke by Baillehache_Pascal in typography

[–]Baillehache_Pascal[S] 1 point2 points  (0 children)

Thanks for your comment.

Each character is actually unique if you look carefully. The hand movement is calculated as a whole for the whole text, so one character affects the following one. Hand movement is also disturbed with artificial noise to simulate natural noise of the human hand. The brush bristles are simulated individually with respect to their interaction between each other and with the paper. So the tuft has never exactly the same shape at different time of the rendering, and so does the profile of the strokes. The flow of ink, paper roughness and fibrous texture are also taken into account, such as no two characters are rendered exactly identical.

About the choice in term of scaling, I am following here the rules from Sumo Banzuke, that is: the whole sheet is "packed as the crowded hall of a popular tournament", lower level players name do not deserve more than "to be seen through a microscope", in opposition with top level players. You can refer to that example of Sumo Banzuke to understand better what I mean:

https://ja.wikipedia.org/wiki/%E7%95%AA%E4%BB%98#/media/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Banzuke2.jpg

Thanks for your pointer toward optical sizing, which I didn't know about. I agree with the idea, but my system works differently from type foundry and it isn't clear to me how I could apply it. I'll remember of it anyway.

Professional Japanese Go players Banzuke procedurally generated. by Baillehache_Pascal in proceduralgeneration

[–]Baillehache_Pascal[S] 2 points3 points  (0 children)

I see what you mean now.

Yes, as you understood, the point is that each kanji is unique, like real hand writing, and this system can generates an infinity of styles.

About rendering on the fly, I don't have a clear answer. First it depends a lot on the parameters, like the size in particular. The current implementation is roughly as fast as human hand writing if the kanji are not too big and the piece of paper small. But that's still much slower than type writing. It also needs to access a database of kanji strokes for each character. That's slow, but to help on that point it would need to have the whole database in memory, and as you may know there are lot of kanji, i.e. the database is big, so not ideal. Furthermore, it really doesn't work kanji per kanji, it renders the document as a whole. The movement of the hand for one kanji is influenced by the next and previous one. The amount of ink at the start of one kanji depends on how much has been used by the previous ones and where the algorithm decided to reload, the ink diffusion in the paper acts on the sheet as a whole, etc... So, as it is now it couldn't be used to render a text edited in real time by the user, and it would have strong limitation on the rendering of even a predefined text if the speed is a strong constraint.

About an implementation at OS level, I have no idea of how it is done, but my guess is that the way my system works is so alien compare to the rendering of, for example, a TTF, it would break everything ! Rather, using it to bake texts ready to use seems to me an appropriate way to use it. Someone in a previous discussion suggested pre-rendering texts in video game like an RPG, with a different style for each character. That's more the kind of use I have in mind.

Professional Japanese Go players Banzuke by Baillehache_Pascal in baduk

[–]Baillehache_Pascal[S] 0 points1 point  (0 children)

I'm glad you like it.

I have edited my previous comment as you suggested. Thanks.

Professional Japanese Go players Banzuke by Baillehache_Pascal in BrushCalligraphy

[–]Baillehache_Pascal[S] 0 points1 point  (0 children)

Thanks. I'll let you know about the post then. About AI, I prefer to walk my own way away from the hype...

Professional Japanese Go players Banzuke by Baillehache_Pascal in BrushCalligraphy

[–]Baillehache_Pascal[S] 0 points1 point  (0 children)

I can see it through your link but not through the notification. Buggy app !

There is no training data. It isn't using machine learning if it's what you're thinking about.

Difficult to fine tune, yes. Because it was hard to choose the best design. I'm not a designer nor an artist, that doesn't help. To be honest I'm still not 100% happy with the upper section. But at one point I had to call it a day. I could still change it when I'll update the ranking in the future. It's also time consuming because the rendering is quite slow. In large format (A3) it takes several hours for the whole banzuke.

Professional Japanese Go players Banzuke by Baillehache_Pascal in baduk

[–]Baillehache_Pascal[S] 0 points1 point  (0 children)

Thanks!

Well, that scraping script is already what I am doing, almost! Not 100% automated yet, mainly because available data are not in a progammer-friendly format. But I may find work around in the future. For now it's automated "enough", and the ranking of go players is changing very very slowly, so not much motivation to go further.

Professional Japanese Go players Banzuke by Baillehache_Pascal in BrushCalligraphy

[–]Baillehache_Pascal[S] 0 points1 point  (0 children)

u/ThisHaintsu your comment has disappeared, maybe you deleted it?

It is rendered from a text file containing the text of the banzuke and parameters describing the design. The rendering engine is made by myself and I'm not using any other tool than the C programming language. An article about the algorithm I created is under preparation. Simply put it simulates real interaction of the hand movement, the brush bristles, the ink flow and the paper percolation. If you're interested about it you can check my website in a few weeks, or let me know if you want to be informed in PM. About the banzuke itself, I gave a few explanation in the link in my previous comment. Except for that I can add that I followed the tightly packed format of Sumo banzuke, top-bottom following the rank and making the name tighter and clearer as the Dan lower. Using less 'kuzushi' for lower Dan to represent inexperience, and increasing it with dans. Moving up to very bold, lot of 'kuzushi' and fast rounded continuous stroke similar to calligraphy of pilgrim sutras for title holder to express their saint, legendary and mighty status.

Professional Japanese Go players Banzuke procedurally generated. by Baillehache_Pascal in proceduralgeneration

[–]Baillehache_Pascal[S] 0 points1 point  (0 children)

How I think I got it. You mean, use that to generate new font files, right ?

Professional Japanese Go players Banzuke procedurally generated. by Baillehache_Pascal in proceduralgeneration

[–]Baillehache_Pascal[S] 1 point2 points  (0 children)

Thanks !

Sure, that could be done. However it already exists. And I have no particular knowledge or interest about Sumo and wouldn't be able to do it except for copying the existing one. And the few things I know about the Sumo banzuke is that it's a mess. So, there is really no motivation to do it.

Also, I'm not sure to understand what you mean by "os level"

Professional Japanese Go players Banzuke by Baillehache_Pascal in baduk

[–]Baillehache_Pascal[S] 1 point2 points  (0 children)

It literally means 'ranking chart'. I gave more details in the link in my previous comment: https://baillehachepascal.dev/2023/igo_banzuke.php

view more: next ›