> I'd also understand if shotwell's aim > was to be an iPhoto class app and > something like Aperture was beyond > its aim. Is there any stated long-term > philosophy on this?
Shotwell was originally conceived as an iPhoto-class, consumer-level photo manager. That said, we are acutely aware of the fact that there is no easy-to-use pro- or even pro-sumer-level photo manager on the GNOME desktop today. Over the long term, we'd definitely like to address the needs of these users, but once again, it's a question of resources. As far as philosophy on the future of Shotwell, check out the Shotwell Roadmap here: http://trac.yorba.org/wiki/Shotwell/Roadmap. Clearly, there are some features in the roadmap that target principally the pro and pro-sumer space, namely "GEGL or other floating-point photo pipeline." Cheers, Lucas On Mon, May 30, 2011 at 5:50 PM, Pedro Côrte-Real <[email protected]> wrote: > Hi Lucas, > > Thanks for the reply. Some comments below. > > On Mon, May 30, 2011 at 3:54 PM, Lucas Beeler <[email protected]> wrote: >> That said, loading and decoding RAW files is an expensive operation. >> You can see this yourself by running Shotwell with the >> --no-mimicked-images command-line option. When this option is set, >> Shotwell ignores mimcs and instead loads and decodes the full RAW file >> when you open the photo. >> Setting this option makes Shotwell much less >> responsive. Since one of the things we value in Shotwell is its speed, >> we want JPEGs available for each RAW photo so that we can display it >> quickly. The only way to do get this JPEG data -- short of >> implementing RAW development in Shotwell itself -- is to either create >> a JPEG when a RAW photo is imported (i.e., to create a mimic) or to >> use the JPEG data embedded in the RAW file itself. > > It is indeed expensive to decode RAW files. My experience with f-spot > is that it is fast enough for reasonable usage and that is using dcraw > through a pipe. I understand that shotwell aims for a higher level of > responsiveness. rawspeed and decoding raws at half of quarter > resolution could potentially solve this kind of problem. I'll try to > do some experiments to validate this. If something like rawspeed or > libopenraw were faster would that be enough or do you mean something > else with "short of implementing RAW development in Shotwell itself"? > >> Like you, we would love to have fully parameterizable RAW to JPEG >> conversion inside Shotwell itself. But this would be a big feature to >> implement. For example, we'd have to come up with a UI for >> manipulating conversion curves through sliders, dials, etc. Alas, our >> development resources are limited so we can't implement every feature >> we'd like to (but hey, if you're a developer and want to give it a >> shot, patches are gladly accepted!). So for right now, we have to pick >> some "substandard defaults" to use when we convert RAW photos to JPEGs >> inside of Shotwell. As you've said, our defaults aren't perfect, but >> the curves and white-balance parameters we use tend to give good >> results for most photos shot in well-lit rooms or in daylight. Of >> course, if you're shooting in low-light or otherwise working at the >> extremes of the dynamic range, Shotwell's defaults will not give you >> the best results and you're better off developing the RAW image >> yourself in ufraw. > > Let me just clarify that I'm far from a professional photographer. I'm > on the side of the least sophisticated user of RAW files. And that's > important because I'd argue that anyone that wants to use RAW files > will need more than the fixed conversion shotwell is doing. Because > the fixed conversion will tend to be of lower quality than the JPEG > the camera would produce instead, so it tends to only be worth it to > shoot RAW if you're going to fiddle with the conversion. > > So from a user standpoint I only see two possible solutions for a > program like shotwell: > > - Decide it's not in the RAW handling business and just allow calling > external apps (like ufraw) to do a conversion and store it as a > version. (be an iPhoto) This is what f-spot currently does and was > hoping to move away from. > - Actually implement the RAW conversion itself (be an Aperture) > > Now, that doesn't mean mimics can't still be useful if they end up > being needed to do fast display. I'd expect though, that RAW display > can be made fast enough. > >> I hope this makes clear why we did some of the things we did in >> implementing RAW support in Shotwell. Like you, we'd love to have much >> fuller, richer RAW support, including parameterizable conversion. We >> just don't have the resources to make this happen in the next release >> or two. > > I was just making sure I wrote down a full user report from someone > that does use RAW and has tried the alternatives. I understand these > things take time and resources and shotwell has gotten very far in a > short time. I'd also understand if shotwell's aim was to be an iPhoto > class app and something like Aperture was beyond its aim. Is there any > stated long-term philosophy on this? > > Thanks for the great work, > > Pedro > _______________________________________________ Shotwell mailing list [email protected] http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
