Un TEDS ? Enfin ?

Quelques semaines avant de partir me reposer un peu, j'ai voulu faire un test de "3 rooms" sur ma DS. Pas de chance, il manquait une ligne - une seule - au fichier script sur la DS, de sorte que le fichier en question ne se lançait pas. Du coup, quand je me suis retrouvé assis tranquilou à une terrasse, je suis revenu sur cette idée d'éditeur de texte pour la DS.

I really could use a text editor running on the DS, to patch those script files without having to 1) turn the cube on; 2) stick the WiFi in; 3) setup upstream/downstream channels; 4) beam file out; 5) patch it in vim; 6) beam it in again; 7) try and most likely repeat from 4. And I did have a couple of hours by the swimming pool, sitting at a table to think how to approach it.

Et après quelques notes sur comment l'éditeur pourrait fonctionner, je retombe sur cette idée de "mode scribouille" qui me hante depuis 8 ans ... pour finir par me rendre compte que le meilleur programme pour tester le système, c'est celui qui permettrait d'encoder les patterns de chaque lettre. 

Et donc, après quelques petites opérations de maintenance, je lance une nouvelle branche pour prototyper ça , un peu patraque dans mon fauteuil et pas franchement d'attaque pour grand chose d'autre.

Of course, it wouldn't take long before I tried to inject the "handwriting for DS" technique into it, and I realised something interesting: the "minimal viable product" to see whether I can truly write stuff with that technique is 80% of what we need to populate the recognition data. So after more ndsdev in a row that I've been doing over the last few months, I made a first version of "teds", working enough to decide that, yeah, it's kinda-working. 

Je pourrais baptiser ça "un marathon ndsdev", avec son lot d'essai-erreur, de petites étapes prudentes et de passage par DDD pour me rendre compte que j'ai utilisé la mauvaise variable dans l'itération d'une boucle ^^".

J'ai maintenant une sorte de "minimal viable product" qui permet de tracer des lettres et d'effacer l'une ou l'autre lettre d'un L+LEFT. Assez pour constater que 

• des cellules de 4x4 pixels, ce n'est pas convaincant, vu les imprécisions du tandem stylet/DS
• une "zone morte" en bordure de cellule permet effectivement de faire des "diagonales" de façon plus fiable
• il reste souvent nécessaire de faire des "retouches" pixel par pixel
• tracer les lettres d'un traît ou tracer les lettres "tranches de pixel par tranche de pixel" donne grosso-modo la même vitesse d'écriture: 30-32 secondes pour "there is no spoon" (16 caractères avec les espaces)  

Next step will be storage and loading of the "recognition database" and selection of a "bank" of 8 characters to "train" from the ASCII set shown on the left of the screenshot.

 

handscript ... not yet dismissed

I made no progress in building something to recognize scribbling writing input to my NDS homebrew. But I haven't forgot about it completely either.

I had a old post saying "NDS touch screen is 62x48mm. That makes 1 pixel 0.25x0.25mm. My 8x15 font will take about 2x4mm, making it comparable to tracing 3x5 letters on millimeter sheets (following the edges, not filling the dots) with a .2mm pen. That should be quite easy to emulate."

The smallest I know that works is a grid where cells are 4x4. That's what SpriteEditor does in the "big grid". With 4x8 cells per character, that means 16 characters horizontally on the DS screen, and at best 6 rows of text.

I feel like keeping simple squares (or possibly dots ?) would work sufficiently well. A 1-pixel padding to avoid adding corner cells when we're trying to make a "turn". No fancy overlay, no "drag a wire like in those Android lock screens". just use the bottom 8x8 pixel of each character to print which character has been detected.

 

B-trees

i was thinking a bit more about my handscript recognition system for the NDS this week-end, and i figured out that the sorting techique might not need to be as complex as I initially thought.

The plan is to support the 128 characters of the ASCII charset. There should be a way to define multiple models for the same character — e.g. you might have the ‘d’ character done in either 1 or 2 strokes — but I doubt I would ever need much more than 4 model of each one. That means at most 1K models to sort.

In my technique they can all be indexed with a 16-bit code, but even then storing 64 K pointers would be overkill. I had plans for techniques that find the most discriminating bit(s) for a subset of the models an make an optimal radix tree, but then I realised that with only 1K entries, it might even not be required: a simple B-tree structure would index all the keys with just 64 index blocks of 16 pointers each, plus 4 super_index blocks and one top-level index. This is a perfectly sustainable amount of overhead. Plus I already have a B-tree implementation from my Clicker32 operating system project. . .

Scribble Widget

quelques petits essais (dans SEDS) de ce que donnerait un système de reconnaissance d'écriture avec soit 8 pixels ou 6 pixels par "cellule". Je préfère 6. La police 8x15 juste à côté servirait pour les caractères reconnus (une fois le tracé terminé).

Ideas for a handwriting recognition on DS

Il y a un moment que je retourne l'idée dans ma tête : un système permettant d'écrire librement (du code, pour l'éditeur de comportements) sur DS. Le système serait basé sur une grille 3x5 visible par l'utilisateur. Parce que les claviers virtuels, c'est pénible et qu'un système qui autorise l'utilisateur à écrire n'importe où et n'importe comment, ça n'aura aucune chance de marcher avec 66MHz


That is another idea that has been laying on paper for a while. I lack text and script editors at the NDS.  I don't want to go for a virtual keyboard, because they are really too slow to work with. I can't afford a complex recognition system, and even Google's handwriting system would suck on code expressions.

But I feel like it would be easy to recognize letters when they have been written on a grid. A bit like if we were painting a low-resolution font.

Every letter drawn corresponds to a 15-bit map that can be quickly tested against a small database of features and suggest letters to pick when the decision is fuzzy.

 Additional features could be the starting and terminating coordinates, as well as the number of strokes.

Cette petite grille fait que chaque lettre tracée correspond à un code sur 16 bits unique. A partir de ce code, on pourrait rapidement identifier un groupe d'entrées dans une petite base de données qui traduit les traîts en lettre (p.ex. à partir de la position du point d'origine et du nombre de traits). Je ne veux pas me limiter aux lettres, évidemment. L'idée est de reconnaître l'ensemble des caractères ASCII pour pouvoir éditer du code n'importe où le plus facilement possible. 

I hope the result will be an interesting compromise between
- early PDA "one-weird-stroke-to-write-them- all" (Palm's Graffiti system)
- sharp Zaurus "Free-letters-one-by-one"
- OCR from scanned text.

I know segmenting is a complex task in letters recognition. With pre-drawn grids, the user is guided to start a new segment or stay in the current one. We can also tell apart uppercase and lowercase Eg. "p", punctuations, etc. locally rather having to rely on some line-level calibration. And we can naturally move to the next space for the next letter.


Avec cette grille, je m'affranchis d'un des problèmes les plus costauds de la reconnaissance de caractères (la segmentation) tout en permettant d'utiliser le plus naturellement possible l'espace disponible (sur Zaurus, on devait presque toujours revenir au même endroit pour tracer la lettre suivante ou le mot suivant). Et c'est toujours plus pratique à apprendre (encore qu'on pourrait essayer d'apprendre de nouvelles écritures à la DS) d'écrire "comme Pype/Zaurus" plutôt que "comme en Grafiti", même si grafiti avait le bon goût de ne demander qu'un trait par caractère.

Granted, the hand script writing I use when I want maximum readability already separates letters a lot and uses only one stroke for most lowercase. Because I reformatted my writing for the Zaurus already. But it's not like I had a huge user base to take into account ^^".

The granularity of the grid should help making tricky characters like braces-versus-digits-versus-C easier to deal with.

One man and his (an)droid

Je me suis arrêté d'abord sur le prix: 90€. Non, pas de 3 ou de 4 devant, juste 90€. C'est bien le système androïd qui tourne sur un processeur ARM à 600MHz, avec 256Mo de RAM et 4Go de stockage interne. Lecteur de carte média ? check. Connectivité Wifi ? check. Evidemment, à ce prix-là, ni 3G, ni téléphone, mais on a quand-même l'écran tactile. L'écran ne fait que 10cm avec une résolution plutôt miteuse (480x272 ... ils ont été chercher ça où ?), mais comme kit de développement, ça place la barre nettement plus bas, et c'est tant mieux.

The iPad is not for me. That's a fact. The more I test "my brother's one", the more I'm comfident with that. Paying +400€ for an Android phone ? well, I don't think so. My little vgmap-themed Siemens C60 does the job so far. But that doesn't mean I don't see any interest in androïd development ... at least that's what I realise when I see in an advertisement magazine an ARM-powered device with WiFi and SD media card for 90€. No kidding. You would barely find an iPhing *stylus* for that price :P. Either that or the digitizing pen from Staedler, with the hope that it would work correctly under Linux.

On y verra plus clair après test en magasin. Sinon, il restera l'Asus Transformer, mais nettement moins abordable ... D'un autre côté, pour 20€ de plus, on passe à 18cm d'écran (800x480, mpman720) pour une tablette taille A5. On fait des stylets, pour écrans résistifs ? oui. ça, j'aime :) Mais tout au fond de moi, je crois bien que ce qui me serait le plus utile, vu ma manière de travailler (que ce soit pour le boulot ou le Bilou), c'est cet espèce de bic-numérisateur autonome ... 'faut juste voir si la suite d'outil que Staedler propose avec fonctionne sous Linux :) Evidemment, si les gusses qui avaient proposé le projet Noteslate avaient effectivement réalisé ce qu'ils promettaient, je ne me poserais pas tant de questions.

Of course, both are pathetic replacement for the missing noteslate on my christmas wish list.

Dernière possibilité, aux alentours de 180€, le e-Reader de Sony (PRS-T1) avec la technologie "e-Ink" annoncée dans la noteslate, wifi et écran tactile. Mais c'est Sony. Les connaissant, ça ne va pas aller sans mal de faire du homebrew là-dessus ... quoi que ...