3 ms·

Dev of Polarr here. I think the biggest thing that's missing from the current release is RAW image support which is technically difficult to do. We're right no

by bwang29 12y ago

Dev of Polarr here. I think the biggest thing that's missing from the current release is RAW image support which is technically difficult to do. We're right now having some success of extracting the thumbnail of RAW and do it on the client side only using JS, but editing the RAW is a lot harder and we're thinking about using some WebGL texture blending. Any thought/comment on this is welcomed and appreciated. (Not sure how Adobe is implementing their RAW editing) -- The main idea of the company is in fact automated photo retouching https://www.polarr.co/box https://www.polarr.co/box (please use desktop, large videos), and we applied to YC with the idea.

liangx4 12y ago
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
- tachyonbeam 12y ago
  JS numbers are doubles (64-bit floating-point numbers).
zhongjiewu 12y ago
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?
jenius 12y ago
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/ 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.
- alkonaut 12y ago
  > 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/ 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).
twombly 12y ago
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.
- pedrocr 12y ago
  I'd try rawspeed instead of dcraw. Much faster and cleaner code and the latest version supports almost all cameras.
  - bwang29 12y ago
    Thanks! Will try this out!
  - twombly 12y ago
    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.
    - pedrocr 12y ago
      If you want to do raw processing then you don't really care about the thumbnails. No idea about the javascript compile process.
- bwang29 12y ago
  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.
  - pedrocr 12y ago
    >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.
higherpurpose 12y ago
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.
- bwang29 12y ago
  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.
ChrisCinelli 12y ago
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 https://www.polarr.co/box
- alkonaut 12y ago
  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)
  - bwang29 12y ago
    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.
    - alkonaut 12y ago
      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?
JackC 12y ago
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 https://www.google.com/search?q=histogram+lightroom&tbm=isch
- bwang29 12y ago
  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
zz1 12y ago
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 https://github.com/photo/frontend/issues/1400 https://github.com/photo/frontend/issues/1400

by bwang29 12y ago

liangx4 12y ago

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

tachyonbeam 12y ago
JS numbers are doubles (64-bit floating-point numbers).

zhongjiewu 12y ago

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?

jenius 12y ago

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/ 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.

alkonaut 12y ago
> 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/ 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).

twombly 12y ago

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.

pedrocr 12y ago
I'd try rawspeed instead of dcraw. Much faster and cleaner code and the latest version supports almost all cameras.
- bwang29 12y ago
  Thanks! Will try this out!
- twombly 12y ago
  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.
  - pedrocr 12y ago
    If you want to do raw processing then you don't really care about the thumbnails. No idea about the javascript compile process.
bwang29 12y ago
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.
- pedrocr 12y ago
  >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.

higherpurpose 12y ago

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.

bwang29 12y ago
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.

ChrisCinelli 12y ago

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 https://www.polarr.co/box

alkonaut 12y ago
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)
- bwang29 12y ago
  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.
  - alkonaut 12y ago
    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?

JackC 12y ago

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 https://www.google.com/search?q=histogram+lightroom&tbm=isch

bwang29 12y ago
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

zz1 12y ago

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 https://github.com/photo/frontend/issues/1400 https://github.com/photo/frontend/issues/1400