9 ms·

Show HN: Interactive, Visual Explanation of the GRAIL Handwriting Recognizer

119 points by jackschaedler 11y ago

deleted 11y ago
[deleted]
voaie 11y ago
Great! The linked demos give a very creative feel.
amelius 11y ago
Nice demos. This is what "literate programming" should be like really :) It is unfortunate that it can't recognize lowercase/uppercase, and that F and X have to be drawn in a quirky way to be properly recognized. Also I had problems with inputting "K".
- skykooler 11y ago
  I also had problems with "K"; I think the issue is that it does not recognise strokes where the second direction is right (rather than up) as a "K".
- jackschaedler 11y ago
  Thanks! I'll take some time this evening to make it a bit better at picking out the K.
HappyTypist 11y ago
Nice demo. I've never been able to get it to recognise B, no matter how I draw it.
- refset 11y ago
  It didn't work with how I normally write B either (drawing downwards from the top-left corner), but I did find a method that worked: start at the bottom-left corner, move up to the top, then draw a "3"
- jackschaedler 11y ago
  I'll take some time tonight to make it a bit better at dealing with different shapes of Bs. If you want to know what the 'canonical' stroke pattern is, you can click on the little graphics above the tablet. They will animate to show you the expected stroke path (although, it should just work, so I'll fix that tonight)
- shultays 11y ago
  Same thing for me on O. I tried clockwise, counter clockwise both failed. Then I tried starting from top instead of bottom. Don't people start from bottom? It should be easier to align.
  - XaspR8d 11y ago
    I start many of my letters from the bottom, and everyone tells me I write opposite-handed. This recognizer definitely had problems with the way I would naturally write a lot of the letters...
  - jackschaedler 11y ago
    Oh goodness, haha. Doing this project I've learned that there is a great deal of variety in handwriting style. Single-stroke vs. Multi-stroke 5 for example, seems to be a big point of contention. I'll extend the decision tree to be more friendly about bottom-starting strokes.
gugagore 11y ago
It could be worth mentioning that, for thinning points, ideally you'd use a circle, so that points are thinned equally in all directions. When you use a square, diagonal lines are thinned more (by a factor of sqrt(2)) than horizontal/vertical lines. However, checking inclusion within a axis-aligned square requires only comparisons/subtractions, but checking inclusion within a circle requires square roots and squares... certainly a big deal back then.
- jackschaedler 11y ago
  This is a great point. When I first implemented the visualization, I actually used a circle until someone pointed out to me that the formula describes a square region around the datapoint and not a circle. I think you are very right in saying that this decision was made by Groner solely for efficiencies' sake in 1966. I'll probably add a side-note to explain this a bit.
rayiner 11y ago
Worth looking at the linked video. Pretty impressive what they could do using late 1960's technology.
dsr_ 11y ago
This looks 99% identical to what Palm developed as Graffiti. Graffiti ran nicely on a 16MHz (later 33MHz) 68030ish microprocessor with 512KB of RAM and a 160x160 LCD display with a resistive touchscreen. I think that I'm faster on an Android soft-keyboard with prediction and sliding, but not by very much.
some1else 11y ago
Thanks for this wonderful essay! I love learning about that period in computing, when a lot of what we use today was first challenged. It's easy to see how those same principles apply to the GRaIL visual programming interface demo[1], where different strokes create different types of elements (boxes, outputs, connections, ...). [1]: https://www.youtube.com/watch?v=QQhVQ1UG6aM https://www.youtube.com/watch?v=QQhVQ1UG6aM
tikwidd 11y ago
It reminds me of the Palm handwriting recognition system. I liked there was no pretensions of natural handwriting recognition on the Palm. The awkward way you had to draw letters with the stylus was part of the UI, so little stroke order hints were displayed on the screen while you were writing. It made for a fairly efficient input system after a bit of practice, like txting on old phones. I assume the Palm system worked on similar principles to GRAIL.
iswim 11y ago
for recent(ish) activity https://depts.washington.edu/aimgroup/proj/dollar/ https://depts.washington.edu/aimgroup/proj/dollar/
Schwolop 11y ago
This is great! You've already linked to Bret Victor's work, but I'll pay you the compliment of saying this essay and demonstration is up there with some of his productions.

119 points by jackschaedler 11y ago

deleted 11y ago

[deleted]

voaie 11y ago

Great! The linked demos give a very creative feel.

amelius 11y ago

Nice demos. This is what "literate programming" should be like really :) It is unfortunate that it can't recognize lowercase/uppercase, and that F and X have to be drawn in a quirky way to be properly recognized. Also I had problems with inputting "K".

skykooler 11y ago
I also had problems with "K"; I think the issue is that it does not recognise strokes where the second direction is right (rather than up) as a "K".
jackschaedler 11y ago
Thanks! I'll take some time this evening to make it a bit better at picking out the K.

HappyTypist 11y ago

Nice demo. I've never been able to get it to recognise B, no matter how I draw it.

refset 11y ago
It didn't work with how I normally write B either (drawing downwards from the top-left corner), but I did find a method that worked: start at the bottom-left corner, move up to the top, then draw a "3"
jackschaedler 11y ago
I'll take some time tonight to make it a bit better at dealing with different shapes of Bs. If you want to know what the 'canonical' stroke pattern is, you can click on the little graphics above the tablet. They will animate to show you the expected stroke path (although, it should just work, so I'll fix that tonight)
shultays 11y ago
Same thing for me on O. I tried clockwise, counter clockwise both failed. Then I tried starting from top instead of bottom. Don't people start from bottom? It should be easier to align.
- XaspR8d 11y ago
  I start many of my letters from the bottom, and everyone tells me I write opposite-handed. This recognizer definitely had problems with the way I would naturally write a lot of the letters...
- jackschaedler 11y ago
  Oh goodness, haha. Doing this project I've learned that there is a great deal of variety in handwriting style. Single-stroke vs. Multi-stroke 5 for example, seems to be a big point of contention. I'll extend the decision tree to be more friendly about bottom-starting strokes.

gugagore 11y ago

It could be worth mentioning that, for thinning points, ideally you'd use a circle, so that points are thinned equally in all directions. When you use a square, diagonal lines are thinned more (by a factor of sqrt(2)) than horizontal/vertical lines. However, checking inclusion within a axis-aligned square requires only comparisons/subtractions, but checking inclusion within a circle requires square roots and squares... certainly a big deal back then.

jackschaedler 11y ago
This is a great point. When I first implemented the visualization, I actually used a circle until someone pointed out to me that the formula describes a square region around the datapoint and not a circle. I think you are very right in saying that this decision was made by Groner solely for efficiencies' sake in 1966. I'll probably add a side-note to explain this a bit.

rayiner 11y ago

Worth looking at the linked video. Pretty impressive what they could do using late 1960's technology.

dsr_ 11y ago

This looks 99% identical to what Palm developed as Graffiti. Graffiti ran nicely on a 16MHz (later 33MHz) 68030ish microprocessor with 512KB of RAM and a 160x160 LCD display with a resistive touchscreen. I think that I'm faster on an Android soft-keyboard with prediction and sliding, but not by very much.

some1else 11y ago

Thanks for this wonderful essay! I love learning about that period in computing, when a lot of what we use today was first challenged. It's easy to see how those same principles apply to the GRaIL visual programming interface demo[1], where different strokes create different types of elements (boxes, outputs, connections, ...). [1]: https://www.youtube.com/watch?v=QQhVQ1UG6aM https://www.youtube.com/watch?v=QQhVQ1UG6aM

tikwidd 11y ago

It reminds me of the Palm handwriting recognition system. I liked there was no pretensions of natural handwriting recognition on the Palm. The awkward way you had to draw letters with the stylus was part of the UI, so little stroke order hints were displayed on the screen while you were writing. It made for a fairly efficient input system after a bit of practice, like txting on old phones. I assume the Palm system worked on similar principles to GRAIL.

iswim 11y ago

for recent(ish) activity https://depts.washington.edu/aimgroup/proj/dollar/ https://depts.washington.edu/aimgroup/proj/dollar/

Schwolop 11y ago

This is great! You've already linked to Bret Victor's work, but I'll pay you the compliment of saying this essay and demonstration is up there with some of his productions.