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
