Detexify: handwritten symbol recognition with HTML5
detexify.kirelabs.org
Detexify: handwritten symbol recognition with HTML5
1–10 of 13 posts
Re: Detexify: handwritten symbol recognition with HTML5
#2This 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.
Re: Detexify: handwritten symbol recognition with HTML5
#3This 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.
Re: Detexify: handwritten symbol recognition with HTML5
#4This 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.
It is usually much faster. I think it may have something to do with being on the front page of HN.
Re: Detexify: handwritten symbol recognition with HTML5
#5This 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.
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).
Re: Detexify: handwritten symbol recognition with HTML5
#6Earlier quoted context omitted.
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 al…
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.)
Re: Detexify: handwritten symbol recognition with HTML5
#7This 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.
Re: Detexify: handwritten symbol recognition with HTML5
#8Re: Detexify: handwritten symbol recognition with HTML5
#9this was where i first heard of the KNN algorithm (K nearest neighbors) - cool stuff.
Re: Detexify: handwritten symbol recognition with HTML5
#10Earlier quoted context omitted.
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 al…
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.