Lightroom 3.2 Release Candidate Available on Adobe Labs

[Tom Hogarty]

This release includes camera support, bug fixes and new features.  Details here:

http://blogs.adobe.com/lightroomjournal/2010/08/lightroom-3-2-and-camera-raw-6-2-available-on-adobe-...

Regards,

Tom Hogarty

Lightroom, Camera Raw and DNG Product Manager

[areohbee]

TK,

Now:

Cached images take about 3 seconds to display in develop mode (accompanied by the "Loading" indicator) - and no new cache entry is written.

Uncached images take about 10 seconds - only one new cache entry written.

Before:

Cached or uncached: ~10 seconds - and a new cache entry was created every time - i.e. switch back and forth between the same 2 images 100 times and there'd be 100 new cache entries.

PS - I have the feeling that moving the cache just "goosed" something somehow - i.e. it wasn't the fix per se, but precipitated the proper behavior somehow. - Just a hunch. Or maybe it was sheer coincidence...   Maybe it was trying to read from one location, but then writing to another, and once it was reading and writing from the same location, all went well...

Are you getting new cache entries written each time or is yours a different problem?

Rob

[TK2142]

Rob, are we using the same software?

I have never seen your "Before" behaviour (my cache files only get written once) but my "Now" behaviour is different from yours.

areohbee wrote:

Now:

Cached images take about 3 seconds to display in develop mode (accompanied by the "Loading" indicator) - and no new cache entry is written.

It takes an initial ~2 seconds to get the initial blurry image replaced by a decent preview. If an image has not received any edits then the "Loading..." indication dissapears after that time.

Depending on the amount of edits done to an image it will take further time for that initial preview to turn into the real rendering with all detail (this best becomes apparant by switching at 1:1 magnification because otherwise, the "fuzzy image" bug will prevent you from seeing the final step in image quality change).

So despite the fact that the cache seems well-behaved on my system (one file per image navigated to in the develop module), I cannot say it helps reducing the image switching time.

You might want to try and see when you'd be ready to start painting with the adjustment brush. Press "K" and switch between images. If you see the brush cursor after 2-3 seconds after switching to an image which received a lot of edits before (go for it, use lots of strokes and spot removal applications) then you are seeing something else than I do.

[areohbee]

TK2142 wrote:

Rob, are we using the same software?

Nope.

Back when I used to write embedded systems which included no 3rd party code of any kind, if the firmware behaved differently on two units then it was a hardware problem (or so the firmware people said - the hardware people still insisted it was a firmware problem...)

But in modern PC systems, no two people are running the same software.

Anyway, it sounds like you have a different problem than I did. Given what I think I know, I would think that the time to load an already cached image should be independent of the number of edits. It sounds like your software thinks it needs to re-render for some reason. Mine always displays sharp image after 2-3 seconds if its cached. That's all I know, I think, and I'm not even sure about that...

Rob

[bob frost]

function(){return A.apply(null,[this].concat($A(arguments)))}

Now:

Cached images take about 3 seconds to display in develop mode (accompanied by the "Loading" indicator) - and no new cache entry is written.

Uncached images take about 10 seconds - only one new cache entry written.

Rob

I'm surprised its taking so long to display your images. I get more or less instant display if the file is cached in the ACR cache (it does flash up 'loading', but its loaded before that goes), while if it is not in the cache it takes about a second. That is for nefs. Big PSDs take a second or two longer to render. That is with an 8800GT card.

Bob Frost

[John_R_Smith]

Bob

What size are your NEFs? (in terms of megapixels)

John

[thokra2]

Unfortunately the annoying bug that has been discussed in http://forums.adobe.com/message/2914148 hasn't been solved in 3.2RC.

But if you follow the thread mentioned above you can see that it seems to be unclear what causes the crashes. 

The German support however has given up to find out what's going wrong.

[bob frost]

John_R_Smith wrote:

Bob

What size are your NEFs? (in terms of megapixels)

John

12 MP

bob F

[john Nall]

Just downloaded (uploaded?) 3.2.  I'm using a 24" iMac, 4 gig ram, etc.  I tried just one 3.0 function that didn't work correctly for me: the brush.  Before, it took seconds to render adjustments I was trying to make.  NOW, with 3.2, the brush doesn't work at all.  I don't even get the funny gunsight cursor, just the normal one.  I've rebooted the program, and the machine, with no effect.  Hmmmm.

[jgblair]

Hi John,

Are you sure you launched LR 3.2RC?  On the Mac, it doesn't "upgrade" LR, it creates a new application.  If you are launching LR from the dock, you should instead, find LR 3.2RC in the Applications folder and launch it directly.

John

John G. Blair Studio

Occidental, CA

[john Nall]

Yes thanks John:  I launched 3.2 from the applications folder.  I think I now have three LR's in my applications folder:  2.7, 3.0 and 3.2.  I wonder where I put LR1?

[jgblair]

Next things to try:

-Set up a new test catalog using copies of some images and see if you still have problems.

-If you do, set up a new user account on your computer (I call mine "Test") and try it.

-Rename your LR 3.2RC and download a new copy from Adobe.  Rinse and repeat tests 1 and 2 above and see if any improvement.

John

John G. Blair Studio

Occidental, CA

[john Nall]

I found a better fix:  be sure a brush is selected (e.g. A, B, or erase)!  So now that I have a brush, I find that it's working much better than 3.0.  Score 1 for the update.

[areohbee]

Hey Bob,

bob frost wrote:

I'm surprised its taking so long to display your images. I get more or less instant display if the file is cached in the ACR cache (it does flash up 'loading', but its loaded before that goes), while if it is not in the cache it takes about a second. That is for nefs.

If its not in the ACR cache, it has to be re-rendered from scratch for the Develop mode - I think, unless the image you're seeing has been borrowed from the Library previews (which sounds like a good idea now that I think about it, but that's certainly not how it is working for me). Its hard to imagine a from-scratch raw rendering being accomplished in only a second. On most machines it takes at least a few if not several seconds, depending on size and edits applied.

Regarding already cached display times - how long does it say "Loading"? I mean, I get "something" displayed right away, its just not a final fully loaded fully rendered one until the "Loading" indicator is extinquished.

Anybody else?

PS - I just re-tested: Develop mode photo switching time does depend on screen size - If itty-bitty its less than a second (pre-cached). At 1920x1200 its a good 2-3 seconds. The develop panels presence doesn't seem to make a noticeable difference.

Rob

[bob frost]

If its not in the ACR cache, it has to be re-rendered from scratch for the Develop mode - I think, unless the image you're seeing has been borrowed from the Library previews (which sounds like a good idea now that I think about it, but that's certainly not how it is working for me). Its hard to imagine a from-scratch raw rendering being accomplished in only a second. On most machines it takes at least a few if not several seconds, depending on size and edits applied.

Regarding already cached display times - how long does it say "Loading"? I mean, I get "something" displayed right away, its just not a final fully loaded fully rendered one until the "Loading" indicator is extinquished.

Anybody else?

PS - I just re-tested: Develop mode photo switching time does depend on screen size - If itty-bitty its less than a second (pre-cached). At 1920x1200 its a good 2-3 seconds. The develop panels presence doesn't seem to make a noticeable difference.

Rob

It's a fairly nippy computer - 7.5 on Win performance. Using twin 1600x1200 21" Eizos and a GTX 460 card (slightly faster than my old 8800GT).

bob F.

[JayS_In_CT]

areohbee wrote:

Hey Bob,

bob frost wrote:

I'm surprised its taking so long to display your images. I get more or less instant display if the file is cached in the ACR cache (it does flash up 'loading', but its loaded before that goes), while if it is not in the cache it takes about a second. That is for nefs.

If its not in the ACR cache, it has to be re-rendered from scratch for the Develop mode - I think, unless the image you're seeing has been borrowed from the Library previews (which sounds like a good idea now that I think about it, but that's certainly not how it is working for me). Its hard to imagine a from-scratch raw rendering being accomplished in only a second. On most machines it takes at least a few if not several seconds, depending on size and edits applied.

Regarding already cached display times - how long does it say "Loading"? I mean, I get "something" displayed right away, its just not a final fully loaded fully rendered one until the "Loading" indicator is extinquished.

Anybody else?

PS - I just re-tested: Develop mode photo switching time does depend on screen size - If itty-bitty its less than a second (pre-cached). At 1920x1200 its a good 2-3 seconds. The develop panels presence doesn't seem to make a noticeable difference.

Rob

Rob,

So in the "I don't know category" ...  I loaded up a group of about 300 7D images last night, to which I had already applied a preset for sharpening.  I went to bed, but left the computer on ..  This morning, I can go from just about any image to any image in about 3 seconds.  I'm running LR 3.2 at 1920x1200 with the Left/Bottom panels in hide mode, picture size set to fit.  The reason I bring this up, is that if I do it shortly after loading the images the screen to screen time is longer.  I just don't know how long and in what priority LR loads the cache (60GB)..

My definition is of "timing" is the time from it appearing on screen to the time it is fully rendered.  Another major difference.  When first loaded, the develop "panel" always seems to look like it is loading as well.  After letting it sit till this morning, the Develop panel is almost instantly ready now.

Jay S.

[areohbee]

Hi Jay,

Hmm... I'm not sure what you meant by "Loaded Up" but if I get the gist of what you are saying, Lr3.2RC did some magic as it sat overnight that speeded things up in develop mode switching for you.

I think I'm getting more confused instead of less confused .

But it sounds like you are getting similar times as me for cached image switching.

How long for non-cached?

Rob

[JayS_In_CT]

areohbee wrote:

Hi Jay,

Hmm... I'm not sure what you meant by "Loaded Up" but if I get the gist of what you are saying, Lr3.2RC did some magic as it sat overnight that speeded things up in develop mode switching for you.

I think I'm getting more confused instead of less confused .

But it sounds like you are getting similar times as me for cached image switching.

How long for non-cached?

Rob

Rob,

"Loaded up" - The act of taking one's photo's from a storage device, such as a memory card, and importing the images stored there in LR 

As for magic, I don't know, but having it sit there made the image to image exchange faster.  I'm getting ready to "load up" another batch of images that I'll put in a separate catalog with cache set to some very low amount to get a timing (hate to give up the magic  )  but like you, I'm not sure I understand totally how the develop cache is loaded.  If you're in a particular catalog event (say a wedding or sporting event you shot the day before), and do nothing, does LR put as many images of that event into cache?  If I'm in Develop and I'm pointed at an image somewhere in the middle, does it load images before and after that one into cache?  Perhaps I should, but I don't know that I've ever seen that documented anywhere.

Anyone?  (since cache seems to be a topic of interest right now)...

Jay S.

[Ian Lyons]

JayS In CT wrote:

Anyone?  (since cache seems to be a topic of interest right now)...

So far as I know there is no prefetching from the Camera Raw cache, which is disk based. When folk see very quick load times it's usually because the image has been cached in memory (i.e. it had been viewed very recently in Develop module) or they're reading from a CR cache located on an SSD drive. Also, switching off the Loading bezel (View menu > View Options) will give the perception of faster loading time because you will see the UI and adjustment sliders become active before the image is truly fully rendered. Depending on the nature of any existing edits the Loading bezel may disappear fairly soon after the sliders become active, but on others it can take many seconds more. It's obvious that Lr is still processing the file in the background when Loading bezel is visible, but switching it off means you've no idea whether file is fully rendered or not. Often this is the reason that folk see slider lag.

Note that when the initial view in Develop module is blurry it is because the Library preview is stale (not up to date) or missing. For the avoidance of doubt, the preview process in Develop module is - first load Library preview (only visible for a second or so), next the CR cache preview then the fully rendered view.

[JayS_In_CT]

Ian Lyons wrote:

JayS In CT wrote:

Anyone?  (since cache seems to be a topic of interest right now)...

So far as I know there is no prefetching from the Camera Raw cache, which is disk based. When folk see very quick load times it's usually because the image has been cached in memory (i.e. it had been viewed very recently in Develop module) or they're reading from a CR cache located on an SSD drive. Also, switching off the Loading bezel (View menu > View Options) will give the perception of faster loading time because you will see the UI and adjustment sliders become active before the image is truly fully rendered. Depending on the nature of any existing edits the Loading bezel may disappear fairly soon after the sliders become active, but on others it can take many seconds more. It's obvious that Lr is still processing the file in the background when Loading bezel is visible, but switching it off means you've no idea whether file is fully rendered or not. Often this is the reason that folk see slider lag.

Note that when the initial view in Develop module is blurry it is because the Library preview is stale (not up to date) or missing. For the avoidance of doubt, the preview process in Develop module is - first load Library preview (only visible for a second or so), next the CR cache preview then the fully rendered view.

Ian,

Thanks.  I remember the turning off the bezel and my "subliminal fastness" comment.    I don't know that experience is telling that there isn't some pre-fetch involved, or it least seems that way.  Perhaps I'm thinking of images that have been already cached, but I'd have to go back and be more observant of what's happening.  I interested in your comments about the bezel taking "many seconds more".  In 2.7 there was never anything I could put into an edit that took several seconds to give me that slider panel.  If this is all related to the process 2010 and Lens correction, etc.  I don't know that ALL that overhead isn't going to start to become problematic for mere mortal folks that aren't throwing 8 cores and 16GB of memory at LR.

I'm totally vested in LR, but even I have to recognize that other packages are doing similar (certainly not an exact match) of functions in LR and doing it far faster.  I'm not trying to start a debate, but perhaps Adobe still needs to look at those new processes and see if there isn't ways to shorten path lengths in code, reduce perhaps redundancy, etc.

An example might be lens correction.  I submitted a problem where LR Image Exif got the combination of a 70-200 2.8 Canon with a 1.4 TC on it.  However, when I went to the lens correction module, it picked a completely wrong lens.  So the question is why do some form of calculation to try and determine a lens when the lens information is already present right in the EXIF.  I can see a back up path that says if for some reason EXIF is missing try and calculate a lens, but if it's there why not use it?

Jay S.

[Ian Lyons]

JayS In CT wrote:

I interested in your comments about the bezel taking "many seconds more".  In 2.7 there was never anything I could put into an edit that took several seconds to give me that slider panel.  If this is all related to the process 2010 and Lens correction, etc.

The sliders were and still are available fairly soon after the image is selected in Develop module. However,the Loading bezel can hang around for a while after sliders have become active. For example,  Spot Removal, i.e. many spots and adjustment brushes, again many of them http://forums.adobe.com/thread/700551?tstart=0 will result in 5, 10 or even more seconds passing before the Loading bezel disappears.The same edits in Lr2.7 resulted in near enough the same delay, and yes I have checked, MANY times.

Process 2010 and Lens Corrections are being blamed for lots of things, but in the vast majority of situations their impact amounts to no more than 1 or 2 seconds, sometimes closer to 0.

An example might be lens correction.  I submitted a problem where LR Image Exif got the combination of a 70-200 2.8 Canon with a 1.4 TC on it.  However, when I went to the lens correction module, it picked a completely wrong lens.  So the question is why do some form of calculation to try and determine a lens when the lens information is already present right in the EXIF.  I can see a back up path that says if for some reason EXIF is missing try and calculate a lens, but if it's there why not use it?

I can't comment on specifics, but the engineers are aware of some issues whereby the wrong lens is selected. To date, the majority of these are due to the camera telling "pork pies". While not necessarily about the lens, the info is sufficiently erroneous to cause Lr and CR to get things badly screwed up.

[JayS_In_CT]

Ian Lyons wrote:

JayS In CT wrote:

I interested in your comments about the bezel taking "many seconds more".  In 2.7 there was never anything I could put into an edit that took several seconds to give me that slider panel.  If this is all related to the process 2010 and Lens correction, etc.

The sliders were and still are available fairly soon after the image is selected in Develop module. However,the Loading bezel can hang around for a while after sliders have become active. For example,  Spot Removal, i.e. many spots and adjustment brushes, again many of them http://forums.adobe.com/thread/700551?tstart=0 will result in 5, 10 or even more seconds passing before the Loading bezel disappears.The same edits in Lr2.7 resulted in near enough the same delay, and yes I have checked, MANY times.

Process 2010 and Lens Corrections are being blamed for lots of things, but in the vast majority of situations their impact amounts to no more than 1 or 2 seconds, sometimes closer to 0.

An example might be lens correction.  I submitted a problem where LR Image Exif got the combination of a 70-200 2.8 Canon with a 1.4 TC on it.  However, when I went to the lens correction module, it picked a completely wrong lens.  So the question is why do some form of calculation to try and determine a lens when the lens information is already present right in the EXIF.  I can see a back up path that says if for some reason EXIF is missing try and calculate a lens, but if it's there why not use it?

I can't comment on specifics, but the engineers are aware of some issues whereby the wrong lens is selected. To date, the majority of these are due to the camera telling "pork pies". While not necessarily about the lens, the info is sufficiently erroneous to cause Lr and CR to get things badly screwed up.

Ian,

Just a couple of points to add to...  regarding 2010 Process and Lens Correction.  Both are adding a substantive amount to export (Lens correction more so) and I filed a report and the Adobe team is looking at that one.

Since you do have some insight into the lens correction issues (and I'm not familiar with "pork pies") I'll again just suggest that it would seem significantly more efficient to use the data it already has in EXIF read.  Why both doing any subjective figuring at all?

Thanks again.

Jay S.

[Ian Lyons]

JayS In CT wrote:

Ian,

Just a couple of points to add to...  regarding 2010 Process and Lens Correction.  Both are adding a substantive amount to export (Lens correction more so) and I filed a report and the Adobe team is looking at that one.

Since you do have some insight into the lens correction issues (and I'm not familiar with "pork pies") I'll again just suggest that it would seem significantly more efficient to use the data it already has in EXIF read.  Why both doing any subjective figuring at all?

My response was specifically to your questions on cache.

"Pork Pies"  = lies

The lens info by itself is meaningless, the lens correction system requires additional information and it is here that the problem lies. I can't comment further on what or why.

[TK2142]

Ian, thank you very much for shedding some light on the ACR cache issue.

Ian Lyons wrote:

The same edits in Lr2.7 resulted in near enough the same delay, and yes I have checked, MANY times.

Given this information and the fact (as I learned in the "LR3.2 Raw Cache Behavior" thread you referenced) that the ACR cache only contains a partially demosaiced version of the original, I no longer think that there is a problem with the ACR cache on my system. I believe it works as intended (I say "believe" because I see disk activity when switching images but haven't checked what part of the disk is accessed).

I wonder, though, why LR doesn't keep cached versions of the final renderings. The time required to redo the partial demosaicing seems to pale in comparison to the time that is needed to perform edits to an image. If people don't edit their images, they'll see some speed up due to saving the partial demosaicing. However, if they edit, I wonder whether it is worth investing the hard drive space for a seemingly negligible speed up.

When I develop images, I sometimes go back and forth between a few images between edits to one image. Wouldn't it be nice if for a low number of images the switching time could be minimised by not re-running all the edits for each switch?

[areohbee]

From my experience, here is my best recap at what's happening develop-mode-image-display-wise:

1. Toss up something from the library preview system to kick things off (rendered preview if available else embedded jpeg).

2. Start concurrent thread/task to update panels and enable sliders whilst continuing loading.

2. Put up "Loading" indicator if preference option not prohibiting it.

3. Finish rendering - taking advantage of ACR cache data if present.

4. Update ACR cache data for next time if changed or new.

Note: Loading from disk (raw image and/or cache data + little support files) faster if OS has recently accessed a file and hence has it in smart-disk-IO cache.

There is no look-ahead or background rendering in Lightroom (that I can detect - I mean other than previews as necessary or demanded for library system).

PS - Its easy to see ACR cache behavior just by opening it in Explorer or Finder and deleting everything in it (that's all the "Purge Cache" function does). Then watch as new files are created and old files change last-modified-date.

Note: I think this explains everything I've seen (even if its wrong) but it does not explain why develop switching would be sped up by letting the computer sit for a while (you sure about that one Jay?).

Rob

[JayS_In_CT]

areohbee wrote:

From my experience, here is my best recap at what's happening develop-mode-image-display-wise:

1. Toss up something from the library preview system to kick things off (rendered preview if available else embedded jpeg).

2. Start concurrent thread/task to update panels and enable sliders whilst continuing loading.

2. Put up "Loading" indicator if preference option not prohibiting it.

3. Finish rendering - taking advantage of ACR cache data if present.

4. Update ACR cache data for next time if changed or new.

Note: Loading from disk (raw image and/or cache data + little support files) faster if OS has recently accessed a file and hence has it in smart-disk-IO cache.

There is no look-ahead or background rendering in Lightroom (that I can detect - I mean other than previews as necessary or demanded for library system).

PS - Its easy to see ACR cache behavior just by opening it in Explorer or Finder and deleting everything in it (that's all the "Purge Cache" function does). Then watch as new files are created and old files change last-modified-date.

Note: I think this explains everything I've seen (even if its wrong) but it does not explain why develop switching would be sped up by letting the computer sit for a while (you sure about that one Jay?).

Rob

Rob,

Yes..  I'm still sure image to image is faster in develop, and the only thing I did was leave it sitting all night after building some 300+ standard size 1440 previews...  In fact that was the last thing I did before I left the computer for the night.  I never quit LR, so it was still active in the A.M. when I came back.  Now, Macs do housekeeping around 3:00 A.M. or so every day (if you leave them on) and maybe that had something to with it, but I've had the machine online before at that time, so I'm not sure that had an impact..  Given all that is being discussed though, what I'm not sure about is why.

Jay S.