Skip navigation
LanceBenedict
Currently Being Moderated

Rendering issue in Develop Module

Oct 20, 2013 3:33 PM

Slow rendering has been discussed in many threads, but can anyone explain what is going on with this specific issue I am having?

 

If I am working in the Develop Module and I render two raw files at 1:1, after the initial rendering delay I can generally toggle between the two and they are rendered almost instantaneously.   I assume this is because some info has been stored in the ACR Cache and Lightroom can quickly display them.  Now if I render a 3rd raw file at 1:1 and try to toggle between 3 images, one of them always needs 10 seconds or so to load/render.  What is happening here?  I thought the purpose of the ACR Cache was to allow for fast rendering of previously rendered images.  I currently have my ACR Cache set to 10GB and I have recently purged it, so I am nowhere near the limit.  Other system/software specs as follows:

 

LR 5.2

NEF files from Nikon D7100 (approx 30MB)

iMac 27-inch 2560x1440

OS 10.8.5

Processor:  3.06 GHz Intel Core 2 Duo

RAM:  16GB

Video Card:  ATI Radeon HD 4670 (256MB)

Storage:  1TB SATA 7200rpm, 25% full

 
Replies
  • Currently Being Moderated
    Oct 21, 2013 2:07 AM   in reply to LanceBenedict

    Rendering 1:1 previews has minimal impact on performance in the Develop module, their primary use is when zooming to 1:1 in the Library module. However, a by-product of rendering standard or 1:1 previews is that the ACR cache entry will be created for those images (if it doesn't already exist).

     

    Having said that, if we look at your issue is has little to do with the ACR cache entries.....these are used to give you a preliminary view of the image, which should activate the sliders and allow you to start work, whilst the full image is read and converted in background and when that's done the new editable preview that has been created will replace the first view that you saw. You may not notice that change, often the only awareness that you might have that the image is still being converted will be the "Loading" indicator (which you can turn off if it's distracting).

     

    The converted editable preview is cached, presumably in system RAM.....but the kicker is that it seems as though only two images are retained in that cache (which is not related in any way to the ACR Cache), i.e. the current image and the last used image. Hence, once fully loaded, you will have almost instant loading when moving back and forth between the two images, but as soon as you move to a 3rd image one of the previous 2 is removed from the system cache to make way for that 3rd image. Go back to that image again and it will have to be converted all over again.

     

    I don't know why that apparent limit of only 2 cached images in Develop exists, it would be great to see it increased if possible.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 21, 2013 2:16 AM   in reply to Jim Wilde

    "Negative" (RAM) cache size used to be 4 - dunno when that changed.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 21, 2013 2:25 AM   in reply to LanceBenedict

    ACR cache may have provided more noticeable performance improvement a decade ago (dunno), but these days it's affect is almost negligible, at least in my very non-scientific tests.

     

    Consider using smart previews - you should get better performance that way. The ACR cache isn't used when you have smart previews.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 21, 2013 2:33 AM   in reply to Rob Cole

    Rob Cole wrote:

     

    ACR cache may have provided more noticeable performance improvement a decade ago (dunno), but these days it's affect is almost negligible, at least in my very non-scientific tests.

     

    Agreed...."back in the day" (aka Lightroom 2) the ACR Caches entries for my 25-30mb files were more than 17mb each! Since LR3 they're usually less than 1mb.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 21, 2013 2:34 AM   in reply to Rob Cole

    Rob Cole wrote:

     

    "Negative" (RAM) cache size used to be 4 - dunno when that changed.

     

    It may vary, I don't really know. All I can say is that on my system it's definitely only 2.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 21, 2013 3:00 AM   in reply to Jim Wilde

    It's 4 for me in Lr3 (I just now checked), 2 in Lr5 (same machine) - I didn't check Lr2 or Lr4.

     

    How to check: if you can flip back and forth between the same X images, in develop module, very quickly, but not X+1 images, then the size of the "Negative" (RAM) cache is X. Note - it has nothing to do with ACR cache - it's in ram, not on disk.

     

    And it can be disabled completely by putting a file named config.lua in Lightroom app data folder (e.g. C:\Users\{username}\AppData\Roaming\Adobe\Lightroom) with this in it (or at least such was true in Lr3):

     

    -------------------------------------------

    AgNegativeCache.enabled = false -- false kills the ram caching of recently visited images in dev module.

    -------------------------------------------

     

    This used to actually fix some abnormal performance issues (not many though).

     

    Rob

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 21, 2013 9:57 AM   in reply to LanceBenedict

    LanceBenedict wrote:

     

    Thanks for the explanation on the RAM caching.  If I am understanding you correctly on the ACR Cache, it sounds like it is essentially useless once you have applied some editing to the image because you need to wait on those edits to be rendered. 

    No, I wouldn't agree that it's useless. When you load an image into Develop you'll be presented first with a brief view of your Library preview, which should quickly be replaced with the ACR Cache "scene-referred" preview that will have any existsing edits applied before you see it. That should all happen quite quickly, and when that preview is loaded the sliders will be activated. When that happens you can start work, even though the full file is being rendered in background, and there is no need to wait until the "Loading" indicator goes out (as I said earlier, you can turn that off if you prefer).

     

    So the benefit of the ACR Cache entry is that it allows you to start work in Develop whilst the original file is still being fully converted.

     

    Note that although we are talking specifically about the ACR Cache entry, the same holds true for DNG Fast Load Data and/or Smart Previews. Which one of those 3 is initially used depends on what exists at the time of loading, and what file type is being used. But the same principle applies to all three.

     

    In terms of reducing the rendering time, that's a more problematical issue as there are various factors in the pipeline which come into play, any one (or more) of which may be sub-optimal. These factors include:

     

    1. Size of the files being loaded. It should go without saying that 36mp files from a Nikon 800 are going to take quite a bit longer that the 10mp files from say a Canon 40D.

    2. Location of the files and speed of the interface, i.e. expect image files on a USB2 connected hard drive spinning at 5400rpm to be a lot slower to load than if they were on a 7200rpm drive internally connected on a 6gb/s Sata hub.

    3. Once the data has been read, how fast is the CPU.....rendering a raw file will be quite a CPU-intensive task, so the faster the processor the better.

    4. User expectation.....one man's "painfully slow" could be another's "quite acceptable".

     

    With that in mind, I have no idea if what you are experiencing is "typical" or too slow. Putting it into context, all my original files are on a fast internal drive on a 3gb/s connection, I have an i7-930 quad-core processor (now over 3 years old, so not leading edge by any means), 12gb of RAM. Full loading times in Develop are now about 3 seconds per image when using 22mp files from a Canon 5D3.

     

    Looking at the things you've tried, purging the ACR Cache and increasing its size would have no effect unless:

     

    a) There was a problem with the existing cache, and

    b) You regenerated new cache entries

     

    Discarding old previews and rebuilding would have had no effect on Develop loading times, nor would downsizing the dimensions of the develop window.

     

    Increasing system RAM should certainly be beneficial to other areas of Lightroom, I'm just not sure it would have a specific benefit to image loading into Develop. That might be dependant upon what else was running in the system at the time.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 21, 2013 2:32 PM   in reply to LanceBenedict

    Lance,

     

    For optimal performance in develop module, you need:

     

    1. Fast CPU, multiple cores (primarily).

    2. Fast (and separate) disks for system, catalog, and photos (secondarily).

    0. Sufficient RAM (excess ram won't help).

    3. Lr operating smoothly (normally).

     

    If you don't have 3, then 1 & 2 won't matter much.

    If you do have 3, then there are limits to how much 1 & 2 will help (once there's enough CPU to go around, and disk reading time is no longer much of an issue, the other mystery bottle-necks kick in - only those with in-depth modern computer architecture can understand - not me).

     

    That said, 10 seconds is too long. Most of us experience raw load times of 2-7 seconds or so, depending on resolution (pixel count), extent of editing, and computer power.

     

    So either:

    A. Your system is underpowered.

    B. Lr not operating smoothly.

     

    I'm not sure which in your case, but definitely check that all cores are engaged at a relatively uniform and fairly high percent utilization.

     

    As Jim said, you may be happier if you turn off the loading indicator and start editing as soon as sliders will allow.

     

    Over n' above what's already been mentioned, the only way to speed up substantially more is to export a tif or jpg (after initial tone and detail settings have been applied...) and start editing that instead. ProxyEditor will retrofit changes to tif or jpg back to the raw if you want, but since the changes won't translate 100%, it's usefulness is limited.

     

    PS - Adobe went from 4 to 2 for ram cache, probably because of code changes, and not to conserve ram. Probably another re-write will be needed before we see that number go up again - just guessing. Note: ram cache is a Lightroom thing, but ACR code is also used in Photoshop plugin, so there is a bit of a hurdle there.

     

    Rob

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 21, 2013 3:54 PM   in reply to Rob Cole

    My LR5.2 Develop 1:1 render time for 21 Mp raw files is about 4.5 sec. with an i7-860 quad core PassMark score of 5,102.

     

    The OP's 3.06 GHz Intel Core 2 Duo has a Passmark score of 2,007 to 2,374 (he doesn't tell us the specific CPU model) and processing 24 Mp Nikon D7100 raw files.

     

    Using my system as a comparison the OP's best-case rendering time works out to about 9.6 sec, which is pretty close to the 10 sec. he mentioned.

     

    Processor Performance = (5102-2374) ÷ 5102 = .535

    Image Size = 24 ÷ 21 = 1.143

    Calculated Render Time = 1/.535 x 1.143 x 4.5 sec. = 9.6 sec.

     

    I checked LR4.4.1 and it Caches three (3) 1:1 Develop previews, so we have:

     

    Develop Module 1:1 Preview Cache

    LR3 = 4

    LR4 = 3

    LR5 = 2

     

    If I have a bunch of images I need to review at 1:1 I use the Library module and make sure the 1:1 previews have already been built. For processing in the Develop module I work on one-image-at-a-time using the top-down workflow from Basic down to Detail. For a similar group of images all shot at the same ISO, lighting and exposure I'l Sync WB, NR, and Sharpening, and perhaps some others, so very little time involved.....

     

    It's funny (or not so funny) because working this way the 1:1 Develop preview building time has never bothered me. Maybe I process my image files differently than others?

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 21, 2013 4:08 PM   in reply to Todd-Russell

    Thanks for filling in Todd.

     

    So I guess Lr6 cache size will be 1?

     

    Also, Quick Develop (or a relative editing plugin like Gazoo) may help reduce the number of loads in Develop module.

     

    Rob

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 22, 2013 7:08 AM   in reply to LanceBenedict

    LanceBenedict wrote:

     

    If I have say 10 photos of the same bird, I do an initial selection with library previews, but often feel compelled to carry perhaps 4 of them though editing in the develop module.  Then after editing I find myself toggling amongst the 4 looking at minute differences at 1:1 trying to determine the best of the bunch.

    Regardless of the system being used 1:1 image reviews in the Develop module will always have some lag,

     

    Suggestion:

    If the four bird images are very similar (same ISO, lighting and exposure accuracy) try adjusting the first image and Sync the Develop settings across the rest. Then review all four images at 'Fit' view for tonal balance. Generally you will only need to "tweak" the Exposure on any images that look lighter or darker. After processing all of your  images select them in the Library module and then go to Library> Previews> Render 1:1 Previews. While the previews are being built you can continue to work in the Library or Develop module, at least I can with my i7-860 system.

     

    After the preview building has completed you can review all of your processed images (not just the four) at 1:1 view with no lag. If you find a group of images that needs "fine-tuning" of NR, Sharpening, or other settings, repeat the process in the first paragraph on these images.

     

    The only time you should need to use 1:1 view is for adjusting the 'Sharpening' and 'Noise Reduction' controls. For just about everything else you can use 'Full-Screen" mode in the Library module and use the film strip or arrow keys to step through the images for review.

     

    Tip:

    To get the most accurate image view in LR or PS do not use 'Fit' or 'Fit On Screen' views. Instead select a view size of 1:8 (12.5%), 1:4 (25%), 1:2 (50%), and yes even 1:1 (100%), which is the only truly 100% accurate view. Just remember to do this in the Library module to avoid the preview building lag. This affects the image's onscreen sharpness–For judging composition, tonality and color in the image Fit and Fill views are fine.

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points