If I were to need RAW processing in the browser I'd probably have compiled libraw using emscripten.
It's pretty easy ( http://blog.bitops.com/blog/2013/06/04/webraw-asmjs/ ) and provides a proven set of demosiacing algorithms that work well, in addition to support for a lot more cameras (Sony springs to mind).
At any rate this looks like it was a quite fun exercise, and the blog post is well written.
We also played with dcraw running on asm.js.
It actually a blackbox with no control. Our current implementation is more fast because uses platform specific optimisations code. I personally spend alot of time optimising it for running in JavaScript.
In the demo blog post I linked, it looks like libraw is around 3MB, but that the blogger who wrote that post didn't pay much attention to eliminating cruft and the script is additionally not minified. Minified and compressed it's under 450k.
http://dev.tag.is/rawson.js/ seems to be an emscripten-to-JS compiled dcraw.c, and while less functional than libraw it's under 500kb.
Any idea why they didn't go with an emscripten compile of libraw or rawspeed? These formats are well understood by now. libraw (dcraw based) can convert practically any format in existence.
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.
Would be interesting to hear what their demosaic algorithms look like. Being gflops-limited means that a lot of the image signal processing algorithms need to be dramatically simplified in some regards, but having large memory buffers that they can work in gives them a wide berth to implement more complex algorithms in other ways.
The libraw / dcraw-based demosaic algorithms are, I am told, very good; it'd be interesting to compare the image quality that they get (if they reinvented the wheel) vs. libraw, vs. the camera's on-board ISP.
Either way, having an in-browser RAW experimentation platform could be a very interesting tool; even if for nothing else, using it for education could be very neat. Good work!
Before start, we investigated and learned tons of theory and alot of libs.
Rawspeed is my personal best and we compared our results with it.
Now in raw.pics.io we implement simple bicubic interpolation algorithm which optimal in speed/quality. Sure, we think about AHD, gradient and other algos, but we should deal with performance first.
Am I understanding this right, the conversion is done in the browser, so rather than using something like dcraw that's quick and featureful and exist, you've reimplemented the whole thing in js? (I do get that it's a trade-off concerning what you want to enable). Do you see this as viable for use on tablets and such? Today's tablets, or are you targeting the tablets of, say, 2015+?
Sony holds a good share, so, yes, we'll take it into work. But for now our priority is speeding up. We just started optimising and already reduced processing time by 50%. But that isn't enough, obviously.
You are correct about our approach (I'm referring to dcraw here).
>Do you see this as viable for use on tablets and such?
It's a question of hardware, most of the things we build can run in browsers on tablets (in theory). We actually don't see much benefit in editing on a tablet. But iPad can be a good device for photo management and sharing.
Hm, if I can't edit where I happen to be (I need my laptop/workstation) -- what's the benefit of editing in the browser vs just using an application and some form of cloud sync (actually, as editing is local in the browser, there is no "sync" needed for feature parity, as one could just "automagically" download on demand and/or upload on save/use davfs...?)?
>just using an application and some form of cloud sync
Setups like this usually suck. These workflows are hard to maintain, especially by not so tech-clever photographers.
>what's the benefit of editing in the browser
You mean from a user perspective? Then "no installation", freedom choosing platform, collaborative editing, etc.
If we talk in a greater perspective... Web version of software for RAW processing can be easily integrated into any web service: Google+, Dropbox...
>just using an application and some form of cloud sync
>> Setups like this usually suck. These workflows are hard to maintain, especially by not so tech-clever photographers.
Maybe. Then again, I don't really see the need for syncing going away in the near future -- it's still hard to "just upload" the result of a single photo session/trip/whatever? Even if you're great at deleting obviously bad shots, it's pretty hard to keep the number of photos below the low hundreds (ie: 2+ GB of raws)?
I suppose some will prefer to synch up once, then have "the cloud" maintain the working set of images (as bad ones are deleted, cropped/edited/black'n'white copies are created). Does sound like a lot of data going up and down though.
>> what's the benefit of editing in the browser
> You mean from a user perspective?
> Then "no installation", freedom choosing platform,
Fair enough -- I see how this can be a benefit -- it also highlights how much more comfortable my life has become after I gave up on dualbooting and just stuck with Debian as my main desktop/workstation setup. But that might not be for everyone.
>> collaborative editing, etc.
Do you plan on supporting some form of non-destructive editing, where changes can be easily propagated?
>> If we talk in a greater perspective... Web version of software for RAW processing can be easily integrated into any web service: Google+, Dropbox...
I'd like to see that :-) I still think there's a bandwidth problem though -- I have problems managing my RAWs locally, I can't imagine it will work (yet) with the actual image data only in the cloud -- and I'm not sure if caching gigabytes of data on the client is an acceptable solution (mostly because of poor uis for controlling the cache, purging parts etc).
Really interesting that you put so much emphasis on the proprietary formats.
As a Pentax (K-5, K-5II, K-3) and Nokia (Lumia 1020) user, I use nothing but DNG. Sure I could squeeze a few more bytes from a memory card with PEF, but I prefer my records to be in a standardised format.
Is their site seriously broken or what? I keep getting no images loading and scrolling to the bottom I get a ton of links to handbags and purses, shoes and fake oakleys
think this is really cool. Do you support compressed DNG? I used that a lot when moving raw files across the internet, comes out a lot smaller while still retaining 12bit raw
The next part - processing the debayered pic on the browser. I like ACR a lot, the highlight recovery is the best I've seen.. plans?
It's pretty easy ( http://blog.bitops.com/blog/2013/06/04/webraw-asmjs/ ) and provides a proven set of demosiacing algorithms that work well, in addition to support for a lot more cameras (Sony springs to mind).
At any rate this looks like it was a quite fun exercise, and the blog post is well written.