Luminous Landscape Forum
Raw & Post Processing, Printing => Adobe Lightroom Q&A => Topic started by: larkis on September 12, 2018, 12:55:21 pm
-
I'm sure this has been touched upon at some point on this site, but what is happening with lightroom classic at the moment ? I have used the application since version 1 and have hundreds of thousands of images in my catalog. Yesterday I downloaded a demo of capture one 11 and was saddened when I realized that in comparison lightroom feels like antique software in terms of performance both on my mac book pro retina and my new 28 core 58 thread windows 10 machine. Everything from adjustment interactivity viewed simultaneously on my 4k cintiq 24 and 27" eizo display to the way the masking tool painting responds on the tablet just feels the way it should given the hardware. This is not even going into the adjustment tools and layers that are not available in lightroom.
Is anyone from adobe aware of this ? Or has the marketing department been engulfed by the cloud and is no longer interested in making software for professionals ? It seems that it's not even supported properly on a 4k display on windows 10. I would switch to Capture one but unfortunately I use a medium format camera not made by phase so that complicates matters for any raw that does not come from my a7rIII. I hope anyone close to adobe can chime in and at least drop a hint that there is some work being done internally to improve the products or if people that have huge libraries need to start thinking about retooling their whole workflow.
-
Define "professionals". Those with medium format gear and brand new high-end systems, sure, but that's only one group that makes a living from photography and there's plenty of stuff listed on this recent features page (https://www.adobe.com/uk/products/photoshop-lightroom-classic/features.html) that is relevant to this broad range of demanding users. The use of embedded previews or the new Auto setting are just two. There has been an ongoing drive to remove performance problems, which is mentioned on that page and elsewhere.
Rather than extrapolate from your specific performance differences between the two apps to some LR vs C1 thing, you might be better off seeing if there is some configuration issue. GPU is as often the culprit as it is the solution, but your specs indicate it should be enabled. It could be that adjusting its settings might be beneficial too.
And maybe ask if people are even able to have huge libraries in C1....
-
Define "professionals".
Maybe I should have said power users, or people who expect the software to be a well tuned tool for the task it's marketed for (I assume professionals and casual users want this to). I was also not complaining about library performance, just the develop module which seems behind in editing performance on every single machine I have tested it on so far, even after starting a new catalog to rule that variable out. Since the develop module is a big part of the functionality of the software I would hope they can catch back up with Capture One.
Core rot of adobe applications has been discussed elsewhere and it's kind of sad to see the tools a lot of us love fall behind, especially in the areas they were the king of the hill (or the hill itself) before.
-
The core rot stuff is just such a lazy generalisation, like "bloat", isn't it? I think many of us yawn at that term. With all leading applications there are always things one does better than the other, and P1's market demands high end performance and tethering, LR's maybe less so, but how good is C1 at managing more than a few thousand images, HDR which is big in real estate work, or stitching, and so on? I'd still focus on the configuration issues, but in general I am less confident of LR driving large screens and I think there have been too many reports of slowdowns on high end laptops. Solving that isn't a case of a single solution, but a range of them, and since 7.0 that seems to be what Adobe are doing. Yet with such a big and diverse user base, they can never win.
-
My feeling is that if Capture One is so great, make the switch from Lightroom and use it. You don't see users of Photoshop dissing Elements.
-
I would switch to Capture one but unfortunately I use a medium format camera not made by phase so that complicates matters for any raw that does not come from my a7rIII.
Dissing ? Observing lightroom's shortcomings does not mean I have general hatred for it. Elements and photoshop don't pretend to cater to the same market so I'm not sure how that comparison is relevant. Lightroom is basically a player in the same league as Capture One which is why it's jarring to see some of those differences when they do occur.
It seems that other people on the forum are observing similar issues: https://forum.luminous-landscape.com/index.php?topic=125429.0 and adobe has come out in 2017 admitting this is a concern of the community: https://theblog.adobe.com/on-lightroom-performance/
-
As a user of both, I have a couple of salient observations.
Firstly, in respect of the O/P's basic complaint about the responsiveness of the Lr Develop Module, I don't have the same experience. Mine is pretty good. I find Lr responds to edit commands instantaneously as it always did since years ago. My computing environment is not even the most recent. I'm using a mid-2010 MacPro (desktop) with 24GB RAM, 2.66GHz clock speed and 24GB virtual RAM.
Regarding the quality of output from Lr, Martin Evening's comparison of the two applications, though a version or so predating the most recent for both applications, I think says it all, nicely laid out in a scientific, systematic manner. For those who haven't seen it, I can roughly sum it up as "6 of one, half a dozen of the other", though there are some nuances, so that rough statement doesn't do it complete justice. If you want the fine details read Martin's contribution. I've worked in both and always found that the toolsets in both applications allow one to derive approximately equivalent definition, tonality and colour, but I seldom work larger than for 13*19 inch output, so I haven't compared them for mural-sized enlargements.
There are four aspects of Capture One that don't often get picked up in these discussions:
(1) For those who own Phase One camera systems (I have an earlier one), for doing tethered capture this is the only option. Tethered capture comes in very handy in studio settings where absolute freedom from vibration is important. I'm using it for macro-photography just now and this is a clear case in point.
(2) There is a basic difference of architecture between C1 and Lr that I think is important, I have brought to Adobe's attention years ago, but it never worked its way into the Adobe way of structuring the application: when you do layered work with C1 (creating masks, etc.) you have at hand the full editing toolset. This is not the case for Lr, where any kind of masking (Adjustment brush or Graduated tool) offers only a reduced set of editing tools. I have long hoped for the day when Lr would allow one access to the full toolset when working on masked portions of the photo.
(3) When you use "Sessions" as the organizing principle for your work in C1, absolutely everything related to all the photos within that Session is self-contained within a file structure for that Session. So if you want to port the work you've done from one computer to another, all you need to do is send the Session over to C1 on the other computer and everything is identical between the two. Syncing has always been a nightmare with Lr.
(4) Finally, there are some Cultural Heritage specialty features in C1 designed for cultural heritage copy work with the latest Phase One and Digital Editions equipment that don't exist in Lr, but to access these you need the CH Edition of C1, which is terribly expensive.
-
in respect of the O/P's basic complaint about the responsiveness of the Lr Develop Module, I don't have the same experience.
Maybe you're the lucky one or have lower expectations than everyone else.
Poor responsiveness of the develop module has been complained about time and time again, both here and in just about every other relevant forum on the net. If it really wasn't a widespread issue Adobe wouldn't be making such a fuss about trying to rectify it recently.
-
Maybe you're the lucky one or have lower expectations than everyone else.
Poor responsiveness of the develop module has been complained about time and time again, both here and in just about every other relevant forum on the net. If it really wasn't a widespread issue Adobe wouldn't be making such a fuss about trying to rectify it recently.
Can you point us to evidence of the "fuss" Adobe has made and whether what they've been doing is "rectifying" performance from what standard to what standard, versus simply striving for faster performance as any application developer would do in the normal course of improvement and then marketing these changes?
I don't think I'm lucky and I can't conceptualize my expectations in terms of other peoples' expectations because I have no way of objectively knowing what they are relative to mine and how to measure them.
All I can do is report my own experience from years and years of using this application. My most current experience relates to version 7.1. If the responsiveness of the editing tools has declined between that version and the most recent, I wouldn't have had that experience so I can't report on it. All I can tell readers is that using 7.1 I don't experience adjustment lags between the time I trigger an edit and the time it takes effect. If there were noticeable delays I would be concerned. So that is as close a "scientific" statement about my expectations that I can make.
There is one aspect of responsiveness that I do find somewhat concerning, but it is specific to one function and unclear what the cause may be: calling-up large TIFF files in the Develop module, and here I am talking about files of film scans that are roughly 450 MB large, being 27 x 18 inch linear dimensions at 360 PPI. When I open these photos in Develop, I can be staring at the "loading" advisory for perhaps 20 to 30 seconds - I haven't timed it exactly. Now is that because of Lightroom, or because the data is being fetched from an eight year old 7200 RPM hard drive? How much faster would it be if I were to replace the hard drive with an SSD? Could be night and day. But 24 MP raw files from my Sony a6300 load-up very rapidly.
-
Can you point us to evidence .............
Mark, you've been on this forum for years, you're not stupid, you know very well how much criticism has been leveled at Adobe on this issue and the amount of puff they've expended on surveying users for issues and promoting any tiny improvement they've tried to screw out of LR.
Don't expect me to waste time itemising it all, there's just so much.
Just be honest and accept that performance in the develop module has been one LR's weak points for years for a lot of users.
-
Can you point us to evidence of the "fuss" Adobe has made and whether what they've been doing is "rectifying" performance from what standard to what standard, versus simply striving for faster performance as any application developer would do in the normal course of improvement and then marketing these changes?
From around the time they introduced Classic, Mark, a series of releases specifically included performance improvements and targeted a variety of areas of the program. Unfortunately Adobe have rejigged their blogs from the old LR journal and it's a pain tracking down migrated posts, but I did come across this helpful
list of new features (https://helpx.adobe.com/lightroom/help/whats-new.html) and would point you to the 7.0 and 7.2 posts. Using the embedded previews is one action which isn't a standard code optimisation.
-
Mark, you've been on this forum for years, you're not stupid, you know very well how much criticism has been leveled at Adobe on this issue and the amount of puff they've expended on surveying users for issues and promoting any tiny improvement they've tried to screw out of LR.
Don't expect me to waste time itemising it all, there's just so much.
Just be honest and accept that performance in the develop module has been one LR's weak points for years for a lot of users.
Don't have the temerity to read into my mind what I know or don't know. And don't think for a moment that your interpretation of what Adobe has been doing is necessarily gospel and my interpretation anything less than my honest perception of what they are doing. The glass can be half-full, half-empty, different people have different perspectives and may even disagree on perceived "facts".
The most honest thing I can do is report my own experience and that's what I've done.
-
From around the time they introduced Classic, Mark, a series of releases specifically included performance improvements and targeted a variety of areas of the program. Unfortunately Adobe have rejigged their blogs from the old LR journal and it's a pain tracking down migrated posts, but I did come across this helpful
list of new features (https://helpx.adobe.com/lightroom/help/whats-new.html) and would point you to the 7.0 and 7.2 posts. Using the embedded previews is one action which isn't a standard code optimisation.
Useful link, thanks.
I don't understand what is inferred in your last sentence. Grateful if you could clarify it.
-
I was pointing out that the feature wasn't simply "simply striving for faster performance as any application developer would do in the normal course of improvement and then marketing these changes?" As well as fine tuning existing code and marketing the changes, this was a new feature to improve performance.
-
As well as fine tuning existing code and marketing the changes, this was a new feature to improve performance.
Ah - that's an important clarification, because one could have mistakenly interpreted it to mean that it was something wrong-headed (...isn't standard optimization). Thanks for clarifying.
-
Maybe you're the lucky one or have lower expectations than everyone else.
Poor responsiveness of the develop module has been complained about time and time again, both here and in just about every other relevant forum on the net. If it really wasn't a widespread issue Adobe wouldn't be making such a fuss about trying to rectify it recently.
Most people want stuff to go faster. Most software developers strive to speed things up as a matter of course. I’d like LR to respond faster too, but it actually works fine. Responsiveness is largely determined by how much you want to spend on your CPU/GPU, and whether you are running an SSD.
-
Responsiveness is largely determined by how much you want to spend on your CPU/GPU, and whether you are running an SSD.
This is not universally true. As with most endeavors ... it's not a one-size-fits-all situation.
If you research discussions here, on the Adobe U2U forums and elsewhere, you will see where some savvy, experienced users with some very capable top of the line hardware are suffering from excruciatingly slow performance. The situation doesn't seem to have a singular universal quick fix answer that can be pinpointed reliably to either software and/or hardware.
My own experience working mostly on moderate to above average hardware configurations, I have had very good responsiveness when working with my normal 20-24MP (D750 and D500) images but do see significant slowness when throwing a large basket full of 50MP (D850) images which is understandable as there is much more data involved. Sometimes it's a matter of perspective along with the size and quantity of the image files we most commonly work with.
-
Maybe you're the lucky one or have lower expectations than everyone else.
Poor responsiveness of the develop module has been complained about time and time again, both here and in just about every other relevant forum on the net. If it really wasn't a widespread issue Adobe wouldn't be making such a fuss about trying to rectify it recently.
I’m using LR to work on IQ3 100 files all the time, using a 2013 MacPro and now exclusively on a 2018 MacBook Pro with an eGPU when at home. I see no real issues with LR performance unless I try some intensive work with the spot tool (over 100 spots) or maybe having a large number of adjustment layers (more than 10 or so), both scenarios something I just don’t find myself doing.
I use C1 Pro as well but to be honest the workflow from import to printing with LR is something I’ve done so long, and I get great results. I also find the LR auto mask function (something I rely heavily on) works far better in LR and is pretty weak in C1.
-
I use C1 Pro as well but to be honest the workflow from import to printing with LR is something I’ve done so long, and I get great results. I also find the LR auto mask function (something I rely heavily on) works far better in LR and is pretty weak in C1.
I agree - and the Print module in Lr is better developed.
-
I see no real issues with LR performance unless I try some intensive work with the spot tool (over 100 spots) or maybe having a large number of adjustment layers (more than 10 or so), both scenarios something I just don’t find myself doing.
I find that one of the biggest slowdowns for LR is local adjustments done with the Adjustment Brush while using Auto Mask. This is a known issue because the auto-mask adjustments need a degree of precision that is simply not best done with parametric adjustments. Soft brushes and gradients don't suffer the same slowdowns. The mention of spot healing is also a potential slow down because again, parametric adjustments tax ACR/LR's processing. Add to that a large high resolution display and you have the makings of very slow ACR/LR performance...
I'm really amazed at how far people try to push parametric adjustments...localized adjustments and retouching is best done in Photoshop where the pixels are being edited and not in ACR/LR where the parameters are beinging edited. I kinda see an anti-Photoshop bias by a lot of photographers who try to everything in raw.
Don't get me wrong...I'm really good at working in ACR/LR. Heck, I even write books about editing in those apps. But I'm also pretty good in Photoshop and have no problem pulling the trigger and drawing the line at parametric editing and pop an image into Photoshop for further editing...often I'll split the difference and open an image from LR as a Smart Object in Photoshop so I can easily combine parametric editing with pixel editing.
ACR/LR weren't designed as final image editing applications. ACR was designed to open raw images into Photoshop for further editing and LR was designed to deal with masses of raw images photographers find themselves shooting.
If LR is running real slow for you, ya gotta ask why...are you trying to do too much in LR that really should be done in Photoshop?
BTW, I really only have slow performance on a regular basis on DNG panos and processed panos in .tif–that and large film scans. But then I'm not doing editing of those images in ACR/LR, I just store them in LR.
-
I would appreciate some guidance on addressing what I perceive as slow processing of 50MP 5DsR files in Lightroom 6.14. The particular issue relates to moving from one image to the next and viewing in the zoom view. It takes me so long to move from one image to the next that it disrupts my workflow. My 20MP 6D files are no problem. I don't mind waiting for tasks such as HDR or panorama merges, but moving from one file to another is taking longer than I would like.
My system is near new with an i7-8700 CPU; 16GB RAM; OS & programme files & catalog on a Samsung SSD (MVie?) drive and raw files on a reasonably fast 4TB HDD. No GPU card and relying just on the Intel integrated graphics. I'm running two screens, Samsung 1920x1080 for menus (sliders) or in grid mode, and a 24 inch 1920x1200 Eizo as the main screen. Looking at the resource monitor, my CPU is running at close to 100% (4.2GHz) when processing, but RAM is rarely more than 12GB, only when doing large panorama merges. I do notice that the RAM usage is about 30% when I first start LR and then gradually creeps up over 50%, at which point I restart LR.
I understand that LR does not benefit much from GPU acceleration. The Intel graphics does not seem to get much over 10% according the resource monitor and I don't notice much difference if it is switched on or off. Happy to be corrected and get a GPU.
Is LR Classic CC 7.1 that much faster?
Thanks, Bob
-
I'm really amazed at how far people try to push parametric adjustments...localized adjustments and retouching is best done in Photoshop where the pixels are being edited and not in ACR/LR where the parameters are beinging edited. I kinda see an anti-Photoshop bias by a lot of photographers who try to everything in raw.
Don't get me wrong...I'm really good at working in ACR/LR. Heck, I even write books about editing in those apps. But I'm also pretty good in Photoshop and have no problem pulling the trigger and drawing the line at parametric editing and pop an image into Photoshop for further editing...often I'll split the difference and open an image from LR as a Smart Object in Photoshop so I can easily combine parametric editing with pixel editing.
ACR/LR weren't designed as final image editing applications. ACR was designed to open raw images into Photoshop for further editing and LR was designed to deal with masses of raw images photographers find themselves shooting.
If LR is running real slow for you, ya gotta ask why...are you trying to do too much in LR that really should be done in Photoshop?
I couldn't agree more, I think that pixel editing is too underrated. I agree to do as much as you can in a parametric editor but heavy localised editing is best done in a pixel editor. By using smart objects and layers you don't neet to throw away your original pixels.
-
This is of course true, and by keeping the raw file one always has the original data, but saving TIFF or PSD files with layers intact can be very storage-intensive. I'm working on stuff now that without flattening the files get into >1GB each. Yipes. Yes I know "storage is cheap" but it's not that cheap (especially if SSD), takes space and needs to be backed-up. As well, long-term storage of unused hard-drives is unsafe, so how much of this one needs deserve consideration.
Taking this back to the original complaint - slow responsiveness of LR - it would perhaps be useful - especially to/for Adobe - to see some kind of scientific, systematic work-up of evidence from may users with varied operating environments on Lr's processing performance; this would need to be structured to accommodate all the key variables most likely to affect it in an analytically useful manner. Such a construct would take us beyond the anchorless, anecdotal impressionistic stuff that constantly gets trotted out in these kind of discussions, inevitable for want of a rigorous framework within which to evaluate application efficiency. Not that the anecdotal material is unimportant - people can readily see, say, when they move from version X to version Y whether the performance of this or that feature has slowed down when the change is large enough to be noticeable. But beyond that, one wants to know why - is it regression of application design, or is it an emerged disconnect between the new demands of the application versus factors with one's operating system? And what else.
-
...
Is LR Classic CC 7.1 that much faster?
Thanks, Bob
I am on a mac; a new fast computer- it can do on the latest LR 7.5 35 nefs (36MP) a minute export to 16bit tiff
it only uses the cpu for exporting - i guess the GPU helps the interface... (?)
Lr 6 does about 20 nefs a minute - so yes it is much faster.
Personally i have no problems with the speed of LR- i did have some on my old2008 Macpro.
I also have a question concerning LR
what is the difference between version 4 ( new) and version 3 2012
I am tempted to stay at version 3 for my older photos are made with it, except when the quality has improved.
I cannot see the difference...
-
I couldn't agree more, I think that pixel editing is too underrated. I agree to do as much as you can in a parametric editor but heavy localised editing is best done in a pixel editor. By using smart objects and layers you don't neet to throw away your original pixels.
Smart objects and adjustment layers are a parametric workflow. You just have a baked file sitting at the bottom of the stack vs a raw.
I agree with Jeff that photoshop is great and much faster and precise for localized editing, but there is a case to be made for an environment where all your data is available to all the tools. People that do heavy dodging and burning, localized color shifts and other such tasks in their raw editor have the unbaked pixels at their disposal. Try this experiment: Process a raw file in lightroom to make it fairly dark, or even black, take it as a smart object into photoshop and then try using the exposure tool (or any other) to get it back to it's original brightness. You won't be able to do it without at the very least introducing banding or some other color issues. Photoshop does not go into the raw data inside the smart object which is less flexible than it could be if more procedural adjustments could be done in lightroom (or if photoshop could have a raw data layer photoshop's tools could access). This problem has been solved in most applications used in the VFX world that cache all the adjustments the user does not wish to constantly re compute and only update when asked. Applications like Mari do this for amounts of data that photoshop simply can't deal with, and nuke or davinci resolve can read raw data and have cache points along the adjustment flow where 80 thousand+ adjustments (I have seen this on a few films in nuke) can be worked with without loosing any interactivity.
I realize photoshop has been architected in an era where the needs were different and that Adobe has to cater to a much broader audience, but some features are useful for everyone. For example if users could import alphas from other applications to be used as adjustment masks, edits could stay in Lightroom which is a nicer environment for photographers to stay in. Which dot does what ? How about letting us name the adjustments if a layer system like the one in CaptureOne is a no go ? Having one source file instead of many is always cleaner and easier on storage and not neglecting key feature performance is also something everyone benefits from.
I remember last year talking to one of the Adobe developers at NAB regarding another popular application they have: After Effects. They have some interesting issues with it that highlight some broad issues with Adobe. For years now, the import mechanism for image sequences has been dog slow. It attempts to list all the images in a sequence vs just showing one file that represents the sequence (something competing tools have done for years). This has every day implications for thousands of users especially if they deal with directories that have multiple image sequences inside of them. OpenEXR files are so slow in after effects that many studios have switched to nuke for tasks After Effects is better suited for just to mitigate the performance issues. A hack tool called immigration that used to sell for 19 dollars fixed the import issues but its silly to have to get a plugin that's basically a properly working import dialogue the host application should provide.
When I physically showed the developer the issue on the machine he was demoing something on, he looked surprised and said "hmm, yea... I will have to bring this up with Adobe" and mentioned that the new bridge like window they were showing could be a candidate for this improvement down the road. I'm sure embedding adobe stock into the applications and making videos pop up when hovering over tools is helpful to some segment of the market, features that the whole market uses (such as open or import) should always be re visited.
Before everyone attacks me for being an Adobe "hater" (i'm not) and for pointing this out, my opinion only echoes a broader one long time users have voiced on various online and offline forums. This year at siggraph there was some laughter at Adobe's expense during various side events. I have a hard time believing they are not aware of having dropped the ball in some key areas. They have some amazing and one of a kind tools that end up being handicapped by neglected code elsewhere in the application. I hope Lightroom and Photoshop don't go to far down this path and I point this out because I love the products and want to see them continue to flourish.
-
If LR is running real slow for you, ya gotta ask why...are you trying to do too much in LR that really should be done in Photoshop?
Just scrolling a large number in Grid, too slow!
-
Try this experiment: Process a raw file in lightroom to make it fairly dark, or even black, take it as a smart object into photoshop and then try using the exposure tool (or any other) to get it back to it's original brightness. You won't be able to do it without at the very least introducing banding or some other color issues.
Of course, that is a very good example of what you should not be doing in a pixel editor, starting with the fact that unless you take extra steps, you are first adjusting exposure with linear gamma (LR) and then "reverting" back in non-linear gamma. In addition, I'm not 100% sure that LR just adust exposure in a linear fashion when you move the exposure slider (just as a scalar multiplication of the raw channels).
In any case you (larkis) raise very good points about the issues in adobe applications that other products have overcome.
Just scrolling a large number in Grid, too slow!
Definitely! and that doesn't require scientific experiments unless you are in denial mode, but then you wouldn't aknowledge hard evidence anyway.
-
Just scrolling a large number in Grid, too slow!
I don’t scroll...I use page down...thats faster :-)
-
Some of the optimisations introduced in LR 7.x can slow down the application depending on the workflow and hardware configuration that are used.
If I import RAW files from an SD card and generate 1:1 previews in parallel, both processes will compete for access on the hard drive where the data is imported. In my case, using a 7200 rpm hard drive to store RAW files and a SATA SSD to store the catalogue, I see that imports are slower than in LR 6.x, where both operations are performed sequentially. There are workarounds to address this issue but that means I would have to change my current import workflow.
Independently of such border cases, I subjectively feel that the application in 7.x builds is getting slower with tasks which used to be done quickly (browsing the catalogue in the grid view). Long sessions in LR can be problematic. The application needs to be restarted more often to reclaim memory and recover basic user interface responsiveness.
Cheers,
Fabien
-
I don’t scroll...I use page down...thats faster :-)
Yeah, but I got to move my hand off of the mouse, which I scroll with the wheel, up to the keyboard or move the other hand which is resting on the arm rest. Requires a lot of effort compared to just using the middle finger on the mouse.
Lazy Larry
-
If I import RAW files from an SD card and generate 1:1 previews in parallel, both processes will compete for access on the hard drive where the data is imported. In my case, using a 7200 rpm hard drive to store RAW files and a SATA SSD to store the catalogue, I see that imports are slower than in LR 6.x, where both operations are performed sequentially.
You can disable the generation of previews in parallel in the preferences
-
I don’t scroll...I use page down...thats faster :-)
That's sufficient evidence to prove there is a performance problem with the software
-
That's sufficient evidence to prove there is a performance problem with the software
Not really if you understand what an app must do to generate the display image rolling up compared to a full page regeneration. But hey, I'm just trying to let you know how I work as efficiently as possible...I really hate trying to track rows of previews vs an entire page of previews. And with my programable mouse, I can page down with a single click of a button which even lazier than using my middle finger.
Just sayin'
-
There are several approaches to generate the display rolling up. Just compare it to Capture One, which uses a different approach, if you move the scroll bar too fast, it will not generate the previews until you stop or slow down. LR on the other hand, looks like it wants to generate the display for every single line you move and freezes the UI
Edit: And if you want to see how fast it could be, just try FastRawViewer
-
LR on the other hand, looks like it wants to generate the display for every single line you move and freezes the UI
Yep...that's why I use the page down.
Not only is it quicker to edit a page at a time, it doesn't piss me off because it's not as "fast" as it should be. Rather than fight with LR, I just learn how to use it in the most efficient manner as possible.
Seems like a lot of people complain about the way things are...I try to take advantage of the way things are. It's a lot less frustrating and more enjoyable.
-
Seems like a lot of people complain about the way things are...I try to take advantage of the way things are. It's a lot less frustrating and more enjoyable.
Well, I think there are two discourses here, on one side is how to make the most of what is available, and in regards to that, I agree completely with you.
on the other side, the discussion is why it cannot be improved if others have succeded? Don't get me wrong, I use many Creative cloud apps and like them a lot, but that does not mean that I would not criticize certain issues with them, and the same with Capture one or any other tool I use.
-
I don’t scroll...I use page down...thats faster :-)
NOT fast enough Jeff! This is what I see below doing so; lots and lots of blank thumbnails. All the time. LR's Library is too DAM slow :-[ . Compare this behavior to say Fast Raw Viewer and LR seems like a sad joke.
https://www.fastrawviewer.com/about-and-features
NIGHT and day difference in performance. Even Apple's Photo's is vastly faster.
This is a very sad joke:
-
NOT fast enough Jeff! This is what I see below doing so; lots and lots of blank thumbnails. All the time. LR's Library is too DAM slow :-[ . Compare this behavior to say Fast Raw Viewer and LR seems like a sad joke.
https://www.fastrawviewer.com/about-and-features
NIGHT and day difference in performance. Even Apple's Photo's is vastly faster.
This is a very sad joke:
I'm puzzled - how do you reproduce this problem? I have 39000 pictures in my library. I click on all photographs in the library and can drag the the bar at the side of the thumbnail view up and down to my hearts content and never a blank thumbnail. I can scroll down with the wheel on my mouse and ditto but not as fast as dragging the bar. Wherever I stop I can click on thumbnail and pre-view opens instantly. For reference I have a Windows 10 laptop with I7-8750H processor, Nvidia GTX1060 graphics, 32Gig 2400MHz RAM, 500GB Samsung 970 EVO M2 drive holding operating system, applications and Lightroom .lrcat files etc. The original pictures are on 1Gig Ethernet connected NAS.
Is this problem restricted to Apple? I don't remember having this problem on my old much less powerful desktop either.
-
NOT fast enough Jeff! This is what I see below doing so; lots and lots of blank thumbnails. All the time. LR's Library is too DAM slow :-[ . Compare this behavior to say Fast Raw Viewer and LR seems like a sad joke.
https://www.fastrawviewer.com/about-and-features
NIGHT and day difference in performance. Even Apple's Photo's is vastly faster.
This is a very sad joke:
When you and others compare the speed of Library functions between Lr and several other applications, just curious to know whether it's an apples to apples comparison, in terms of the kind of previews being constructed and other stuff that may be happening in the one but not the other - I have no idea and I'm not particularly beset with this problem, but just interested in knowing whether the discussion is based on valid comparisons.
-
I turned off the use of "Windows Ink" and that helped my develop module immensely! YMMV...
-
How did you disable Windows Ink? Doesn't seem straightforward.
Thanks
-
You can disable the generation of previews in parallel in the preferences
Thanks Frank, this should solve my import issue!
As for the Fast Raw Viewer comparison, library functions are likely to be different between applications (size of previews), but that doesn't explain why what used to be reasonably fast in LR is now much slower. Looking at what might have changed on the PC since LR 6.x, LR might be taxed more than other applications by Spectre and Meltdown mitigations since it constantly accesses storage. I fear that the rest is self-inflicted by Adobe.
Cheers,
Fabien
-
This thread, and similar threads regarding performance and other Adobe product issues just takes me back to Schewe's thread started several years ago: "If Thomas designed a new Photoshop for photographers now..."
https://forum.luminous-landscape.com/index.php?topic=78240.0
There is a strong case to be made that Photoshop (and perhaps Lightroom) needs a fresh approach with a modern codebase in the age of faster computers and GPUs and larger and larger image files. This, in contrast to Adobe's more recent emphasis on things like editing raw files on your iPad.
Not all companies have the knowledge, resources and industry influence to accomplish such a feat, but Adobe is one of the few companies that does have what it take to revolutionize the photographic and image processing workflow and toolset.
One can wish.
kirk
-
How did you disable Windows Ink? Doesn't seem straightforward.
Thanks
In the "orientation settings" of my Wacom pen tablet..
Also, if you don't have a Wacom tablet, you can Google "disable Windows ink" and find ways...
-
My system is near new with an i7-8700 CPU; 16GB RAM; OS & programme files & catalog on a Samsung SSD (MVie?) drive and raw files on a reasonably fast 4TB HDD. No GPU card and relying just on the Intel integrated graphics. I'm running two screens, Samsung 1920x1080 for menus (sliders) or in grid mode, and a 24 inch 1920x1200 Eizo as the main screen. Looking at the resource monitor, my CPU is running at close to 100% (4.2GHz) when processing, but RAM is rarely more than 12GB, only when doing large panorama merges. I do notice that the RAM usage is about 30% when I first start LR and then gradually creeps up over 50%, at which point I restart LR.
I understand that LR does not benefit much from GPU acceleration. The Intel graphics does not seem to get much over 10% according the resource monitor and I don't notice much difference if it is switched on or off. Happy to be corrected and get a GPU.
Is LR Classic CC 7.1 that much faster?
Thanks, Bob
There have been steady performance gains. I’m running LR 7.5 on a 2018 MacBook Pro, 2.9ghz i9 (6 core), 2TB SSD (Incredibly fast), 32 gigs of Ram, with a Radeon Pro 560x internal GPU, and when at home running a Radeon RX Vega 56 eGPU. Connect to 2 30” NEC displays running at 2560x1600.
I see little issues moving from image to the next, zooming to 100% is often instant and rarely takes more than a couple of seconds. I see no lag in scrolling a window in grid mode, over 1000 images in the grid, and I can scroll as fast as I want with no blanks and no lag. My images are from an IQ180 and IQ3 100 back, so 80 and 100mp captures.
Unfortunately I can’t tell what parts of my system are contributing to having better success than you seem to be having. I would suspect 16 gigs of ram is pretty sparse (despite what your system is reporting), I think LR uses the GPU a little more than some realize, and it can’t hurt that my SSD sustained reads are > 2500 MB/s. And I’m pretty sure version 7 is able to utilize multiple cores better than version 6.
-
There have been steady performance gains. I’m running LR 7.5 on a 2018 MacBook Pro, 2.9ghz i9 (6 core), 2TB SSD (Incredibly fast), 32 gigs of Ram, with a Radeon Pro 560x internal GPU, and when at home running a Radeon RX Vega 56 eGPU. Connect to 2 30” NEC displays running at 2560x1600.
I see little issues moving from image to the next, zooming to 100% is often instant and rarely takes more than a couple of seconds. I see no lag in scrolling a window in grid mode, over 1000 images in the grid, and I can scroll as fast as I want with no blanks and no lag. My images are from an IQ180 and IQ3 100 back, so 80 and 100mp captures.
As far as I can tell, when you open a folder or collection, LR will read the preview files from disk and will freeze the application momentarily if waiting for the data. Once the previews are loaded, then it works well. In your case you likely have new NVMe disks, which are incredibly fast, so you would probably not experience these issues.
Having enough resources helps for sure. It is more an issue of comparing LR performance with competing apps doing similar tasks (like C1)
-
This thread, and similar threads regarding performance and other Adobe product issues just takes me back to Schewe's thread started several years ago: "If Thomas designed a new Photoshop for photographers now..."
https://forum.luminous-landscape.com/index.php?topic=78240.0
There is a strong case to be made that Photoshop (and perhaps Lightroom) needs a fresh approach with a modern codebase in the age of faster computers and GPUs and larger and larger image files. This, in contrast to Adobe's more recent emphasis on things like editing raw files on your iPad.
Not all companies have the knowledge, resources and industry influence to accomplish such a feat, but Adobe is one of the few companies that does have what it take to revolutionize the photographic and image processing workflow and toolset.
One can wish.
kirk
I wonder if this new application is Lightroom CC (the newer edition, not the classic one). We might never know for sure, unless someone not under NDA can share this information.
Cheers,
Fabien