Come-rad is right — emscriptened code is not very maintainable, so we cant rely on it.
More than that we use alot of JS-specific performance optimisations that allows us to run faster than any of those autogenerated libs.
Interesting. If you're worried about correctness I'd just do integration testing. Get a bunch of raw files from different manufacturers and test them with rawspeed on the desktop and on the browser, comparing output. If it's performance though it seems strange when there are 3D engines being ported to asm.js that something like rawspeed wouldn't optimize well.
The alternative seems a little crazy to me. Reimplementing a full raw library in JS is a huge task. I've just spent a total of 6-7 hours getting the basics of MRW support in rawspeed and those formats are just insane, and change continuously between models of the same manufacturer. And even within a single model you'll get crazy variations depending on camera settings.
AFAIK these 3D-engines was specially prepared to be ported to JS. We have abit another specific than just moving 3D objects, creating scenes and blend textures.
Sure, its very similar, but our "textures" is bigger and we should know about more than one pixel per time to do correct demosaic process. Its not the same to create cool WebGL 3D effect and do JPG decompression for example.
If the emscriptened code does the right thing, then its output is object code, no more in need of by-hand maintenance than the object code from a compiler, right?
Anyway, I'd be interested to see how much faster you are (at comparable image quality) than one of the suggested libraries. If you are in fact a lot faster, I'd be curious to know what it is that you're doing that you think makes it run significantly faster in current JavaScript engines than translated code.
