In-browser RAW Processing: How We Did It

http://blog.pics.io/sneak-peeks/in-browser-raw-processing-how-we-did-it

by Come-rad • 12 years ago

74 30 12 years ago

blog.pics.io

pedrocr2• 12 years ago

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-rad5• 12 years ago

Hi, I'm part of the team. In that case we would get a "black box". We need full control over the process.

yetithefoot10• 12 years ago

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.

jwise0• 12 years ago

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!

yetithefoot10• 12 years ago

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.

e12e3• 12 years ago

Any plan to support Sony ARW?

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+?

Come-rad5• 12 years ago

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.

e12e3• 12 years ago

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...?)?

bri3d2• 12 years ago

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.

frik2• 12 years ago

It would be interesting how big the libraw asm.js file is. One downside is usually that it gets quite big.

bri3d2• 12 years ago

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.

yetithefoot10• 12 years ago

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.

nobodysfool• 12 years ago

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

Come-rad5• 12 years ago

Loads for me. Don't see spam links. Can send you over the post in Pocket. What's your email?

frik2• 12 years ago

  raw.pics.io doesn't support your browser

IE 11 supports WebGL (and is a pretty decent HTML5 browser)

yetithefoot10• 12 years ago

The problem is not only with WebGL. Unfortunately we don't support it yet, but working hard on it.

Come-rad5• 12 years ago

Hey, hackers. Here's the first picture from the post in higher resolution – http://blog.pics.io/wp-content/uploads/2014/05/8bd2a4633b08b...

In case some of you want to put it as a desktop wallpaper :)

yetithefoot10• 12 years ago

Images like this are created due to bug in our JPG decompression algorithm — I like this one and put it as a post title photo. =))

TheAnimus• 12 years ago

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.

yetithefoot10• 12 years ago

We love DNG and I personally always recommend it. Unfortunately there are lot of manufacturers doesn't support DNG, thats why we support CR2/NEF.

dharma1• 12 years ago

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?

yetithefoot10• 12 years ago

If you talking about lossless DNG compression — yes we support it. If you talking about lossy DNG compression — no.

We already added Exposure Compensation to http://raw.pics.io, and we think about upcoming features. What features are the most useful for you?

In-browser RAW Processing: How We Did It

Related Stories