Live data from Hacker News

Show HN: Polarr.co, a WebGL photo editor

polarr.co

91–100 of 100 posts

Re: Show HN: Polarr.co, a WebGL photo editor

#91
post #41

I hate to shit on your parade because this is pretty dope, but the title is disingenuous at best. But I use Lightroom every day, and you might be faster but you aren't working at the same level of quality. I loaded up a 16-bit TIFF and got an 8-bit JPEG as a result, which leads me to assume that you are downsampling to 8-bit to work. Also, the results in polarr are way harsher then Lightroom, which is pretty common f…

Unlike some other fortunate users who reached the editor, I never did: http://tuxdiary.com/2014/10/28/polarr/

Re: Show HN: Polarr.co, a WebGL photo editor

#93
post #48

Earlier quoted context omitted.

with WebGL?

WebGL textures suffer from the same problem as shaders can be used to extract data. WebGL is hence using CORS as well. Do you say the performance penalty in WebGL is non-existing contrary to canvas?

what data do you want to extract?, all postprocessing effects are made with GLSL shaders, you don't process data with javascript algorithms.

Re: Show HN: Polarr.co, a WebGL photo editor

#94
post #35
post #30

Earlier quoted context omitted.

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.

Re: Show HN: Polarr.co, a WebGL photo editor

#95
post #40
post #21

Earlier quoted context omitted.

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.

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.

Re: Show HN: Polarr.co, a WebGL photo editor

#96
post #48

Earlier quoted context omitted.

WebGL textures suffer from the same problem as shaders can be used to extract data. WebGL is hence using CORS as well. Do you say the performance penalty in WebGL is non-existing contrary to canvas?

what data do you want to extract?, all postprocessing effects are made with GLSL shaders, you don't process data with javascript algorithms.

Just the call on getImageData to extract texture and read all pixels from an image can take 15s if CORS is in the play...

Re: Show HN: Polarr.co, a WebGL photo editor

#97
post #96

Earlier quoted context omitted.

what data do you want to extract?, all postprocessing effects are made with GLSL shaders, you don't process data with javascript algorithms.

Just the call on getImageData to extract texture and read all pixels from an image can take 15s if CORS is in the play...

you don't call getImageData to extract a texture data. You load the image, make a texture of it, and then apply all postprocessing effects with a WebGL shader.

Re: Show HN: Polarr.co, a WebGL photo editor

#98
post #96

Earlier quoted context omitted.

Just the call on getImageData to extract texture and read all pixels from an image can take 15s if CORS is in the play...

you don't call getImageData to extract a texture data. You load the image, make a texture of it, and then apply all postprocessing effects with a WebGL shader.

OK, thanks for the hint! I'll try to play with CORSed image texture binding to see what the performance is.

Re: Show HN: Polarr.co, a WebGL photo editor

#99
post #74

This is an awesome idea. I think what people might be missing is that even with the features you currently have, there's a market for this application already, though maybe not as a stand-alone lightroom replacement. If you think about batching, my brain immediately starts gravitating towards real estate, headshots, HS seniors photos, ENG. In short: drop the filters, put the "basic" controls on the left, focus on wha…

Make sure you signup so that you can receive our mailing list, we're building a basic "editor-less" mode for Polarr right now.

Will do - but I suppose a "filter-less" version might be what I was leaning toward, as a potential user.

Re: Show HN: Polarr.co, a WebGL photo editor

#100
post #91
post #41

I hate to shit on your parade because this is pretty dope, but the title is disingenuous at best. But I use Lightroom every day, and you might be faster but you aren't working at the same level of quality. I loaded up a 16-bit TIFF and got an 8-bit JPEG as a result, which leads me to assume that you are downsampling to 8-bit to work. Also, the results in polarr are way harsher then Lightroom, which is pretty common f…

Unlike some other fortunate users who reached the editor, I never did: http://tuxdiary.com/2014/10/28/polarr/

I did re-visit after a rather harsh review because of the loading issues and I am pleased with what Polarr has to offer. The review is updated now! :)
Post reply on HN