Hi, 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. So why not just take the embedded JPEG? Sure programs like lightroom, darktable, ratherapee have to display the the correct image but Shotwell in my understanding not. At least display the JPEG for the time the RAW is been demosaiced.
More remarks: My Canon 500d hast embedded low and high resolution JPEGs which are sufficient. And even if there are no embedded JPEGs, maybe there are already developed JPEGs. Just take this. To use 15Gig of space just for previews is a little bit too much. Lightroom only uses 3.5. And Shotwell starts eats a lot of performance after startup for generating the previews. And to store all the previews in one folder is not consistend since Cameras tend to start counting the pictured from the start after reaching a limit. 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. Steffen Am Montag, den 16.08.2010, 11:25 -0700 schrieb Jim Nelson: > There is at least one more issue here. > > The JPEG thumbnails generated by the camera may not match the output > of the RAW file as it emerges from the libraw pipeline. Many cameras > will adjust the JPEG files it generates (whitepoint, contrast > expansion, etc.) in their own way. Other cameras (esp. > point-and-shoot RAW cameras) have barrel distortion that's corrected > in software. (Shotwell can't correct this at this time.) If we > relied on the JPEG thumbnail as the baseline image, all adjustments > you made would be against that image. Then, when you exported the RAW > photo, we would run those color adjustments against the RAW output and > not the JPEG, and you'd get different results -- sometimes drastic > differences. > > In other words, you'd be editing a post-processed JPEG and applying > those transformations to a pre-processed RAW file. The mimics, > however, are the pre-processed RAW files stored in a format more > conducive to interactive editing, which is why we generate them. > > -- Jim > > On Mon, Aug 16, 2010 at 8:07 AM, Adam Dingle <[email protected]> wrote: > On 08/15/2010 10:25 PM, stesind wrote: > > Hi, > > > > Asap as I start latest svn shotwell it starts to create > JPEGs in the > > mimics folder. Each of them has a size of 2-3MByte. This is > nearly the > > size of delevoped JPEGs. In my libary are a lot of CR2s. > Every time > > shotwell eats a lot of my system performance. The mimics > folder has a > > size of 15GByte. Why is it creating this files? I think it > is totally > > useless since JPEGs are stored in the CR2 Raws. They should > be used. > > > > > stesind, > > First of all, note that it can be *very* slow to generate a > display > image from a RAW photo - it can take several seconds, which is > an > unacceptable amount of time for opening a photo. So Shotwell > needs to > have a full-size JPEG available for each photo in the > library. This is > why it generates the mimic JPEGs. > > Now, we agree that it would be nice if Shotwell could use a > JPEG > embedded in a RAW file rather than generating its own JPEG > mimic - this > is http://trac.yorba.org/ticket/1771 . But not all RAW files > contain > embedded JPEGs which are large enough for all editing needs, > and so even > after we implement this capability the user will be able to > turn it on > and off. For example, CR2 photos from my Canon S90 camera > contain > embedded JPEGs which are 1600x1200 (to see the sizes for your > camera, > run 'exiv2 -p p foo.cr2' on one of your photos). My monitor > is > 1920x1080, so it would probably be reasonable to use these > embedded > JPEGs for displaying photos in Shotwell as long as I never > need to zoom > into a photo. But, still, this should be a user option. If > the user > enables the use of embedded JPEGs, then Shotwell will not > generate the > mimic JPEGs, but if you try to zoom into a resolution larger > than the > embedded JPEG then Shotwell will have to display a blurry > photo (at > least for several seconds; perhaps it could render the RAW > image in the > background and then update the display). > > adam > > > _______________________________________________ > 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
