Have you thought about compiling dcraw to javascript with emscripten? I'm not sure what the performance would be like, but I've seen this work in the past.

I'd try rawspeed instead of dcraw. Much faster and cleaner code and the latest version supports almost all cameras.

rawspeed won't let you extract the thumbnail. Also, the reason I suggested dcraw is because it's one C file and that makes things a lot easier, especially when compiling to javascript.

If you want to do raw processing then you don't really care about the thumbnails. No idea about the javascript compile process.

Thanks! Will try this out!

We tried it. It works with modification to emscripten and compiled code. Performance is acceptable and I think there is a much larger space using GPU to do the decoding as well. But I think the user won't just want to edit the thumbnail though I think many of them didn't know that.

>I think there is a much larger space using GPU to do the decoding as well.

I doubt that very much. Raw processing is very fast these days and I don't think you could make it faster with the GPU given the memory copying overhead. Look at darktable for an example of how the GPU is used intensively for the pipeline but the raw processing is all done by the CPU and is very fast.

Came here just to see about RAW support -- I think that's the only thing stopping this from being a legit competitor to lightroom, which says a lot so nice work guys! One other thing I would miss as well is the ability to auto-correct distortion through the lens profile. This is super quick and easy in lightroom and it auto-detects your lens from the image metadata. This typically reduces the vignette, so the ability to add that back in is nice as well.

On a totally separate note, I feel like you guys are positioned in a spot to solve the photographer storage problem as well, which is detailed remarkably well here: http://paulstamatiou.com/storage-for-photographers/ -- a service like this is something that I know I would pay for and I'm sure it's the same for a number of others.

> On a totally separate note, I feel like you guys are positioned in a spot to solve the photographer storage problem as well, which is detailed remarkably well here: http://paulstamatiou.com/storage-for-photographers/ -- a service like this is something that I know I would pay for and I'm sure it's the same for a number of others.

The workflow feels a bit contrived and the whole problem based only on the cramped space on the SSD disk. I find storing previews on SSD and then the RAW files in the catalog on a huge mechanical drive works perfectly. I can't shoot pics fast enough to cope with the drop in storage cost on mechanical You get 1Tb drives in cereal boxes these days.

Ths library is then just backed with a good backup solution (NB: NOT just a sync provider like DropBox/OneDrive/...). I use crashplan, but you could use BackBlaze or any stand alone backup package to a sync provider. I also sync to my NAS, as per the "store everything in 3 places" theorem.

A problem I would like to solve (well) though is the first part of the article, where he shares pictures with his relatives. Email SUCKS for this. I use zenfolio, but creating galleries just to share a few pics is tedious. I'd like something more integrated with lightroom, and less tedious/crappy than zenfolio (better raw support, simpler/better style support etc).

FWIW the other key feature missing for me is the histogram.[1] Pretty much everything I change in Lightroom, I'm keeping an eye on the histogram to make sure I'm not (unintentionally) blowing things out or losing dynamic range. Being able to drag the histogram itself is a bonus, but being able to see it at all is key.

Oh yeah, and noise reduction. With low-light photos lack of noise reduction is a dealbreaker. Maybe that becomes more important with RAW?

[1] https://www.google.com/search?q=histogram+lightroom&tbm=isch

Thanks for recommending all these features. Viewing / dragging histogram will be in our dev pipeline soon. There are some generic noise reduction algorithms that do not perform very well so we want to implement a few from the recent research papers. this is in our pipeline too.

- Update, we just added the previously hidden de-noise function there, it is not the most efficient but algorithmically correct, hope this helps

Don't know if it may be useful for you, but Trovebox dealt with RAW import, you might want to see what they're doing and if you can take advantage of their work

https://github.com/photo/frontend https://github.com/photo/frontend/issues/1400

Do you use a three level hiearchy on the image? I assume you guys first down sample to full resolution preview(like 600x400) and a low resolution preview. When editing, filter applys on the low resolution preview and then full resolution preview (1.5second latency). When exporting, you apply all the filters on the original image. Is it the case?

The Polarr Editor is great and is a already more useful than Lightroom. What is relly compelling as $1B company is the vision in https://www.polarr.co/box

The point of using lightroom is Cataloging and RAW photo development. I can't see what's useful since the hyperbole mentions Lightroom. It's a program to develop RAW's (Even the name of the application is a pun on that)

Polarr dev here. we're very interested in bringing raw in the web and if there is a possibility of decoding and editing raw properly, we're either the first to do it or it will become some sort of commodity supported from the browser layer.

Great, a good low-cost feature in the meantime would be useful messages when trying to import unsupported or corrupt files, seems nothing happens now?

How are you going to solve the performance issues if JS's type is only 32 bit? I could see the possibility of mixing multiple JPEGs but extracting that probably takes you a minute in processing

JS numbers are doubles (64-bit floating-point numbers).

Could you make it faster still by compiling to asm.js? I'm not sure how it would apply to you, but I know Mozilla has been bragging about how WebGL games are faster with asm.js.

The code is GPU intensive but not quite CPU intensive so in this scenario I believe no. Certain WebGL games need their engine compiled into JS.