Very good points. If only my Lightroom could notice my fading interest and could say "Hey, pal. Grab your ass off the couch and go shoot a cityscape (you've enjoyed them). I'm challenging 5 other guys like you to make the same." and then show our photos each other.
There's a few "weekend/topic challenge" groups/hashtags on Instagram and, if I recall correctly, there's a few iOS apps which are similarly "here's a theme, take photos, submit them" based.
Developing and printing, yes. But the photography is so much easier. You do have film changes though, with digital you have endless film. But I used to enjoy photography for its own sake when doing it on film and digitally it is more of a documentation tool for me.
For some reason I always seem to 'miss the moment' with digital and with film that rarely if ever happened.
Digital is all about convenience after you've pressed the shutter button.
Shooting digital is MANY more times complicated and cumbersome than shooting film - this is a common misconception of those who have never shot film. It's infinitely more simple and "zen-like".
Actually my problem is not necessarily with the size, but more with the just reaching over and using a mouse. With the pen you either put it in the base or you leave it laying there. If I am working coding or something where I use the mouse rarely having to reach, pickup, use is more time consuming and frustrating to me. With a traditional mouse it is more natural just to move my hand to the right, use the mouse, and go back to typing away.
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).
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.
