A developer who builds browser-based projects such as WebGL Gaussian splatting, JavaScript OCR, WebM encoding and an SVG animation tool.
HN commenters link it for his web demos, such as the Ajax Animator and splat viewer, and for his essay on the H.264 versus VP8 video debate.
Extension is awesome and while the code is messy, it has enough little jokes to keep you amused. For those looking to access the backend OCR service, it seems to be down right now, but will hopefully come back up soon.
Here were the API references I could find for the remote OCR:
- GET https://sky-lighter.appspot.com/api/read/<chunk.key>
- GET https://sky-lighter.appspot.com/api/lookup?url=<image.src>
- POST https://sky-lighter.appspot.com/api/translate
Apparently the author was one of the winners of HackMIT 2013 according to some of the comments. Couple of fun things in there if you decide to poke around in the code. Jump into naptha-wick.js for the remote logic.
Note from the Dev (http://challengepost.com/users/antimatter15, http://antimatter15.com/wp/, https://twitter.com/antimatter15):
/*
It's April 16, 2014.
It's been six months since I started this project.
Just under two years after I first came up with the idea.
It's weird to think of time as something that happens,
to think of code as something that evolves. And it may
be obvious to recognize that code is not organic, that
it changes only in discrete steps as dictated by some
intelligence's urging, but coupled with a faulty and
mortal memory, its gradual slopes are indistinguishable
from autonomy.
Hopefully, this project is going to launch soon. It
looks like there's actually a chance that this will
be able to happen.
The proximity of its launch has kind of been my own little
perpetual…
>I would be interested to hear your arguments on how dropping H.264 could increase usage of the <video> element in the long term. I just don't see a case for it.
It's very simple - a significant share of the browser market was never going to support <video> with H.264. In which case you end up with a fragmented market and everybody's using wrappers like Flash anyhow.
Of the available formats, WebM is the one most likely to eventually get everyone on the same page. Without that, <video> never really becomes a standard.
It's been posted elsewhere in the thread several times, but if you have a few minutes, this is probably the single best article I've seen on the whole mess:
http://antimatter15.com/wp/2011/01/the-ambiguity-of-open-and-vp8-vs-h-264/
If MS jumps on board, which wouldn't shock me at all, you've got 90% of the browser market signed on.
By our very own antimatter15[0] who happens to also be 16 years old now. Has also released lots of other cool things for the web like the Ajax Animator[1] and an excellent article[2] on the whole VP8 vs H.264 video wars that clears up a lot of misinformation. His Github[3] is very impressive.
[0]: http://news.ycombinator.com/user?id=antimatter15
[1]: https://chrome.google.com/webstore/detail/ginffkjapdobanedcblllenliboglpkp
[2]: http://antimatter15.com/wp/2011/01/the-ambiguity-of-open-and-vp8-vs-h-264/
[3]: https://github.com/antimatter15
This makes me feel old. I saw it for the first time in 2014 on HN, just when it was announced. I felt kind of envious of Kevin Kwok, author of this project. I had just graduated and he was still an undergrad. He had already shipped so many complex projects, including a full-fledged Flash Animator[1] for the web.
It's pretty surprising to see that his site hasn't been updated since 2015 and not many projects have been shipped since then.
[1]: https://antimatter15.com/project/ajax-animator/
After reading this: http://antimatter15.com/wp/2011/01/the-ambiguity-of-open-and-vp8-vs-h-264/
It sounds like the plugins with be in the OS and not the browser. So it will be like downloading a codec for your Mac or PC not like installing Flash on in your browser.
The big distinction here is that it will be native to the browser because IE and safari use whatever codecs are in the OS instead of providing their own.
You could use a simple client-side JS OCR library, like GOCR.js[0]. It may only work on good photos of relatively new tires with clearly printed text, and that's not always what bicycle tires look like when you're looking to replace it, so not sure how useful it'd be.
[0]: https://antimatter15.com/gocr.js/demo.html