Detexify: handwritten symbol recognition with HTML5 | Hacker News Reader

Detexify: handwritten symbol recognition with HTML5

detexify.kirelabs.org

44 pointsysh4u12 comments

http://news.ycombinator.com/item?id=713743

http://news.ycombinator.com/item?id=1607964

This works incredibly slowly for me (~30 seconds per symbol after I stop drawing), and doesn't work at all on my iOS devices (where I can actually draw reasonable looking characters, unlike with my mouse). Still, it's a really neat app.

There's a free App Store version.

http://itunes.apple.com/us/app/detexify/id328805329?mt=8

It is usually much faster. I think it may have something to do with being on the front page of HN.

Why? If it is truly "in HTML5"... that implies there is not a server side component. If it is just grabbing the drawing from canvas and submitting it to the server, I'm not really impressed.

And considering how slow it is now, I'm not sure what exactly to think. :/

edit: Yup, a quick run with Chrome shows that it is just sending a list of the strokes to the server. It explains the speed. I'm more interested in the algorithm (and why it wasn't ported to client side JS. That would made for a much more impressive showing and a lower hosting bill).

Nit time! In html5 ≠ exclusively in html5.

As a full match database may well weigh in at a few hundred megabytes (pure speculation here), schlepping it over to the client would make for a must less impressive showing and a higher hosting bill.

(As fun as it would be to "view source" for it, or have it work offline.)

Hi, I am the author. There is actually no HTML5 involved. It's SVG+AJAX on the client side and Ruby on the server side, though a backend written in Haskell is nearly ready to be deployed. Gotta fight some memory leaks before I will switch though. I am planning for client side processing but there is some serious number crunching going on behind the scenes and I am still sceptical if Javascript can do it.

Just wondering how the classifier works. You presumably calculate the probability of each symbol matching the one I have drawn, but I wondered if you did any a priori modelling of the likelihood of me drawing any particular symbol. For example, I went and drew a simple capital theta, and it was number 5 on the list after some fairly esoteric shapes, all with similar shapes. At the point, where there are several very similar shapes, I'd have thought having a good prior distribution helps accuracy more.

Are you using click data to model what people are drawing, or just to retrain the classifier? It's also not totally obvious you should click the right one — I only realised after I started writing this comment.

Also, I noted Greek letters are displayed in italics. Did you train on italics only for? People don't tend to write italics, which might be why Greek letters are not matching well for me.

Is it possible to extend the idea with equations (handwritten) as input, and produce the corresponding Latex source as output? That would save lots of time.

As the interface is similar to Chinese character mouse input software (which is really fast), maybe the backends could be more similar..

this was where i first heard of the KNN algorithm (K nearest neighbors) - cool stuff.

Reply on news.ycombinator.com