Hi, FYI. I just did some testing with the recently announced Cyberlink Photo Director, a (shameless) clone of Lightroom. Regarding performances when using local adjustements, in all honnesty, I must say that it is not faster than LR. It might even be slower in some cases. Importing is significantly slower in Photo Director. Local adjustments continue to perform faster in Camera Raw than in LR, though. So either LR and Photo Director have the same problems (in that case Photo Director is actually a "real" clone) or it's time to setup a much more powerful workstation to get LR (and its clones) running at a speedier pace. -- Patrick ... View more

Hi, areohbee wrote: IMO, Adobe is good about fixing bugs that prohibit its use by paying customers, and supporting new cameras..., but the other bugs and long-standing performance issues - not so much... I tend to consider that long-standing performance issues are also prohibiting the use of LR by paying customers when it becomes so slow that you have to give up. If I can achieve the very same editing task much faster in ACR (which is the case on my system), I will probably decide to switch to Bridge + PS. and lose the LR specific functionality as well as my investment (time and money) in the product. Another (possible - no guarantee) solution would be to upgrade my hardware but in both cases, I will lose money. However, switching to Bridge could be jumping out of the frying pan into the fire. See a thread that I just started about Bridge and dual monitor setup. -- Patrick ... View more

Hi, Pic4 wrote: It seems like plenty has been written, and i appreciate that various comp configs will affect how a prgoram works - but i'm puzzled by the fact that Mac's are, for the most part - all built to a same spec, where as Windows systems reqlly can vary from one pachine to another. Not sure whether this has already been discussed but I'm wondering whether these performance problems could be related to a specifc processor brand. I have recently read somewhere that Photoshop and Lightroom were optimized for Intel processors (which has to be confirmed). Maybe those who are experiencing performance issues could post what processor they are using? I'm using an AMD Athlon 64 X2 Dual core 4400+, 2.21 GHz (XP Pro SP3 + 3 GB + NVidia GeForce 9500 GT / 1GB / dual screen). ... View more

Samoreen wrote: Hi, I recently worked on a few images in LR (3.3) that needed lens corrections (mainly vertical and horizontal transforms) beside the usual corrections. While I was trying to set the relevant sliders, LR suddenly started to misbehave, slowing down to the point where it was totally unresponsive and unusable, displaying blank screens for a while, etc. I eventually installed version 3.4 RC. Not only this didn't fix the performance problems mentioned above, but the problems with the temporary blank screens and weird display behavior are now even worse. A problem that I occasionally had with LR 3.3 now appears more systematically : the second display is regularly disabled, generally while the main display is going nuts... Again, I don't have and never had such slowdown and display problems when developing RAW files in Camera RAW or handling them in Photoshop (CS5). Ditto for LR 2.x. I'm wondering why it's so difficult to list the process differences between RAW file processing in ACR and in LR. ACR is dramatically faster (same system, same files). This eliminates any hardware configuration problem and any display driver or OS related issue. Since there's obviously a big difference, it should be easy to spot. Actually, there are 3 kinds of things to list : 1.  the processing differences. ... Hi, After discussing the problem with Dan, I discovered that disabling the local adjustments (by flipping the switch located in the brush adjustments panel) eliminates the slowdown problem in the lens corrections panel. So one could think that the transform adjustements should be done first (before the local adjustments) but unfortunately, if this speeds up the transforms, local adjustments then become slow if the lens corrections remain enabled. Kind of a chicken-egg problem... ... View more

Hi, I recently worked on a few images in LR (3.3) that needed lens corrections (mainly vertical and horizontal transforms) beside the usual corrections. While I was trying to set the relevant sliders, LR suddenly started to misbehave, slowing down to the point where it was totally unresponsive and unusable, displaying blank screens for a while, etc. I eventually installed version 3.4 RC. Not only this didn't fix the performance problems mentioned above, but the problems with the temporary blank screens and weird display behavior are now even worse. A problem that I occasionally had with LR 3.3 now appears more systematically : the second display is regularly disabled, generally while the main display is going nuts... Again, I don't have and never had such slowdown and display problems when developing RAW files in Camera RAW or handling them in Photoshop (CS5). Ditto for LR 2.x. I'm wondering why it's so difficult to list the process differences between RAW file processing in ACR and in LR. ACR is dramatically faster (same system, same files). This eliminates any hardware configuration problem and any display driver or OS related issue. Since there's obviously a big difference, it should be easy to spot. Actually, there are 3 kinds of things to list : 1.  the processing differences. 2.  the additional tasks that LR is handling during development. 3.  the user interface differences between LR and ACR. Regarding #2, I only see the following: - Catalog updating (I'm not writing to the XMP file automatically). So SQLite could be a potential culprit. - Second display refreshing (although I have the same problems when using a single display). I'm now considering switching to Bridge + ACR + PS. LR is not helping me. It is consuming my time. ... View more

Hi, Here is a copy of a report that I just sent to Dan after I had new LR performance issues on my system. I'm wondering whether other users have the same feeling and are observing the same symptoms... I recently worked on a few images in LR (3.3) that needed lens corrections (mainly vertical and horizontal transforms) beside the usual corrections. While I was trying to set the relevant sliders, LR suddenly started to misbehave, slowing down to the point where it was totally unresponsive and unusable, displaying blank screens for a while, etc. I copied the RAW file and the XMP file to another folder and loaded the image in Camera Raw. Working there and trying to apply the very same corrections was a much smoother process. No slowing down, no misbehavior. Well, transforming a rather big image takes time but at least I could do the job without any particular problem. Not a new topic but I was again wondering why there are so much performance inconsistencies beween LR and ACR. Then I noticed that the ACR and LR user interfaces are actually not working the same way. For example, when I move the horizontal transform slider in ACR, it seems that ACR stops any computation until it detects that the slider is no longer moving. In LR, it seems that these computations occur continuously. That is, as soon as the slider value is changed a new computation is started. But the user can still increase or decrease the value while LR computes the new image. As soon as this computation is terminated, LR detects that a new value has been set and starts again. Meanwhile, the user can set a new value for the slider, etc. I don't know if I am clear enough but I guess you see what I mean. ACR obviously doesn't behave this way. My feeling is that LR doesn't have an internal flag telling him that the current computation is no longer valid and has to be stopped because the user has changed the slider value anyway. It seems that ACR has such a mechanism. Otherwise I cannot understand why ACR runs much more smoothly when doing exactly the same job as LR. Moreover, if these transform computations are managed in a queue and if any change in the slider value adds a new entry to the queue (thus generating a number of useless jobs), I can understand why LR becomes unresponsive : a lot of unnecessary jobs are stacking up in the queue and are executed while they should be invalidated each time the user changes the slider value. Just a guess but there must be an explanation anyway... Hope this helps. ... View more

Hi, Jeff Schewe wrote: but the odds are, every confirmed bug has been assigned to somebody for fixing. So I guess that many of us would like to know the exact definition of a confirmed bug. Is this necessarily a reproduced bug? When such a confirmed bug is added to the bug database, is the author of the bug report notified ? If not, shouldn't it be (this can be done automatically) ? ... View more

Hi, thewhitedog wrote: But the primary reason for this forum, as Tom just reiterated, is not to sing the praises of Lightroom, but to report and discuss problems. Unfortunately, when people do complain, someone else feels compelled to tell them they're using the program wrong, or some other such insult to their intelligence. ... Some here consistently take criticism of Lightroom as some sort of personal attack. I suggest that it is they, not the critics, who are misusing this forum. The forum was not started to defend Lightroom or Adobe; it was to take problem reports so that Adobe staff could do a better job of fixing the problems. I fully agree with this. Documented critics and problem reports are positive contributions. Many users reporting problems are also computing professionals who are not "baying at the moon" but are able to identify and document software bugs and design mistakes. So this forum is not the right place for LR evangelists. We are already convinced that it's a good product. We just want it to be fixed. And not posting critics and bug reports would just mean that we don't care any more, which would be much worse news for Adobe (meaning that we are considering switching to another product - not much competition around here but Bibble is stabilizing). ... View more

Hi, So Adobe wants user feedback in order to fix these performance problems. But are they doing what is needed to achieve such a result? In every commercial application I have ever written, I have always implemented a "debug mode" feature. When a user reported a problem that I could not reproduce in my lab, I asked him to open the application's "Preferences" dialog and to check the "Debug mode" option. With this option enabled, the application started to record every user actions, tracing entry and exit points (and exit codes) of every important routine, collecting information about the user's system, etc. Once the problem had occured again, the user had to disable the debug mode option and to send me the log file. 90% of the time I could see what happened and fix the problem (or explain to the user what he was doing wrong or what was wrong with his system) without having reproduced the problem on my own systems. And I'm not talking about small applets. I implemented this in complex applications involving a user interface, system services and device drivers. By the way, this demonstrates that the statement "not reproduced, not fixed" that we have read here too many times is not justified. If I was able to do this for my apps as a small software shop, I'm wondering why Adobe can't do that for Lightroom. There are a lot of commercial software on the market having a similar option. Of course, such a feature is a little bit more difficult to add "after the fact". It's preferable to think about it during the software engineering phase. Also, when the application uses multithreading (like LR does), the logging system has to be protected against re-entrancy. But any seasoned programmer can deal with this. When implemented properly, such a feature has no impact on the software performance. When the option is disabled, the debug code does nothing at all. When enabled, this code may slightly affect performances but again, if this is done properly, the impact will be very limited. If we go back for example to the "frantic registry accesses" problem, a debug mode feature would have help determine what's going on (which code is running repeatedly) when the problem occurs. So I'm wondering : since LR version 1.0, bugs have been reported that Adobe could not reproduce and nobody has ever considered implementing a debug mode feature or writing a specific debug version (which is another way of achieving the same result : collecting information from and tracing execution on the user's system) ? ... View more

HI, imajez wrote: Jeff has said on several occasions he is not an Adobe employee, though he certainly does advise and give them useful feedback. And when he is not letting off steam and being somewhat tactless, he can be extremely helpful at times to users of this and other forums. Correct. Let's say he has tight relations with them. ... View more

Hi, thewhitedog wrote: If we stop recommending Lightroom to our friends and associates, that will hit Adobe where it really hurts, in the bottom line. Adobe has traditionally relied on its user base to evangelize its products. They can ill afford for that base to turn sour on Lightroom. I read again the statements made above by Jeff Schewe : they obviously don't care that much. I have exchanged informations with a member of the development staff and honestly, I can't say that they are not trying to solve the performance problems and fix the related bugs. However, they are doing what they can or what they are allowed to do. Which again leads the discussion to what the company is ready to do (that is, invest) to have these bugs fixed. Jeff Schewe statements give us an idea. When I was a Microsoft MVP, I reported bugs in some of their development tools that they could not reproduce. Since others reported the same bugs/issues, they sent an engineer to me and we spent some time on my systems working together on these problems. This helped a lot solve these issues. So the problem is not what the LR developers can do but what Adobe are wanting to do. ... View more

Hi, Jeff Schewe wrote: Deal with the reality instead of baying at the moon. You'll be better off in the long run. Let me give you an idea about something "real": when I can bring LR3 to its knee on a rather powerful system just by creating a single local adjustment and when, oddly enough, the problem totally disappears by removing the capture date and time overlay from the display options, that's a real bug, not an inadequate use of the product. So I don't know who is "baying at the moon" but it's time to consider fixing LR3 instead of telling the customers that they didn't understand how to use it. Can't believe it. ... View more

Hi, tgutgu wrote: I think also that spending more time on answering emails than on bug fixing is not what we want, but on the other hand we don't see the results that they spend more time on bug fixing. Agreed. Given the big amount of time spared by not answering so many bug reports or messages in the forum, there should not be any long standing (or persisting) bug in LR. However, some bugs reported in version 1.0 of the product are still there in version 3. So how did they use this spare time? I'm afraid, it was used to produce new features justifying an upgrade to the latest version. That's the problem: some users always want more features while others give the priority to a more stable product. But fixing old bugs doesn't bring cash. I have been an independent developer and sofware vendor for many years and I always tried to fix all the problems that were reported, provided I could reproduce them. For sure, I gave higher priority to the bugs that had the most impact on the user's experience but I fixed everything anyway. And I never asked money for fixing bugs : that is, I always tried to fix all reported bugs before releasing a new major version instead of telling the user that such or such fix would only appear in the next major release. ... View more

Hi, H.D. wrote: Win 7 64bit or 32? I'm wondering if this makes a difference. Could be a hint for the guys from Adobe where to search the problem. Considering the reports that have been uploaded, this performance issue with the local adjustment tools cannot be related to a hardware configurations being too weak (very powerful systems do have the problem) or to a specific version of Windows or even of the OS. My understanding is that Adobe are clear about this. -- Patrick ... View more

Hi, May I kindly remind the participating members that this thread is titled "Lightroom 3.3 Performance Feedback" ? -- Patrick ... View more

Hi, H.D. wrote: "Beschriftung" (I do not know the english wording for this feature Beschriftung means Label (in that case, color label). MfG -- Patrick ... View more

Hi, Lee Jay wrote: If you can see it on your monitor, chances are you can print it since the monitor likely has a smaller gamut than many available print sources.  Of course, with LR currently lacking soft proofing, you might have some trouble editing it to get it to look like you want it after printing. I'm using this plugin : http://www.lightroom-plugins.com/ProofIndex.php So far, I'm very satisified with it. -- Patrick ... View more

Samoreen wrote: DanTull wrote: Also, if you turn off the loupe overlay and set your grid to not show the capture time on each cell, do the calls stop? Since the registry calls problem is unfortunately (or fortunately?) back since today, I can now answer this question: removing the capture date/time from the overlay makes the problem disappear. To be more accurate: - Removing the capture date/time overlay in Loupe Mode makes the problem disappears. - Using the Grid mode in the secondary window (instead of the Loupe mode) even if the thumbnail displays the capture date/time for each cell doesn't make the problem re-appear. -- Patrick ... View more

DanTull wrote: Also, if you turn off the loupe overlay and set your grid to not show the capture time on each cell, do the calls stop? Since the registry calls problem is unfortunately (or fortunately?) back since today, I can now answer this question: removing the capture date/time from the overlay makes the problem disappear. -- Patrick ... View more

Hi Dan, DanTull wrote: The rate at which you are seeing it definitely suggests something in your situation is triggering a different series of events to occur than I'm seeing. Does the screen flicker as you mouse over (suggesting excessive re-painting) and is there anything unusual about your mouse (is it a tablet, do you have any usual settings for the cursor, etc)? Also, if you turn off the loupe overlay and set your grid to not show the capture time on each cell, do the calls stop? Lastly, do you have auto-write XMP enabled? (I haven't tried that yet, but the fact that the XMP/metadata code uses the time component call makes me suspect it). Since LR now works normally (and much faster) since I uninstalled/cleaned up the registry and the disk/re-installed, I may not be able to answer all questions but I'll try... Does the screen flicker as you mouse over No. is there anything unusual about your mouse (is it a tablet No. I have a tablet attached but the problem also happened without it being connected. It is still there however, and there's no problem with it. As mentioned in a previous message. I didn't change anything to my configuration during the uninstall/cleanup/reinstall process and I didn't even reboot. The problem was cured immediately. Since I only removed the LR related folders and registry keys, the problem may be caused by something that happens when upgrading from a previous version (although as I mentioned, 3.3 was installed in a new folder). Also, if you turn off the loupe overlay and set your grid to not show the capture time on each cell, do the calls stop? I can't say but the problem was only appearing when hovering the image editing area. The registry calls didn't occur when hovering any other area in LR (or any other application window not related to LR). Lastly, do you have auto-write XMP enabled? No. This option has always been disabled. I save the XMPs only when needed. -- Patrick ... View more

Hi, teho59 wrote: It seems I do have the same symptoms for registry reading. What I  wonder about is the last line above here says "NOT FOUND". Thats must be why it tries so often to get it? If it was found it would stop checking? No. When a program looks for information in the registry, it's not unusual that the requested registry key or value doesn't exist. I would even say that this happens all the time in many cases. In most situations, when a key or value doesn't exist, this means for the calling program or module that a defaut value should be used. Not all possible registry keys and values are actually present in the registry. I would say fortunately because this would make the registry even bigger. Using default value for keys and values that are not changed that frequently is a good way to save registry space. In our case, the request sent to the registry is not made by Lightroom itself but by a system routine that is itself called by LR. In no case a system routine would request again and again the same registry value because it didn't find it the first time. So you shouldn't worry about this NOT FOUND warning in the registry monitor. ... View more

Hi, KKuja wrote: The vast majority of users are also not posting problems which generally suggests lots of people are not having problems. I agree. And when there have been wide spread problems Adobe has usually recalled problematic version and released new dotdot release which have fixed the worst problems. Do not underestimate the number of people who are not reporting any problem even if they have one. How many of the Lightroom users do you think are visiting this forum? How many people are using the bug report form? How many users are just clicking on "Check for updates" every other month just to see if things could get better? This doesn't mean that every LR user has problems, which is certainly not true. Moreover, think about the non english speaking users who are facing a page in english when they want to report something to the support. On the french site, there's no bug report form and when you click on "Ask a question", you are redirected to a page in english (US). Clicking on "Change" to go to a page in french will send you back to the french site's home page. Endless loop... I guess this is the same for many other countries. ... View more