Highlighted

Lightroom 3.3 Performance Feedback

Adobe Employee ,
Dec 02, 2010

Copy link to clipboard

Copied

Please use this discussion topic for your feedback on Lightroom 3.3 RC and the final Lightroom 3.3 release when it becomes available.  The Lightroom team has tried very hard to extract useful feedback from the following discussion topic but due to the length and amount of chatter we need to start a new, more focused thread.  Please post specifics about your experience and be sure to include information about your hardware configuration.

Regards,

Tom Hogarty

Lightroom Product Manager

Views

95.1K

Likes

Translate

Translate

Report

Report
This conversation has been locked.

Lightroom 3.3 Performance Feedback

Adobe Employee ,
Dec 02, 2010

Copy link to clipboard

Copied

Please use this discussion topic for your feedback on Lightroom 3.3 RC and the final Lightroom 3.3 release when it becomes available.  The Lightroom team has tried very hard to extract useful feedback from the following discussion topic but due to the length and amount of chatter we need to start a new, more focused thread.  Please post specifics about your experience and be sure to include information about your hardware configuration.

Regards,

Tom Hogarty

Lightroom Product Manager

Views

95.1K

Likes

Translate

Translate

Report

Report
Guide ,
Dec 02, 2010

Copy link to clipboard

Copied

Area of interest:  The "blur" tool (local adjustments, sharpness from -51 to -100).

Specific issue:  It's slow - really slow.  I'm not so worried that it's application is slow as this is a processor-intensive operation by nature, but I am worried that it slows down the application of all the other adjustments.  I find it especially odd that it slows down cropping, which shouldn't be forcing a re-calculation of the pixels, at the very least until closing the crop tool.  Opening, changing aspect ratio, flipping or closing the crop tool is very slow.  Curiously, draging around the borders once the tool is active and in the desired ratio is not slow.

Noticed on:  Windows XP, Windows 7 64 bit, all versions of Lightroom 3 including 3.3 RC.

Notes:  It's easiest to see if you apply several applications of the tool, such as several gradients or several brush adjustments.  I'm not sure if overlapping adjustments make it worse or not as it's so slow it's difficult for me to test.

Workarounds:  None that I can find short of not using the tool.  Even shutting off the local adjustment panel doesn't bring things back up to normal speed.

Likes

Translate

Translate

Report

Report
New Here ,
Jan 10, 2011

Copy link to clipboard

Copied

I have recently upgraded from LR2.x to LR3.3. When opening an image edited in LR3.3 in CS4 (with lightroom editing) using photo/edit in photoshop the resultant image on screen is a very poor worse than the original nikon raw image. So this has dramatically affected my ability to print as the colours I get are incorrect once I do the work in CS4 to correct the poor quality image from LR3.3. This has only just started and the process I employed without problems with LR2.x and the same CS4 software produced prints (printing from CS4) that were good.

I have separately listed this problem on this forum but no-one has provided a solution or suggested solution.

I also lost many of the enhancement files resident in Lightroom when I upgraded from LR2 to LR3. Maybe they are still there maybe no but so far no-one has offered a possible solution for that problem either.

Likes

Translate

Translate

Report

Report
Community Beginner ,
Jan 11, 2011

Copy link to clipboard

Copied

Sorry guys for interrupting this very interesting thread

But I think this topic should be handeled in a different thread (not in the performane section).

I think I did not make myself clear in my original post about Spot Removal tool. My point was that I can't simply switch between LR and Bridge (there is no problem with the Spot Removal tool and jpgs) because the "Beschriftung" (I do not know the english wording for this feature therefore I used the term "color encoding", meaning you can use red or green to mark your image) is lost (I have a solution for this now).

I think nebosphere then got me wrong and thought I was talking about color garmuts.

Likes

Translate

Translate

Report

Report
Advocate ,
Jan 11, 2011

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Engaged ,
Jan 11, 2011

Copy link to clipboard

Copied

@ Sharpis: your problem relates, if I'm not mistaken, to an incompatibility between RAW processing in LR 3 and the older version of Adobe Camera Raw included with Photoshop 4. They simply don't match up. Thus, when you open a Raw Image you've processed in LR 3 in Photoshop 4, you get the results you describe. One way around this would be to save (export) the image first from Lightroom as a JPEG, TIFF of PSD file, which would render the adjustments you made in Lightroom; this should prevent the image corruption you are seeing now when you subsequently open the images in Photoshop CS4. Any Lightroom image you open in Photoshop is going to be rendered in any case when you save it. For Raw compatibility you will need to upgrade to Photoshop CS5, in which development of the ACR plug-in runs in parallel with Lightroom 3. This is done, at least in part, to prevent the kind of compatibility problems you are having.

Likes

Translate

Translate

Report

Report
New Here ,
Jan 12, 2011

Copy link to clipboard

Copied

Hi thewhitedog

I did not know that LR3 was only for CS5 or the associated ACR (mine I think is

5.7). It was offered automatically as an upgrade to what I had previously. So

what you say sounds imminently sensible and I will give it a try.

I do hope though that Adobe will be giving a fix (an ACR 5.7 upgrade) so that I

am able to use LR3.3 with CS4 (I didn't have the problem with earlier versions

of LR3). I do not use CS4 enough to warrant a new outlay fro CS5 and then CS6

sometime in the future.

Again thanks for your suggestion.

Likes

Translate

Translate

Report

Report
Advocate ,
Jan 12, 2011

Copy link to clipboard

Copied

Hi,

May I kindly remind the participating members that this thread is titled "Lightroom 3.3 Performance Feedback" ?

--

Patrick

Likes

Translate

Translate

Report

Report
Engaged ,
Jan 12, 2011

Copy link to clipboard

Copied

@ Sharpis: I wouldn't hold my breath for an ACR upgrade for Photoshop CS4. They didn't do it for earlier versions. If you don't use Photoshop that often, then saving your image from Lightroom first to another file format would seem to be an adequate workaround. The major advantage in Lightroom 3 of opening in Photoshop is that, when you finish your Photoshop edits and save the file, it will automatically be added to the Lightroom catalog. This makes the Lightroom to Photoshop workflow smother - almost seamless - and makes keeping track of versions of your files much easier. Indeed, it's now simpler to use Lightroom for managing files and doing Raw edits in conjunction with Photoshop than using Bridge/Camera Raw/Photoshop. In my opinion, using Bridge and Camera Raw is far more tedious than using Lightroom, with it's integrated interface.

2

Likes

Translate

Translate

Report

Report
New Here ,
Jan 13, 2011

Copy link to clipboard

Copied

thewhitedog, I do not know how to save in Lightroom as it has never been

necessary. I edit and then open in CS4 to finish off with features there like

free transforms, a better clone tool and other tools. I did open an LR3.3 raw

file in Nik Efex Pro 3 and saved it (with no Nik Efex changes) as a TIFF and

opening that up in CS4 had the same result no embedded editing. Of course I can

make it work this way but as you say I do not like Bridge/cameraraw/photoshop

for the reasons you state.

So I am now in a position where I do not know how to proceed.

Likes

Translate

Translate

Report

Report
LEGEND ,
Jan 13, 2011

Copy link to clipboard

Copied

Sharpis wrote:

thewhitedog, I do not know how to save in Lightroom

Using the Export dialog.

Lightroom has a pretty good Help facility - I recommend spending some time in there, then you'll find how to export your file as (say) a TIFF, and how to send it to your version of Photoshop.

It's not hard.

Likes

Translate

Translate

Report

Report
Engaged ,
Jan 13, 2011

Copy link to clipboard

Copied

@ Sharpis: you save files in Lightroom by using the Export dialog. Take some time to look it over - there are a lot of options to consider. The most important items are Export To - I generally save my file versions in the same folder they were opened from to make them easy to track, and File Settings - for a non-lossy image choose TIFF or PSD. Also important is File Naming - if you change the file format you don't necessarily have to change the name, as it will have a different file type suffix in any case. You can open the Export dialog from the File menu or with the contextual menu. Once you save a file as a TIFF or PSD, you can then open it in Photoshop CS4 without difficulty, bypassing the Adobe Camera Raw plug-in and avoiding the compatibility problems you were having. There is an option at the bottom of the Export dialog, Post Processing; in the After Export pull-down menu you can choose to open your file immediately in Photoshop.

Because Lightroom is getting more complex, it's not a bad idea to pick up a reference book you can consult when you have questions. I've found Scott Kelby's The Adobe Photoshop Lightroom 3 Book For Digital Photographers to be quite useful. It doesn't answer every question, of course, which is why I'm active on this forum.

Likes

Translate

Translate

Report

Report
New Here ,
Jan 13, 2011

Copy link to clipboard

Copied

thewhitdog

Again thanks. Yes I have saved by exporting before and the image still opens in

CS4 without the edits in LR3.3. As it is late here (Malaysia) I will look it

over tomorrow. I do have some Scott Kelby books but on Photoshop and Micheal

Evening (I think) on CS2 and 4.

Once again Thanks.

Likes

Translate

Translate

Report

Report
LEGEND ,
Jan 13, 2011

Copy link to clipboard

Copied

Samoreen wrote:

May I kindly remind the participating members that this thread is titled "Lightroom 3.3 Performance Feedback" ?

+1 vote -

Where "performance" means: the speed of things, especially things that are abnormally slow...

Not: "anything could be considered "performance" if you use your imagination..."

R

Likes

Translate

Translate

Report

Report
Adobe Community Professional ,
Jan 13, 2011

Copy link to clipboard

Copied

You're like a turkey voting for Xmas. Step back 1 page and I counted 3 posts by your good self that have SFA to do with performance.

areohbee wrote:

Samoreen wrote:

May I kindly remind the participating members that this thread is titled "Lightroom 3.3 Performance Feedback" ?

+1 vote -

Where "performance" means: the speed of things, especially things that are abnormally slow...

Not: "anything could be considered "performance" if you use your imagination..."

R

Likes

Translate

Translate

Report

Report
LEGEND ,
Jan 13, 2011

Copy link to clipboard

Copied

Ian,

I'm getting inundated with posts on this thread that have nothing to do with Performance Feedback.

Suggesting we try and stay on topic a little more (and start new threads for new topics) does not seem like a bad idea to me, even if I too have slipped up on occasion - like this one, for example.

PS - I started zero off-topic sub-conversations in this thread.

PPS - Some people truly dont understand what Tom meant by "Performance" - I apologize if my explanation came off a bit smart...

Rob

Likes

Translate

Translate

Report

Report
Engaged ,
Jan 13, 2011

Copy link to clipboard

Copied

@ Sharpis: If you export your files from Lightroom in JPEG, TIFF or PSD format the edits you made are not lost, they are "rendered", that is, applied to the exported file. If you want to retain the ability to adjust the Raw settings when you open a file in Photoshop, you will need to use the Edit In menu and choose Open as Smart Object in Photoshop. However, this will probably require Photoshop CS 5 to work reliably. There's no way around the fact that if you want to get the most out of a Lightroom/Photoshop workflow you will need to use compatible versions of both applications. For this you will need either to revert to Lightroom 2.x in order to use Photoshop CS4 or get Photoshop CS5 to use with Lightroom 3. Any workaround, however useful, will involve some loss of functionality.

Likes

Translate

Translate

Report

Report
Engaged ,
Jan 13, 2011

Copy link to clipboard

Copied

My apologies to everyone for going off topic. But when questions are posted here that I have an answer for, I don't feel comfortable ignoring them because they seem off topic. As some people have noted, they posted questions on other threads and got no answers. It seems natural they would move to an active thread to try to get some response. It's no one's fault, it's just a weakness in any system like this that people who know the answers are not necessarily scanning all the threads to see where they can help. Who has that kind of time? We don't, after all, get paid for our contributions; it's good will alone that sustains an effort like this. Shutting people out does not promote good will.

Likes

Translate

Translate

Report

Report
New Here ,
Dec 02, 2010

Copy link to clipboard

Copied

Tom,

Aside from trying to analyze everyone's individual issues and system configurations, can we agree that many of us are using the Same systems with Lightroom3.x as we were using with 2.x and are now having varyied performance issues?

I trust you are looking at coding changes that have been made since 2.x as well as additional features added to 3.x ? That would seem a likely starting point.

Regards,

Karl

Likes

Translate

Translate

Report

Report
Guide ,
Dec 02, 2010

Copy link to clipboard

Copied

appcoop1 wrote:

Tom,

Aside from trying to analyze everyone's individual issues and system configurations, can we agree that many of us are using the Same systems with Lightroom3.x as we were using with 2.x and are now having varyied performance issues?

I trust you are looking at coding changes that have been made since 2.x as well as additional features added to 3.x ? That would seem a likely starting point.

The basic demosaicing algorithms have been changed in LR3 from prior versions.  There are two basic results of this change - superior image quality and slower conversions of raw data.  While other portions of the application are faster than in LR2, image processing (and therefore preview generation, time for the "loading" indicator to go away, and exporting) are slower.  The only real way around this is more powerful hardware, specifically CPU and memory speed.  One thing the LR team has done to help alleviate this problem somewhat for some people is to expand the maximum size of the Camera Raw cache.  If you have the space available, using a large cache can help with some of these issues, especially in cases where all the images you are working on fit inside the cache and the cache has been populated by, for example, rendering previews.

Likes

Translate

Translate

Report

Report
New Here ,
Dec 02, 2010

Copy link to clipboard

Copied

Lee Jay wrote:

The basic demosaicing algorithms have been changed in LR3 from prior versions.  There are two basic results of this change - superior image quality and slower conversions of raw data.  While other portions of the application are faster than in LR2, image processing (and therefore preview generation, time for the "loading" indicator to go away, and exporting) are slower.  The only real way around this is more powerful hardware, specifically CPU and memory speed.  One thing the LR team has done to help alleviate this problem somewhat for some people is to expand the maximum size of the Camera Raw cache.  If you have the space available, using a large cache can help with some of these issues, especially in cases where all the images you are working on fit inside the cache and the cache has been populated by, for example, rendering previews.

Lee:

I hope this hasn't been answered elsewhere already - are you talking about the setting for Camera Raw Cache on the File handling tab of Preferences?

How large do you recommend setting this (I have PLENTY of HD space available.) Should I put this on the root drive (C:) or on a separate partition of the same HD?

I have some externals, but I don't think they are fast enough for cache - they are prob only 5400RPM.

Likes

Translate

Translate

Report

Report
Guide ,
Dec 02, 2010

Copy link to clipboard

Copied

LydellPhoto wrote:

Lee:

I hope this hasn't been answered elsewhere already - are you talking about the setting for Camera Raw Cache on the File handling tab of Preferences?

How large do you recommend setting this (I have PLENTY of HD space available.) Should I put this on the root drive (C:) or on a separate partition of the same HD?

I have some externals, but I don't think they are fast enough for cache - they are prob only 5400RPM.

Yes.  Put it on an internal drive that's separate from the drives where you store your images.  Set it big enough to store as many raw files as you might normally work on at a time.  I think the max is not 200GB.

Likes

Translate

Translate

Report

Report
New Here ,
Dec 02, 2010

Copy link to clipboard

Copied

Smart Collections are very slow in 3.2/3.3RC, as per this thread:  http://forums.adobe.com/thread/757607?tstart=0

All other operations for me are reasonably/acceptably fast. (Though I do any heavy re-touching/brushing in PS)

Surely SC's only need a query on the DBs (Catalogue and thumbnails for display), and would not need to access the actual images at all. Given that, I don't know why they take minutes to populate.  (I have quite a few complex, multi-level ones).

Also....  It would be nice to be able to refresh all thumbnails (eg Ctrl-A, 'refresh thumbs') without having to create previews for all images.  Paging down and watching numbnails update is annoying.

BTW - Quality improvement of LR v3 for my old high ISO 30D RAWs is fantastic!

Likes

Translate

Translate

Report

Report
Contributor ,
Dec 02, 2010

Copy link to clipboard

Copied

Lee Jay wrote:

One thing the LR team has done to help alleviate this problem somewhat for some people is to expand the maximum size of the Camera Raw cache.

Unfortunately, the ACR cache has very limited utility. It only caches demosaiced versions of the originals. None of the real image adjustments are cached. The latter (spot removal, local adjustments, etc) take up the bulk of the processing time. Hence the cache helps a little bit but it isn't the path to salvation when one experiences LR turning into molasses.

One thing that I find most surprising in LR 3.2. is that switching between images in the Develop module often causes an old preview to be briefly shown before the adjusted image is displayed. A new preview cache is only calculated if one changes to the Library module and steps through all respective images. Go back to the Develop module and now updated previews are available. That should not be necessary.

I don't know whether the issue still exists in 3.3 RC because on Windows it would replace my 3.2 and the latter has a working TAT tool. Does anyone know how 3.3 RC could be released with a broken TAT tool? It isn't a bug that is hard to spot, is it?

Likes

Translate

Translate

Report

Report
Participant ,
Dec 03, 2010

Copy link to clipboard

Copied

TK2142 wrote:

Lee Jay wrote:

One thing the LR team has done to help alleviate this problem somewhat for some people is to expand the maximum size of the Camera Raw cache.

Unfortunately, the ACR cache has very limited utility. It only caches demosaiced versions of the originals. None of the real image adjustments are cached. The latter (spot removal, local adjustments, etc) take up the bulk of the processing time. Hence the cache helps a little bit but it isn't the path to salvation when one experiences LR turning into molasses.

One thing that I find most surprising in LR 3.2. is that switching between images in the Develop module often causes an old preview to be briefly shown before the adjusted image is displayed. A new preview cache is only calculated if one changes to the Library module and steps through all respective images. Go back to the Develop module and now updated previews are available. That should not be necessary.

I don't know whether the issue still exists in 3.3 RC because on Windows it would replace my 3.2 and the latter has a working TAT tool. Does anyone know how 3.3 RC could be released with a broken TAT tool? It isn't a bug that is hard to spot, is it?

As you said: Version 3.3 is a release candidate submitted to the public for testing. It does not mean that it is ready for production, although close to it. If a broken TAT tool is a reason to hold back a release candidate is debatable, but I would not call the importance of it so high. The official production release is still 3.2 .

I thought that this thread is not for ranting, but purely for reporting and discussing solutions of performance issues including the exact specifics (as far as a user can tell it) under which the issue occurs and what the extent (timings) of the issue is.

Likes

Translate

Translate

Report

Report
Guide ,
Dec 03, 2010

Copy link to clipboard

Copied

TK2142 wrote:

One thing that I find most surprising in LR 3.2. is that switching between images in the Develop module often causes an old preview to be briefly shown before the adjusted image is displayed. A new preview cache is only calculated if one changes to the Library module and steps through all respective images. Go back to the Develop module and now updated previews are available. That should not be necessary.

Yes, I have seen both of these behaviors consistently.  One additional thing I found that really surprised me is this.  I opened up a whole bunch of raw images in Develop, made a substantial change to all of them (major WB shift), watched each one change on my screen, then exited LR.  I then made the image files unavailable by unplugging the external drive on which they reside.  Result - the Library images show unavailable (expected) but the thumbs and loupe-mode previews were the original images.  This is related to this thread because it means the application isn't taking advantage of the rendering that is done in Develop to update the Library previews, which means one much go into library and re-render each and ever image and thumb to see the effect of changes made to the images in Develop.  This is a waste of computer resources and of time.

Likes

Translate

Translate

Report

Report
Engaged ,
Dec 03, 2010

Copy link to clipboard

Copied

When selecting an image, if I'm not mistaken, the reason you see the original briefly before the adjustments you've made are displayed is because those adjustments are never applied to the original image in Lightroom. They remain as data in the catalog. The number of steps preserved in the History panel may also affect this process. Deleting the history has been recommended (by Adobe) as one way to speed up rendering operations.

As for the "Write to XMP" issue, this requires a write operation to the original file every time you make a change; essentially you are writing the data twice: once to the catalog and once to the file; the redraw is probably connected with the dynamics of this procedure in some way. If you need the XMP data with the file for some reason (you're going to use the image in another application not directly linked to Lightroom the way Photoshop is, for instance - or you want to use the image in another copy of Lightroom on another computer), as a point of procedure, it would probably be more efficient to wait till you're done with a group of images and perform the Write to XMP operation on all of them at once at the end of your workflow.

I don't see either of these issues as a bug in Lightroom; they are a necessary element in the nondestructive image processing system the application uses. It's possible the code could be improved to run these operations more quickly, but the hardware you're using may also be a factor in how well or poorly they function.

Likes

Translate

Translate

Report

Report
Guide ,
Dec 03, 2010

Copy link to clipboard

Copied

thewhitedog wrote:

When selecting an image, if I'm not mistaken, the reason you see the original briefly before the adjustments you've made are displayed is because those adjustments are never applied to the original image in Lightroom.


No, but they could be applied to the previews which are pulled up for a moment even in Develop while the raw data is loading and the image is being processed.  The bug or limitation is that the image has already been processed but the preview wasn't updated.

Likes

Translate

Translate

Report

Report
New Here ,
Dec 03, 2010

Copy link to clipboard

Copied

thewhitedog wrote:

As for the "Write to XMP" issue, this requires a write operation to the original file every time you make a change; essentially you are writing the data twice: once to the catalog and once to the file; the redraw is probably connected with the dynamics of this procedure in some way. If you need the XMP data with the file for some reason (you're going to use the image in another application not directly linked to Lightroom the way Photoshop is, for instance - or you want to use the image in another copy of Lightroom on another computer), as a point of procedure, it would probably be more efficient to wait till you're done with a group of images and perform the Write to XMP operation on all of them at once at the end of your workflow.

I don't see either of these issues as a bug in Lightroom; they are a necessary element in the nondestructive image processing system the application uses. It's possible the code could be improved to run these operations more quickly, but the hardware you're using may also be a factor in how well or poorly they function.

Sorry, but I disagree.  For starters they weren't there in LR2 and my PC is faster than a Ferrari.  And like many photographers, I have a variety of software packages I use that aren't necessarily as integrated with LR as Photoshop is.  I never had an issue with any of this in previous versions, just from v3 onwards.

Likes

Translate

Translate

Report

Report
Contributor ,
Dec 04, 2010

Copy link to clipboard

Copied

tgutgu wrote:

Version 3.3 is a release candidate submitted to the public for testing. It does not mean that it is ready for production, although close to it. If a broken TAT tool is a reason to hold back a release candidate is debatable, but I would not call the importance of it so high.

The fact that it is a candidate and the associated wording regarding "sufficiently tested" (or similar) strongly suggest that things are fine from Adobe's point of view. In other words, ideally the candidate  should turn into the real thing without further change.

Knowing about a broken TAT tool and still releasing an RC would mean that you are either only inviting input from Mac users or people with spare Windows machines (since you cannot run 3.2 and 3.3RC side by side on a single Windows machine) or that you take the stance that people don't use the TAT tool. Neither of these alternatives seem to be realistic propositions.

tgutgu wrote:

I thought that this thread is not for ranting, but purely for reporting and discussing solutions of performance issues including the exact specifics (as far as a user can tell it) under which the issue occurs and what the extent (timings) of the issue is.

I had to make the comment of not being able to run 3.3RC since I wanted to report an annoying problem but couldn't be sure whether it still persists in 3.3RC. Luckily Lee Jay (and maybe others) found my "rant" useful. Please forgive me for not opening a new thread for making the remark that I find it frustrating that I cannot provide feedback because Adobe's "one Windows installation only" and "release without extensive testing on several platforms" policies. BTW, it's not like that obvious bugs (easy to find on all platforms) have never been included in official releases. Whether its the QC team or publication targets, this is not the state of the art in software engineering.

Likes

Translate

Translate

Report

Report
Participant ,
Dec 04, 2010

Copy link to clipboard

Copied

TK2142 wrote:

tgutgu wrote:

Version 3.3 is a release candidate submitted to the public for testing. It does not mean that it is ready for production, although close to it. If a broken TAT tool is a reason to hold back a release candidate is debatable, but I would not call the importance of it so high.

The fact that it is a candidate and the associated wording regarding "sufficiently tested" (or similar) strongly suggest that things are fine from Adobe's point of view. In other words, ideally the candidate  should turn into the real thing without further change.

Knowing about a broken TAT tool and still releasing an RC would mean that you are either only inviting input from Mac users or people with spare Windows machines (since you cannot run 3.2 and 3.3RC side by side on a single Windows machine) or that you take the stance that people don't use the TAT tool. Neither of these alternatives seem to be realistic propositions.

tgutgu wrote:

I thought that this thread is not for ranting, but purely for reporting and discussing solutions of performance issues including the exact specifics (as far as a user can tell it) under which the issue occurs and what the extent (timings) of the issue is.

I had to make the comment of not being able to run 3.3RC since I wanted to report an annoying problem but couldn't be sure whether it still persists in 3.3RC. Luckily Lee Jay (and maybe others) found my "rant" useful. Please forgive me for not opening a new thread for making the remark that I find it frustrating that I cannot provide feedback because Adobe's "one Windows installation only" and "release without extensive testing on several platforms" policies. BTW, it's not like that obvious bugs (easy to find on all platforms) have never been included in official releases. Whether its the QC team or publication targets, this is not the state of the art in software engineering.

That is your interpretation of what a release candidate should be. Still, a release candidate is not meant to be for production work. If you need the TAT tool (which in my case does not seem to be strongly faulty, at least with HSL), you can continue to use 3.2. Release candidates are usually the last public beta builds before production. The Lightroom team has probably released the RC to receive broader real world feedback and the TAT problems seem one of them.

Besides that, many users seem to be very happay with the early release of a RC of 3.3, because this way, they can enjoy the support of recently released cameras very early.

I think we should stop the discussion about what release candidates are about because the thread should be focused about the performance issues and not if Adobe's quality control is OK.

Kind regards

Thomas

Likes

Translate

Translate

Report

Report
Contributor ,
Dec 04, 2010

Copy link to clipboard

Copied

tgutgu wrote:

That is your interpretation of what a release candidate should be.

Yes, and it differs from your interpretation. Whether it differs from the intended interpretion, I'm not sure, but your logic isn't very convincing:

Still, a release candidate is not meant to be for production work.

So Windows users who don't have extra machines to spare and need to do production work are excluded from enjoying the benefits of using the RC and are not in the priviliged position to provide feedback? That doesn't compute for me.

I think we should stop the discussion about what release candidates are about because the thread should be focused about the performance issues and not if Adobe's quality control is OK.

Please note that my initial post was on topic and only made a (relevant) side remark. The best option to keep the thread on topic would seem to not make such side remarks the sole topic of follow-up posts.

Likes

Translate

Translate

Report

Report
Engaged ,
Dec 04, 2010

Copy link to clipboard

Copied

Whether or not release candidate software is reliable for production work, if I recall correctly Adobe recommends against using it that way. In any event, release candidates are not finished software, or they would not be candidates. This seems so obvious to me I don't understand why people are arguing about it. The whole point, I think, of offering RC software to the public is to broaden the base of beta testers to include the widest possible variety or real world testing conditions. Adobe wants and expects to get feedback, both good and bad. Without such feedback the whole exercise would be pointless.

That said, Windows users are in an ambiguous position. Basically, if they use a RC on their production computer they are, theoretically at least, taking a greater risk that something might go wrong than Mac users, who can run the last "stable" release alongside the RC. Even so, with version 3.3RC I haven't taken the precaution of using it on only test images on my Mac. My experience since the original Lightroom beta program has given me confidence that Lightroom release candidates are reliable enough to use with my main Lightroom catalog. Others may not share my confidence; still others have found version 3 to be so troublesome that they have reverted to version 2.

Personally I think it's appropriate to believe that Adobe is acting in good faith and that they truly want to find out what's wrong with the program so they can fix it. I suggest that if you don't think they are sincere, you should not be using any Adobe beta, or release candidate, software.

Likes

Translate

Translate

Report

Report
Contributor ,
Dec 04, 2010

Copy link to clipboard

Copied

thewhitedog wrote:

Whether or not release candidate software is reliable for production work, if I recall correctly Adobe recommends against using it that way. In any event, release candidates are not finished software, or they would not be candidates. This seems so obvious to me I don't understand why people are arguing about it.

At http://labs.adobe.com/downloads/lightroom3-3.html there is no recommendation for not using it for production work.

The same page explains that the software has been "well tested".

thewhitedog wrote:

I suggest that if you don't think they are sincere, you should not be using any Adobe beta, or release candidate, software.

I believe that they are sincerely looking for feedback. I only expressed my frustration that -- on a Windows machine -- I cannot test the 3.3RC without giving up the 3.2 version which doesn't have a TAT problem. It is frustrating because releasing the RC with such a bug seems very avoidable. Just like some bugs in LR3.0 --  the "finished software" as you call it -- appear to be avoidable e.g.,  the one where image stacks weren't moved in their entirety but the top most image only. I appreciate that there are bugs which are difficult to find given limited access to test hardware. Some of the performance bugs seem to be of that nature. However, many bugs that were shipped with LR 3.0 could have been easily found by using systematic regression testing, including the major operating systems LR will be run on. If QC were better here, it would a) lead to more feedback for release candidates (since people would not need to avoid them because they didn't want to trade in working features for broken ones) and b) less bugs in the official releases.

Likes

Translate

Translate

Report

Report
Guide ,
Dec 04, 2010

Copy link to clipboard

Copied

TK2142 wrote:

I only expressed my frustration that -- on a Windows machine -- I cannot test the 3.3RC without giving up the 3.2 version...

You can, actually.  You just rename the 3.2 version's folder and go install 3.3RC.

Likes

Translate

Translate

Report

Report
Contributor ,
Dec 04, 2010

Copy link to clipboard

Copied

Lee Jay wrote:


You just rename the 3.2 version's folder and go install 3.3RC.

That'll be cool!

Won't I get a mess in the registry, for example?


There should be some reason why Adobe doesn't suport parallel installations on Windows?

Likes

Translate

Translate

Report

Report
Guide ,
Dec 05, 2010

Copy link to clipboard

Copied

I think there are one or two people around here who have all the past versions currently installed on Windows.  I've had as many as four versions installed using this approach.

Likes

Translate

Translate

Report

Report
Community Beginner ,
Dec 03, 2010

Copy link to clipboard

Copied

Perhaps Adobe could confirm (or update) the minimum requirements for running this software efficiently / effectively if the processing demands have risen significantly?

appcoop1 wrote:

Tom,

Aside from trying to analyze everyone's individual issues and system configurations, can we agree that many of us are using the Same systems with Lightroom3.x as we were using with 2.x and are now having varyied performance issues?

I trust you are looking at coding changes that have been made since 2.x as well as additional features added to 3.x ? That would seem a likely starting point.

Regards,

Karl

Phil

Likes

Translate

Translate

Report

Report
Enthusiast ,
Dec 03, 2010

Copy link to clipboard

Copied

Karl,


    in responce to your request, I was running the same hardware for 2.7 and was having no issues.  When I moved to 3.x, I was forced to double my memory from 8gigs to 16 gigs in order to get any time running at all.  I recently (last two weeks) upgraded my OS from 10.5.8 to 10.6.5, and had no change in the symptoms or solutions.  I had no issues whatsoever with 2.7, or even with the beta 3.0 (that I noticed).

Cheers!

Likes

Translate

Translate

Report

Report
Adobe Community Professional ,
Dec 02, 2010

Copy link to clipboard

Copied

I am a user of Lightroom since the Beta v3 before the release of V1. I have always upgraded to the latest version up to the present version LR 3.3RC.

My main operating system has been Win through XP to Vista and now to Win 7 64bit.

Info on my existing system is as follows.

Image00004.jpg

I have followed the forums since the use of the original Lightroom betas and while I have not experienced any major problems I can accept that some users experience major performance issues.

My main use of LR is for developing my raw files from Olympus E300 and E510 and I must say that the improvements over the past few years in the process engine, particularly process version 2010, has been very good. During this development period of Lightroom I have also used and continue to use several third party raw processing software including SilkyPix  versions 2 through 4 and Bibble Pro versions 4 and 5. These products all have their individual strengths and produce very good/excelent output files.

Presently I use Lightroom as my main raw processing software but I recognize that the processing of raw data from Digital Cameras is still in a rapid development stage. The main reason for the use of Lightroom is the quality output of version 2010 and the improvements to the sharpening and noise reduction features in version 3.x.

Regards, Denis: System iMac mid-2015, 5K 27” monitor, macOS10.15.6: LrC 9.4, Lr 3.4.1, Ps 21.2.2, Camera OM-D E-M1.

Likes

Translate

Translate

Report

Report
Enthusiast ,
Dec 03, 2010

Copy link to clipboard

Copied

Greetings Tom,

   I still see swapping/memory issues when viewing/rating quantities of images ( > 500).  LR does not appear to reuse preview memory; exiting the program and restarting does not "solve" the issue.

   I too have been an LR user since early beta release pre-1.0.  My machines have increased in power the entire time; and they have switched back and forth between PC and Mac.  Right now, I'm running a dual-quad core Mac Pro, 16gig of ram, internal SCSI Raid arrays and Nvidia Quadro FX5600 display driving two Eizo 24" monitors.  I have recently upgraded from 10.5.8 to 10.6.5, with no change in the symptoms, so does not appear to be related to OS version.

   LR can not handle importing and sorting a days shoot of images without having to stop and reboot the machine partway through because 16 gig of memory is not enough.  If I am spending the day editing only a few dozen images, arranging collections, cropping, etc, then there is no problem.  It appears to be previewing (or some relation to it) that causes the problem.

  I can reproduce this issue without effort (just a bit of time to page through 500 images) repeatedly.  Some where around 500 images, every 3rd image will cause a page fault and swap starts growing.  This is silly!  I understand if you wish to keep memory around for images that you have already seen, it speeds things up.  But when you reach the point where you start swapping rather than reusing memory, you are losing far more than you gain!

  In other problems, I too tend to do heavy retouching in PS, because I have noticed that a lot of spot corrections ( > 100) cause the response to slow down massively.  To the point where I click and wait a couple of seconds before another dust correction circle shows up.  So for images that have a lot of dust (I had one set that i was shooting a harvest, dust everywhere, darn it!) I do what I can in LR, as far as corrections go, then export to PS so it doesn't kill off LR.  But of course, doing that, I lose the raw functionality.  Ah well.  Not sure if that is an actual issue, since 99.99% of my images don't require dust correction like that; just mentioning it if you think it is an issue.

Cheers!

Likes

Translate

Translate

Report

Report
Engaged ,
Dec 03, 2010

Copy link to clipboard

Copied

To follow up what is still cropping up on the old thread, I agree with TK2142's latest post that Lightroom 3's default balance of real to virtual memory seems to favor older computers with limited RAM. But limited RAM is of diminishing importance these days, even on laptops, where 8 GB is not uncommon. As a result, the program cannot make efficient use of systems with plenty of RAM available. Designing for the lowest common denominator seems to me to be a short-sighted strategy at best. For some time now Photoshop has enabled people to allocate resources according to their own workflow needs. Indeed, Photoshop CS5, in 64 bit mode, finally enables us to access more than 3 GB of RAM. Likewise, it has been possible for many years in Photoshop to designate the drive to be used for application swap files (virtual memory). In my not so humble opinion, users would benefit immensely from such capabilities in Lightroom. Certainly many of the problems people are reporting on these forums would be less severe if Lightroom could be directed to better utilize available resources. I can't imagine this issue hasn't occurred to the Lightroom engineering team. Apparently, though, they are reluctant to address this matter. I suspect perfecting the code alone cannot solve all the reported performance problems. We need the same kind of flexibility in allocating resources for Lightroom that we enjoy in Photoshop.

Likes

Translate

Translate

Report

Report
New Here ,
Dec 03, 2010

Copy link to clipboard

Copied

On my Win 7 box, I monitored memory usage when I first installed LR 3.0 and subsequently 3.2. LR 3.0 did use all the available RAM (4GB) when processing large files with lots of adjustments (perspective control, local brushes etc). Now, LR 3.2 does not, but seems to page out to disk over about 2.4GB. So something has changed.

John

Likes

Translate

Translate

Report

Report