Hi, Please keep in mind that after importing just a few thousand RAWs shotwell creates for hours the previews and it costs me 15Gig! During that time shotwell is quite slow and the system as well. This could be a no go for new users coming from other programs. Furthermore to keep all previews in one folder is not working at all. Because of repeating file names over the time or from different cameras.
But even more important is this point: One cannot develop RAW files in Shotwell. This must be done in external programs like RawTherapee, UFRaw, ... All adjustments are done there and so the only fitting/correct JPEG is created there! This JPEG should be taken as preview file. For that shotwell must recognise versions of images during import (or later during sync). If I'm not mistaken version file information is also written in .xmf sidekick files. I think shotwell does not keep versions of files yet but since it is able to recognise duplicate images this is quite easy to implement. Just present in the db the Raw file but display the JPEG. Steffen Am Dienstag, den 17.08.2010, 08:57 +0200 schrieb Sebastian Spaeth: > On Tue, 17 Aug 2010 01:01:40 +0200, stesind <[email protected]> wrote: > > > Yes that is right. But for the first preview the embedded JPEG could be > > used. For me at least Shotwell is not an image manipulation program but > > a maintenance program. > > Yes, but still you are able to do simple color correction, rotations and > crops. And if these look different on the embedded JPEG and the RAW file > you have a problem. > > That having said, I would tend to agree that using the embedded JPEGs > for first views and replace that with the properly rendered RAW version > as soon as that is finished should be sufficient. It would mainly hurt > performance if I want to e.g. export a large number of .RAW files but > people wanting to export lots of .raw files to jpgs should be prepared > to take a performance hit :-) (or use LOTS of disk space) > > > So my suggestion is, just keep it simple. Shotwell is a picture viewer > > and not an editor. So performance and not accuracy is the main > > objective. > > I find that shotwell in general takes the simplest approach that works, > which is what they had done here as well (I am not involved in shotwell > development). Any other solution that would save disk space would be > more complex. > > Sebastian > _______________________________________________ > Shotwell mailing list > [email protected] > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell _______________________________________________ Shotwell mailing list [email protected] http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
