Originally posted by jsherman999 My method (which could be improved, I don't know, not a LR expert) is to generate the 1:1 preview only on images I'm interested in working on, and then only at the moment I decide to work on them, with a simple double-click in the develop module. This generates the 1:1 preview after only about 2 - 4 seconds, and then that preview is cached and used/retrieved immediately from cache each time I preview, for as long as I want it to be or until I change something.
Sort of: 'cache in pieces, on demand' vs. 'cache everything, in batch, even if you don't need it.'
This works for me because on import or shortly after import I'm never sure which images I'm going to be interested in, I only figure that out while browsing
I'm not sure this is what 1:1 preview does ...
1:1 preview creates a full resolution JPG image, with all development settings (like demosaicing, lens profile, sharpening, denoising, clarity etc.) applied. It is like RAW+JPG out of cam, except that LR keeps the JPG in sync.
The JPGs reside in a local directory (sibling to the catalog's "NAME.lrcat" file) named "NAME Previews.lrdata".
The .lrdata directory (which on the Mac is made to look like a file) contains a previews.db file which is a SQLite 3.x database file and can be opened with SQLite which is an open source database (much like the Lightroom .lrcat catalog itself).
Otherwise, the preview directory contains many .lrprev files with cryptic names. They are a stack of JPGs (of varying size) plus a scripting header, all within one binary file. If you ever loose an image, here would be a place to recover it.
In all operations
except DEVELOP and PRINT, it then starts from the preview-JPG rather than the RAW. Which is actually pretty fast and browsing through images to select / discard / categorize etc. is real-time basically.
LR will
not create a 1:1 preview image upon double click on an image. It then only creates a normal preview (at smaller size) which is faster. But can also be done ahead of time via the menu. A 1:1 preview is created if:
- you import an image and told LR to auto-create 1:1 previews upon import
- you view an image at 1:1 (view a 100% crop)
- you mandate 1:1 previews from the menu.
- MISSING LR function: recreate preview after develop touched an image or develop settings changed.
It discards 1:1 previews if:
- they expire after a while (configurable)
- you touch images or open and process them in DEVELOP (which doesn't use the preview at all!)
- you mandate is from the menu.
Therefore, I think, you use the 1:1 preview feature (and
ahead of time before you work with your images actually) in order to find the set of images which are worth a special treatment in DEVELOP. Once you selected images to work with, 1:1 previews aren't really that helpful anymore...
Originally posted by RonHendriks1966 Where is the delay coming from?
The delay is processing. On a machine with 2.66 GHz Core i7 (SSD), creating 100 1:1 previews for K-5 RAWs takes 500 seconds (if using all of lens profile, sharpening, denoising, clarity) and a bit less than 2GB of memory. A single preview (or load into DEVELOP) is the same
5 seconds because Adobe actually did a pretty good job using all four cores for a single image even. With fewer corrections, in can be faster like 3 seconds.
I guess the LR render time is a good benchmark for a machine's DRAM-to-CPU memory bandwidth. Most people do not optimize their machine with respect to this parameter. A good chipset and fast DRAM modules are important here. Macs have a decent chipset but many cheapo notebooks have not despite high advertized clockspeeds.
As I said, this could probably be accelerated by using pipeline parallelization programming skills only very few programmers have. Note however that lens profile application, denoising, fill-light and clarity are non-local operations most programs are pretty slow at.
After all, 5 seconds on 4 2.66 GHz cores are 3000 cycles per pixel.
Originally posted by jsherman999 I'd assume the bulk of the time for 1:1 preview generation is probably in pure CPU cycles during the raw conversion. Falk thinks the raw converter there is suboptimal and not up to par with some others, he may be right.
I did not say others are faster. Bibble 5 "is said" to be faster but that remains to be seen. Bibble could try to approximate pixels for view on screen. DxO for instance only renders all final pixels upon export which is even slower than LR. But DxO's lens softness correction module is more ambitious on the other hand. LR still does a lot to the pixels and e.g., it's denoising is class-leading (i.e., good for a raw converter and faster than dedicated denoisers).
So, there is a balance between speed and quality and I didn't say LR is not up to par with peers in this regard. I actually don't know.
Last edited by falconeye; 09-22-2011 at 03:38 AM.