Luminous Landscape Forum
Raw & Post Processing, Printing => Adobe Lightroom Q&A => Topic started by: rdonson on July 21, 2017, 06:46:45 pm
-
What are the Lightroom performance improvements you'd like to see?
-
I'd like to see the local adjustment functions (brush, graduated filter) provide all the editing tools available in the overall editing toolbox. I'd also like to see the Print Module allow for selection of Saturation and Absolute Rendering Intents. In the Print Module again, I would like to be able to position photos on the custom grid using the arrow keys on my keyboard so that they can be positioned in a very controlled, granular manner (compared with the less precise click and drag method). In the Develop Module, I would like to see the ability to clone/fill into empty space created by some of the Upright adjustments (doable in Photoshop with Content Aware Fill by selecting the empty space and filling it). In the print module I would like to see easier and more accessible ways of adding text to prints.
-
Adobe and Ron seem to be talking about performance rather than productivity.
One I have sought since v1, is the ability to use embedded previews in Library, just like PhotoMechanic and Aperture.
-
Adobe and Ron seem to be talking about performance rather than productivity.
That's fine, but I think it's important to put all of it on the table whether asked for or not. To me, what the application DOES is at least as important as how efficiently it does whatever it can do and Adobe needs to be reminded that customers have "productivity" views that were raised at one time or another but not yet implemented. In other words: at least in this Forum, let's expand the discussion to ALL that matters.
-
One I have sought since v1, is the ability to use embedded previews in Library, just like PhotoMechanic and Aperture.
Ditto ... we were asking for that as far back as the v1 public beta ... still no response as to any potential inclusion for consideration.
Another item I have been requesting for over a decade now is the option to only import images that were Flagged/Marked/Protected in camera. That alone could save copious amounts of time when working on tight deadlines.
-
One I have sought since v1, is the ability to use embedded previews in Library, just like PhotoMechanic and Aperture.
I can't see why that would be advantageous.
In the library I want to see the images as I've edited(corrected) them, not raw.
-
I can't see why that would be advantageous.
In the library I want to see the images as I've edited(corrected) them, not raw.
I can't speak for John, but ... several other apps do or have done this and it is invaluable when performing first cull on large imports ... not for viewing past works. Then, of course we do want the Lr generated previews reflecting the results of the efforts performed. It would be nice to turn off the process at the beginning of the process.
Waiting needlessly for Lightroom to build previews when the embedded previews are more than adequate for checking focus accuracy, basic tonal evaluation and composition.
Anyone who has used Photo Mechanic or Aperture where you could use this procedure, would see the value of increased speed for the initial import for meeting stringent deadlines for publication when working with larger volumes of images for sports, news and event coverage.
-
Yes, Photo Mechanic is a great application for very speedy mounting and viewing of large numbers of photos. But don't you think LR does an adequately fast job of displaying the photos to be imported before one starts the import process?
-
I would like to see the local adjustments not bog down the LR system so heavily. Maybe a scratch disk could do that?
-
Yes, Photo Mechanic is a great application for very speedy mounting and viewing of large numbers of photos. But don't you think LR does an adequately fast job of displaying the photos to be imported before one starts the import process?
In a word, no.
-
it is invaluable when performing first cull on large imports ... not for viewing past works.
My point exactly. It would probably be helpful to use the embedded jpgs in the import dialogue, but not in the library itself.
-
I'd like to see the local adjustment functions (brush, graduated filter) provide all the editing tools available in the overall editing toolbox. I'd also like to see the Print Module allow for selection of Saturation and Absolute Rendering Intents. In the Print Module again, I would like to be able to position photos on the custom grid using the arrow keys on my keyboard so that they can be positioned in a very controlled, granular manner (compared with the less precise click and drag method). In the Develop Module, I would like to see the ability to clone/fill into empty space created by some of the Upright adjustments (doable in Photoshop with Content Aware Fill by selecting the empty space and filling it). In the print module I would like to see easier and more accessible ways of adding text to prints.
I would like to see the ability to "name" each local adjustment pin.
Rand
-
I wonder how much of the performance penalty in Lightroom is due to its support for plugins?
If Adobe gave us the choice of "plugin support" to support "Develop" or "faster LR", which would most people choose?
-
I would like to see the ability to "name" each local adjustment pin.
Rand
Oh - goodness - glad you raised that! I would like to see those pins in the first place! They are all smallish gray dots and they often get lost in the image. I have raised this but so far goes unattended.
-
My point exactly. It would probably be helpful to use the embedded jpgs in the import dialogue, but not in the library itself.
Not necessarily. I want all my images in Lightroom, I really don't want to have to go through the import process twice. Software is supposed to offer solutions not more workarounds ... but I also don't want to wait around for Lightroom to build arbitrary thumbnails or hog resources in the background trying to catch up when the embedded jpegs are more than adequate.
Plus, I'm asking for this to be an optional setting. So if you wouldn't find it useful, you wouldn't have to employ it.
-
My point exactly. It would probably be helpful to use the embedded jpgs in the import dialogue, but not in the library itself.
Not really - that creates a huge bottleneck. For example, today I think I shot over 3000 images on 2 cards. If embedded JPEGs were only used in Import, I would only gain the benefit if I culled one card at a time in Import.
But the concept of Import is that it gets pictures off cards, backed up, and with common metadata - so you can then clear the cards and move on - while Library has a wide range of comparison and culling tools.
-
By the way, Import does already access the embedded preview.
-
Oh - goodness - glad you raised that! I would like to see those pins in the first place! They are all smallish gray dots and they often get lost in the image. I have raised this but so far goes unattended.
Set their display option to Auto. Then you just need to move the cursor in and out of the image to make the pins stand out.
-
Set their display option to Auto. Then you just need to move the cursor in and out of the image to make the pins stand out.
Yes thanks, I know about that; the same effect can be had by setting it to "Always" and turning the tool on and off. Either can be helpful in a sort of "now you see it - now you don't" sense, but when you don't, it's because the colour of the pin blends in to the colour of where it sits in the photo - often happens especially with a high density photo, so it isn't a complete solution. The complete solution would be to provide for multi-coloured pins. Shouldn't take those high-powered engineers all that much trouble to provide for this; but I suppose like much else people ask for, it's low on their pecking order of improvements to make.
-
How about allowing zoom while cropping?
-
How about allowing zoom while cropping?
YES!
-
How about allowing zoom while cropping?
+1.
It would be particularly useful while levelling images.
-
Yes, Photo Mechanic is a great application for very speedy mounting and viewing of large numbers of photos. But don't you think LR does an adequately fast job of displaying the photos to be imported before one starts the import process?
Not really. This is related to the question but adds Import to the mix.
Let me give you my use case.
I go on week long photo trips several times a year. Each day I'm taking hundreds of photos. When I come back to where I'm staying I load the photos into Lightroom from my SD card. The first time through this process is acceptable but it seems like it could be faster. The next day I'm using the same SD card and taking hundreds of photos. I return to where I'm staying and ask Lightroom to import my photos but to ignore those already imported. This is where things get kind of slow. Usually a cold drink or a warm chai helps me pass the time until it figures out which photos I can then import. Once that's done then the import is at its normal speed which still seems like it could be faster.
All this happens on a MBP with internal SSD and putting the photos on an external SSD over USB 3.
Yes, all I have to do it buy a week's worth of UHS-II SD cards and use only 1 card/day but that seems like a waste of money to overcome something that feels like Lightroom could be doing a faster job.
-
Yes, all I have to do it buy a week's worth of UHS-II SD cards and use only 1 card/day but that seems like a waste of money [b[to overcome something that feels like Lightroom could be doing a faster job.[/b]
Yes ... Anyone who has the experience and can recall how much faster and more efficient the import process was when using multiple cards over multiple sessions for Aperture is/was, as compared to Lightroom can attest what we are requesting/seeking is indeed possible because it existed years ago in competing products. It's not a matter of if it can be done. It's a matter of choosing to do it. Though I don't hold out much hope as many have been complaining about overall performance issues with Lr for nearly a decade and only now in mid-2017 has it become a 'priority' for Adobe.
-
Maybe the acceptability of the experience depends on one's downloading and cataloguing habits. At the end of each day of a photoshoot I download my card(s) to specially created folders on my hard-drive structured as subject main folder, then daily date/place per nested folder. Once they are downloaded in their correct permanent folder structure, which happens quickly, then I open Lr and import them folder by folder, creating separate similarly named collections per folder along the way. In this manner, there is no confusion between adding or not adding. The import process happens quickly; building Standard Previews take a bit longer, but that's OK. Once the photos are thereby sorted into their collections, I can then leisurely move through them collection by collection prune what gets removed from the collection, or removed from the catalog or trashed, and do my selects. This sequence allows for closer inspection as needed to make these decisions, rather than what one gets at the pre-import stage, and so far, the speed of each process is acceptable - at least to me.
-
Maybe the acceptability of the experience depends on one's downloading and cataloguing habits. At the end of each day of a photoshoot I download my card(s) to specially created folders on my hard-drive structured as subject main folder, then daily date/place per nested folder. Once they are downloaded in their correct permanent folder structure, which happens quickly, then I open Lr and import them folder by folder, creating separate similarly named collections per folder along the way. In this manner, there is no confusion between adding or not adding. The import process happens quickly; building Standard Previews take a bit longer, but that's OK. Once the photos are thereby sorted into their collections, I can then leisurely move through them collection by collection prune what gets removed from the collection, or removed from the catalog or trashed, and do my selects. This sequence allows for closer inspection as needed to make these decisions, rather than what one gets at the pre-import stage, and so far, the speed of each process is acceptable - at least to me.
Your workflow only appears to offer one flaw ... time. You seem to have ample time to allow Lightroom as much time as it needs to accomplish the task. Not all Lightroom users have that luxury.
Imagine if you will that you are shooting a high school or college football game doesn't kickoff until 7:30 or 8 p.m. Presses roll at 9:30 p.m. for your publication's sports section early edition and you have 20 minutes or during halftime to peruse the 300-500 images shot during the first half, properly keyword, label and accurately caption to AP style 4-6 images for print and another dozen or more for an online gallery ... and ... be back on the sideline to capture as much of the second half as possible then repeat the process for the late edition or other publications at game's end.
Folder structure and leisurely pace aside ... for some Lightroom users ... time IS money ... or the difference of who these publications may call to cover the next game.
I've been paying for Adobe licensing fees for over 25 years ... I don't think it is unfair or unreasonable to request features or workflow enhancements to Lightroom that can benefit my interests. If it were me, I wouldn't want my long time customers seeking options elsewhere. That's how you lose customers.
-
Your workflow only appears to offer one flaw ... time. You seem to have ample time to allow Lightroom as much time as it needs to accomplish the task. Not all Lightroom users have that luxury.
Imagine if you will that you are shooting a high school or college football game doesn't kickoff until 7:30 or 8 p.m. Presses roll at 9:30 p.m. for your publication's sports section early edition and you have 20 minutes or during halftime to peruse the 300-500 images shot during the first half, properly keyword, label and accurately caption to AP style 4-6 images for print and another dozen or more for an online gallery ... and ... be back on the sideline to capture as much of the second half as possible then repeat the process for the late edition or other publications at game's end.
Folder structure and leisurely pace aside ... for some Lightroom users ... time IS money ... or the difference of who these publications may call to cover the next game.
I've been paying for Adobe licensing fees for over 25 years ... I don't think it is unfair or unreasonable to request features or workflow enhancements to Lightroom that can benefit my interests. If it were me, I wouldn't want my long time customers seeking options elsewhere. That's how you lose customers.
[/quote
Sure, I'm not saying what's good for me is good for everybody. Everyone has different constraints so whatever timing of application performance is relatively immaterial for me may be a deal-breaker for some one else. I was just making the point that how one views the acceptability of an application's performance depends on one's workflow and requirements, giving myself as an example, definitely at the more leisurely end of the spectrum - but I have no illusions about the reality of time sensitivity for others.
-
Maybe the acceptability of the experience depends on one's downloading and cataloguing habits. At the end of each day of a photoshoot I download my card(s) to specially created folders on my hard-drive structured as subject main folder, then daily date/place per nested folder. Once they are downloaded in their correct permanent folder structure, which happens quickly, then I open Lr and import them folder by folder, creating separate similarly named collections per folder along the way. In this manner, there is no confusion between adding or not adding. The import process happens quickly; building Standard Previews take a bit longer, but that's OK. Once the photos are thereby sorted into their collections, I can then leisurely move through them collection by collection prune what gets removed from the collection, or removed from the catalog or trashed, and do my selects. This sequence allows for closer inspection as needed to make these decisions, rather than what one gets at the pre-import stage, and so far, the speed of each process is acceptable - at least to me.
Mark, my catalog and file structures are similar. For my week long photo trip the hierarchy is named after the trip. In my most recent example that would be 2017-07 Amherst VA. Underneath that folder is daily folders. For example, 2017-07-07, 2017-07-08, etc. It's really a simple structure. I want Lightroom to simply perform its tasks efficiently and quickly. This is easily done through the IMPORT menu items on the right hand side of the screen. Loading the files into structures outside of Lightroom seems like you're doing Lightroom's job for it unless I misunderstand your workflow.
One of the backbones of Lightroom is Digital Asset Management. In the corporate IT world we called it Enterprise Content Management. In banking we had all your documents ingested and could display them to your browser in subsecond response times. Just like Lightroom the files themselves resided on a file system and a relational database kept track of those documents. This wasn't rocket science although the magnitude of the work in large banks dwarfs what we do with Lightroom room by unimaginable magnitudes. Imagine a large bank with tens of millions of customers and all the documents associated with those customers.
From my perspective Lightroom simply isn't taking full advantage of the processors and faster storage devices we have these days. Perhaps it's their code base but honestly I don't know that much about Lightroom. I just feel that it should be performing better in 2017 for a number of tasks.
-
Loading the files into structures outside of Lightroom seems like you're doing Lightroom's job for it unless I misunderstand your workflow.
Hi Ron, no you probably didn't misunderstand. I know my procedure may have an element of redundancy. I just like to make sure I packed away all the raw files properly on my hard drive and its back-up drive before I start involving any other application with its attendant failure risks. It's just breaking down the tasks and doing each one the most direct, uninvolved way possible. Maybe a bit archaic and pedestrian but within my comfort zone :)
-
I also would like faster import/preview generation. The graphics card should have been used for preview generation years ago. Better use of all the cores in our CPUs would also make a difference.
I travel a lot and it is a pain to waste so much time for import every evening. To free up my cards faster I now use PhotoMechanic for import with backup to a separate drive, then I start import of the imported files via lightroom. If I need something fast I tag images in PM and only generates LR previews for those images in the field.
Another LR feature that annoys me is the dependency on internet.
When out traveling I would like a way to sync images to LR mobile on my iphone og ipad via cable. Today LR Mobile is totally useless in places without internet access (and there is no internet on a boat in the arctic or a safari camp in Masai Mara). I know i can export files and transfer with itunes to ipad but I would like to keep the adobe workflow.
-
For my preferences, I'd rather have Adobe work on performance of operations in the Develop module than any improvements during import. I typically copy my files from the cards to my disks, then perform a backup of these files and finally launch LR to import the files. While the import is in progress, I'll do other things like eat dinner, go out to a movie or even sleep. I'm in no rush getting the images into Lightroom, but once there and am working on the images, I'd like those operators to be more snappier than they are today. Import is a one time thing...working on the images is much more time consuming fornme...and I can't do anything else than wait for an operator to finish.
-
For my preferences, I'd rather have Adobe work on performance of operations in the Develop module than any improvements during import. I typically copy my files from the cards to my disks, then perform a backup of these files and finally launch LR to import the files. While the import is in progress, I'll do other things like eat dinner, go out to a movie or even sleep. I'm in no rush getting the images into Lightroom, but once there and am working on the images, I'd like those operators to be more snappier than they are today. Import is a one time thing...working on the images is much more time consuming fornme...and I can't do anything else than wait for an operator to finish.
+1
Cheers,
Bart
-
For my preferences, I'd rather have Adobe work on performance of operations in the Develop module than any improvements during import. I typically copy my files from the cards to my disks, then perform a backup of these files and finally launch LR to import the files. While the import is in progress, I'll do other things like eat dinner, go out to a movie or even sleep. I'm in no rush getting the images into Lightroom, but once there and am working on the images, I'd like those operators to be more snappier than they are today. Import is a one time thing...working on the images is much more time consuming fornme...and I can't do anything else than wait for an operator to finish.
+2
-
For my preferences, I'd rather have Adobe work on performance of operations in the Develop module than any improvements during import. I typically copy my files from the cards to my disks, then perform a backup of these files and finally launch LR to import the files. While the import is in progress, I'll do other things like eat dinner, go out to a movie or even sleep. I'm in no rush getting the images into Lightroom, but once there and am working on the images, I'd like those operators to be more snappier than they are today. Import is a one time thing...working on the images is much more time consuming fornme...and I can't do anything else than wait for an operator to finish.
Once again, it would be so awesome to have the luxury of expending all the time necessary for the ingest/importation process ... if I could only go take a nap while Lightroom churns out the the previews and adds the metadata to the catalog.
Conversely, I have not experienced any detrimental slowness or performance hits once I get images in the Develop module. So the reality of the performance issues is that it isn't a one-size-fits-all situation. Our individual workflows are diverse and Adobe's efforts in providing solutions should reflect that diversity. Otherwise, why offer Lightroom as anything more than a Develop module?
-
From my perspective everything mentioned for performance improvements should be addressed. We shouldn't have to prioritize the importance of any of these weak points. They are all important. The fact that anyone has developed workarounds for bad performance in IMPORT doesn't mean we should dismiss the need to get it straightened out so they can focus on another module in Lightroom. Let's not lose sight that Lightroom has 7 modules. I'm pretty sure I've heard gripes about each of them.
- Library
- Develop
- Map
- Book
- Slideshow
- Print
- Web
-
Once again, it would be so awesome to have the luxury of expending all the time necessary for the ingest/importation process ... if I could only go take a nap while Lightroom churns out the the previews and adds the metadata to the catalog.
Conversely, I have not experienced any detrimental slowness or performance hits once I get images in the Develop module. So the reality of the performance issues is that it isn't a one-size-fits-all situation. Our individual workflows are diverse and Adobe's efforts in providing solutions should reflect that diversity. Otherwise, why offer Lightroom as anything more than a Develop module?
That's exactly right Butch, we all have our different priorities and all should be heard...
-
That's exactly right Butch, we all have our different priorities and all should be heard...
Of course we all should be heard, but Adobe or our fellow users need not relegate addressing such issues to a zero sum gain.
Seeking performance enhancements in various aspects of Lightroom need not be a competition.
I seriously doubt you would be dismayed if the import/ingest process and the Library module would be more efficient as I would not be disappointed with improvements in the Develop module. There can be and should be room for both aspects as both are intrinsic to one another and utilized by every Lr user.
-
Of course we all should be heard, but Adobe or our fellow users need not relegate addressing such issues to a zero sum gain.
Seeking performance enhancements in various aspects of Lightroom need not be a competition.
I seriously doubt you would be dismayed if the import/ingest process and the Library module would be more efficient as I would not be disappointed with improvements in the Develop module. There can be and should be room for both aspects as both are intrinsic to one another and utilized by every Lr user.
Sure in an ideal world...magically everything about LR will become lightening fast, but unfortunately we live in the real world where priorities need to be applied. I vote to focus on the develop module as a first priority. You can vote whatever you desire. Adobe will need to take all the votes in and determine their priorities and where to focus their development dollars.
-
Sure in an ideal world...magically everything about LR will become lightening fast, but unfortunately we live in the real world where priorities need to be applied. I vote to focus on the develop module as a first priority. You can vote whatever you desire. Adobe will need to take all the votes in and determine their priorities and where to focus their development dollars.
Also in the real world, a vote for one improvement need not automatically translate into a vote against another aspect. While I don't think any business has infinite resources, I also think a multinational corporation that measures their revenues ... and profits in factors of billions of dollars have the means to address most concerns all users have in the area of performance improvements.
After all, if you have time to sleep while importing your images, I doubt you'd be impacted negatively, regardless of which area Adobe should focus their development dollars.
-
For my preferences, I'd rather have Adobe work on performance of operations in the Develop module than any improvements during import. I typically copy my files from the cards to my disks, then perform a backup of these files and finally launch LR to import the files. While the import is in progress, I'll do other things like eat dinner, go out to a movie or even sleep. I'm in no rush getting the images into Lightroom, but once there and am working on the images, I'd like those operators to be more snappier than they are today. Import is a one time thing...working on the images is much more time consuming fornme...and I can't do anything else than wait for an operator to finish.
Do you use a machine with graphics card acceleration?
On my laptop the develop module is flying, even with files from D810.
My problem is that preview generation and showing these previews when I open in develop is slow. Those features are as far as I know not hardware accelerated yet.
-
Also in the real world, a vote for one improvement need not automatically translate into a vote against another aspect. While I don't think any business has infinite resources, I also think a multinational corporation that measures their revenues ... and profits in factors of billions of dollars have the means to address most concerns all users have in the area of performance improvements.
After all, if you have time to sleep while importing your images, I doubt you'd be impacted negatively, regardless of which area Adobe should focus their development dollars.
Butch...don't get so excited. I never said anything about not wanting improvements during the import phase...it's just if we are voting I choose to focus on the develop module as I am in that module a lot more than import.
As far as Adobe being a big company...yes they are, but they also have an awful lot of products to manage which require an awful lot of resources. And typically product groups are smallish teams and adding a bunch of resouces to a team usually leads to a disaster.
-
The place for "voting" was the Adobe Lr survey. It does little good to "vote" here.
Why don't we just unearth and discuss ALL performance Lr improvements needed here in this thread.
-
The place for "voting" was the Adobe Lr survey. It does little good to "vote" here.
Why don't we just unearth and discuss ALL performance Lr improvements needed here in this thread.
OK Ron, you started this thread and maybe it would be good if you could clarify what in your mind were the "Terms of Reference" for this discussion. By "performance", did you mean to limit the discussion to matters of process efficiency (for example speed), or did you also mean the effectiveness on outcomes of existing features and the desirability of new features to improve application effectiveness?
Of course Adobe has its own forums for these discussions, but having a discussion here is useful for all those who don't partake of those resources and thereby to broaden the audience for those interested in Lr's future development.
-
Fair enough, Mark. Thanks for asking.
Background: I recently upgraded to a 27" iMac - 4.2 GHz quad core i7, 512GB SSD, 40GB RAM and Radeon Pro 580 8GB VRAM. It replaced a 6 year old 21.5" iMac with quad core i5, 16GB RAM, 512GB HD and a modest graphics card. I was surprised that many things in Lightroom weren't all that quicker on the new machine. Then Hogarty sent out his missive that Adobe wanted to know our concerns about Lr performance and a survey was available. I provided my feedback in the survey. I wondered what others were thinking on this topic.
My concerns were limited to speed of existing features. I really didn't think about workflows not prescribed by the Lr features. I was simply interested in what other people were experiencing with regards to performance. I thought that sharing experiences might be useful and we might gain insight and perhaps some tuning tricks in configuration or preferences.
Responses detailing alternate workflows that alleviate some performance problems were/are interesting as long as we all understand the underlying performance issue being worked around.
I'm open to expanding things to include effectiveness of outcomes and probably to new features to improve application effectiveness as long as it's reasonable and not fantasy stuff or digs on Lr because product XXX does something better. The later seems to lead down a rat hole.
If someone wants to indicate that they're experiencing the same performance concerns that's valuable and confirmation of the problem. I don't find value in "voting" on performance problems to be addressed. Perhaps that's bias or misunderstanding on my part though but I don't think it's of much use for people in this forum to try to prioritize Adobe's tasks by "voting".
This is where I'm at and I'm open to all thoughts on this.
-
... I don't think it's of much use for people in this forum to try to prioritize Adobe's tasks by "voting".
I agree ... a cursory 'vote' for improvements to Lr performance in a particular aspect should not be equated as a vote against performance improvements elsewhere in the app. We aren't electing a politician, we are pointing out the problem areas and performance bottlenecks that users experience. Each user contributes equally for their licensing fees, so one 'vote; should never be of more value than another.
-
OK Ron thanks - that's helpful context for orienting the discussion. And I agree, none of this should be an issue of "voting" - it's useful for sharing experience and suggesting options. Some of these ideas should likely end-up in the Adobe Lr Forum from where there would be greater probability of uptake.
-
... I recently upgraded to a 27" iMac - 4.2 GHz quad core i7, 512GB SSD, 40GB RAM and Radeon Pro 580 8GB VRAM. It replaced a 6 year old 21.5" iMac with quad core i5, 16GB RAM, 512GB HD and a modest graphics card. I was surprised that many things in Lightroom weren't all that quicker on the new machine.
Because Lr/PS are not CPU limited (and not RAM limited either if you already had 16GB). More 'horsepower' does not equate here to higher performance... Higher performance will come from parallelism being taken advantage of in the core code.
-
Because Lr/PS are not CPU limited (and not RAM limited either if you already had 16GB). More 'horsepower' does not equate here to higher performance... Higher performance will come from parallelism being taken advantage of in the core code.
Please help me understand. So doubling clock speed and hyper threading, faster RAM and a dramatic improvement in GPU speed and VRAM are of little value in Lr/PS?
-
I restate... Lr/PS performance has not been CPU limited by recent (10 years or newer) hardware. Sure, if you use performance metrics, specific processing is faster with faster CPUS, but it does not make any perceived difference to the end user, especially in the editing stage. Where you will notice an improvement is in batch processing - exporting a bunch of images, for example.
I bet that Adobe is working on core performance improvements, such as using multiple CPU cores, and parallelism. That will make the app snappier.
-
Thanks for your response.
There are many things where I think CPU performance should show dramatic improvements such as building previews but I don't see a marked difference.
Adobe has said for a long time that PS and Lr supports multiple cores. Perhaps their use of the cores and hyperthreading isn't where it should be.
This article caught my attention a while back with regards to performance.
https://www.pugetsystems.com/labs/articles/Adobe-Lightroom-CC-6-Multi-Core-Performance-649/
-
https://www.pugetsystems.com/labs/articles/Lightroom-CC-2015-10-1-CPU-Comparison-Skylake-X-Kaby-Lake-X-Broadwell-E-Kaby-Lake-Ryzen-7-973/ is more recent
-
Thanks, John, for the more recent test results!
-
John - Thanks from me as well. One hopes Adobe will start better using the multiple cores coming to workstations from Intel and AMD. For grins I tried running LR on one of our Broadwell-EP servers used for ICC profile calculations. Despite having eight times as many cores and sixteen times more memory than an i7 Kaby Lake system, the server crawled through both imports and conversions. A base clock only half the desktop's cratered performance.
Your comparison test shows Intel systems handily besting AMD's latest on Windows. I wonder how much of this is a result of Intel being more responsive at pushing compiler optimizations into Visual Studio and how much is purely processor.
-
https://www.pugetsystems.com/labs/articles/Lightroom-CC-2015-10-1-CPU-Comparison-Skylake-X-Kaby-Lake-X-Broadwell-E-Kaby-Lake-Ryzen-7-973/ is more recent
LOL, the LR machine that they have configured is almost identical to the one I built for my new workstation 18 months ago for less than 1/2 of what this one is priced at.
-
LOL, the LR machine that they have configured is almost identical to the one I built for my new workstation 18 months ago for less than 1/2 of what this one is priced at.
RAM has doubled in price in less than 12 months. Plus those guys have a business to run. Some people find their services add value they truly need, such as the system validation, after sales service, etc. I'm not one of them, because like you I prefer to build my own machine and save the $$. Meanwhile, I'm happy to read their benchmark results :D
-
https://www.pugetsystems.com/labs/articles/Lightroom-CC-2015-10-1-CPU-Comparison-Skylake-X-Kaby-Lake-X-Broadwell-E-Kaby-Lake-Ryzen-7-973/ is more recent
Looking at the charts it's seems that modest gains (10-17%) in performance are seen between generations of Core I7, 4 core processors. I guess that's to be expected. It seems looking at this and the previous tests that Lightroom really doesn't take advantage of more than 4 cores, not that many of us would go that route anyway.
It also seems that any real performance gains that we might like to see will depend on Adobe programming expertise and efforts.
Now.... back to your favorites for Lr performance improvement candidates. Where would you like to see improvements?
-
Now.... back to your favorites for Lr performance improvement candidates. Where would you like to see improvements?
For me, I would have to say brushings.. That and stopping the lag when using the Wacom with Windows Ink enabled (to allow for pressure sensitivity) - PS fixed it, so why is it taking years to fix it in LR.
As for the brushings, that includes any brushing, be it adj brush, radial brushing, grad brushings. I always have to stop any pointer movement for anything to show up at all. Sure, there are workarounds - disabling this, disabling that - but they are still just that: workarounds. Also the speed of doing anything else after there are a lot of local adjustments, is dreadful.
I keep wondering how in the hell could professionals be using LR with all it's performance deficits. I'm just an enthusiast and I can't stand the speed. How professionals can be using this, just boggles my mind. My guess is workarounds galore.
-
Well said. I experience the brushing lag you site as well. The only workaround I've found is to the exit and restart Lightroom. That's more than annoying for me.
-
I keep wondering how in the hell could professionals be using LR with all it's performance deficits. I'm just an enthusiast and I can't stand the speed. How professionals can be using this, just boggles my mind. My guess is workarounds galore.
Because not everyone has problems?
Despite two or three reminders, where's the flood of replies suggesting favourite Lr performance improvement candidates? Maybe that's because the experience is varied. Your specific issue sounds driver-related and I see nothing like it on my system (I did have crashes caused by the latest AMD drivers which AMD fixed with an update), but I do get slowdowns in Develop with lots of spotting corrections on a single image.
Other problems are more in Adobe's realm. For instance:
- Deleting all the History recently solved a severe slowdown on a client's catalogue. So one favourite candidate would be that Lr should automatically cull History in some way.
- Another seems specific to one brand of camera, Fuji. Exporting from Fuji raw files takes 40% longer than from DNGs made from those files. So there are opportunities in caching.
- Another was introduced by third parties - accessing presets. I recently found that some users of my X-LR plugin found it started very slowly on systems with lots of third party Develop presets, especially the ludicrously-expensive ones like VSCO. I believe preset encryption caused the issue, so maybe Adobe could greatly reduce the number of calls to the list of presets (every time you select an image, Lr tries to see if it matches an existing preset - does it need to do this at all?).
- Raw data is accessed unnecessarily and multiple times, so could Develop automatically create smart previews, standard and 1:1's, and could Export use previews (eg if you export full size it should use a 1:1 preview if it's up-to-date and of enough quality).
These are four of mine, as well as using embedded previews, but notice how diverse they are.
John
-
John, thanks for responding to Hoggy.
I have experienced lagging when doing lots of brushwork on my new 27" iMac with an AMD Radeon Pro 580 with 8GB of VRAM. That's not specifically listed by Adobe as supported/tested although it far exceeds their minimal requirements. https://helpx.adobe.com/lightroom/kb/lightroom-gpu-faq.html
Anyway, the next time it happens I'll try your suggestion to delete some of the history states as a workaround until Adobe fixes the underlying problem.
-
Because not everyone has problems?
... I see nothing like it on my system
Same here.
The only thing that responds slowly on my system when in develop is the colour temperature controls.
Spotting ceased to be an issue anyway when I got a DSLR with a self cleaning sensor ...... 7 years ago now.
-
Anyway, the next time it happens I'll try your suggestion to delete some of the history states as a workaround until Adobe fixes the underlying problem.
The history deletion is not a standard fix, Ron. This client has a big catalogue, 650k+ images, growing 2-3000 a week, and with 10 years of edits. The recent slowdown was very strange and I'd tried all sorts of things before I remembered hearing of a corrupt history table - so we rolled that dice. In Develop we selected all the images, then ran the Develop > Clear History menu command and eventually (30 minutes later) restarted LR. The catalogue shrank to 8gb from its previous 17gb and performance was back to normal. So it's an abnormal fix. It does though point to an opportunity for Adobe - people don't need history accumulating forever, and milestones like "Printed on YYMMDD" might be preserved while removing individual steps after a few days or weeks.
-
The history deletion is not a standard fix, Ron. This client has a big catalogue, 650k+ images, growing 2-3000 a week, and with 10 years of edits. The recent slowdown was very strange and I'd tried all sorts of things before I remembered hearing of a corrupt history table - so we rolled that dice. In Develop we selected all the images, then ran the Develop > Clear History menu command and eventually (30 minutes later) restarted LR. The catalogue shrank to 8gb from its previous 17gb and performance was back to normal. So it's an abnormal fix. It does though point to an opportunity for Adobe - people don't need history accumulating forever, and milestones like "Printed on YYMMDD" might be preserved while removing individual steps after a few days or weeks.
Indefinite retention of those history steps is a great feature of Lr that comes in very handy when re-working photos to suit different purposes or interpretations, so I would like to always have the option of retaining them or deleting them, perhaps on a per photo or batch basis.
-
Indefinite retention of those history steps is a great feature of Lr
+1
It sounds what would be a better addition is a function or utility to check and repair the part of the database that holds the history steps.
milestones like "Printed on YYMMDD" might be preserved
OTOH this isn't a 'milestone' for me at all, or any other export function either. I'd like the option to switch off logging this sort of unimportant clutter.
-
It's far from unimportant clutter because it's essential if you ever want to go back and rework that print or supply an exact copy of a file, but these milestones and the entire History panel's value is limited by not being searchable. Imagine if you could filter on which images you've not exported, or find images with ISO>1000 and no NR step. But I've given up on Adobe ever providing that searchability and would be quite content with automated History culling if it's part of tuning performance.
-
I have experienced lagging when doing lots of brushwork on my new 27" iMac with an AMD Radeon Pro 580 with 8GB of VRAM. That's not specifically listed by Adobe as supported/tested although it far exceeds their minimal requirements. https://helpx.adobe.com/lightroom/kb/lightroom-gpu-faq.html (https://helpx.adobe.com/lightroom/kb/lightroom-gpu-faq.html)
Anyway, the next time it happens I'll try your suggestion to delete some of the history states as a workaround until Adobe fixes the underlying problem.
Since you notice this too, and in case you hadn't heard, and because you started this thread.. ;)
The slew of workarounds to reduce or eliminate the lag when making brush strokes can be a combination of things to try. Turn off GPU acceleration, turn off any crop rotation, turn off lens profile corrections including distortion from the manual tab - in the transform panel, turn off upright and turn off any manual transforms.
Whew! Am I forgetting anything? :o Some of these things may be so ingrained that people may have already incorporated the workarounds into their workflow, and not notice them anymore.
...........
As far as the history steps go, I find that after any amount of time the steps don't mean anything to me anyways.. And they tend to really bloat the catalog size as each step seems to be an internal snapshot. What I do instead, is to use snapshots - in which I can put much more useful information in there than a slew of absolute steps taken. Like what was done, and/or what I was trying to accomplish, and/or what I still need to do. Whenever I might export/share, I use JF's Snapshot-on-Export/share facilities to 'set it in stone' - unfortunately for those that print, there is nothing similar for printing other than doing it manually. (EDIT: And as implied, about 99% of the time, I'll then clear the history panel after making the snapshot.)
-
Whew! Am I forgetting anything? :o Some of these things may be so ingrained that people may have already incorporated the workarounds into their workflow, and not notice them anymore.
I didn't miss anything. The workarounds are noted and are NOT a substitute for Adobe addressing the issue(s).
-
It's far from unimportant clutter
To you maybe.
But that was your point. What's important to one user is clutter to another. Which is why getting development of the product suiting everyone is so difficult.
-
What's important to one user is clutter to another.
Which is why any performance benefit from wiping History needs to preserve the milestones. It's a balance of needs.
-
To you maybe.
.................... getting development of the product suiting everyone is so difficult.
Sure, but one effective way to mitigate this circumstance is to provide for options in Preferences. I'm not a programmer, nor do I know much about how operating systems process instructions, nonetheless it seems reasonable in a case like this to surmise that a user-selected preference could be structured within Lr to either maintain or scrap history steps in batches of photos and that when the "scrap" option is selected, history steps would be treated say, like they are in Photoshop. But all this presumes history steps do cause the application to slow down. Do we have any real evidence of this being the case? Or is it circumstantial evidence based on correlation of variables that may not be correlated under the hood?
-
But all this presumes history steps do cause the application to slow down. Do we have any real evidence of this being the case? Or is it circumstantial evidence based on correlation of variables that may not be correlated under the hood?
I provided one when I introduced the topic, though I do not think there is any general evidence that a large accumulation of history steps does impact on performance. Adobe will probably be looking for general and specific/exceptional performance issues.
-
The most infuriating slow feature of LR, well maybe not the most, but it bugs me every time I start the app. The slowness with which the image counts are displayed in the Folders panel of the Library module. What is going on here? The number of files has not changed since I shut down. It isn't going to change the number if I have added files to the OS folders while it was shut down. And even if I have disconnected the library it will still display the last number of files that it knew about. This isn't a complicated DB query, and the query would not return them on a folder by folder basis, it would return the entire set and it could simply be displayed.
Sure, yeah, I know, I don't have to wait for the counts, I can select a folder and go on my merry way. It is contributing to the feel of the application. And the feel is lethargic in general
I suppose that there needs to be some reconciliation of the Catalog files to the OS Files, but does every folder need to be reconciled on startup? If I access 5% of the folders in a session it is a lot. Typically I'm working in 1 or 2. The other 100s are reconciled for naught. Maybe I simply need to have my entire computing storage space as SSDs, then this might happen in a snap... somehow I doubt it.
Are other folks experiencing this oozing of folder file counts on startup? Maybe it is just me.
-
It's not just you. I have the latest 27" iMac with the fastest processor and 40GB RAM and I see it. My images are stored on a Drobo 5Dt connected via Thunderbolt 2. Definitely faster than my old iMac but it's certainly not as fast as I think it should be.
-
The most infuriating slow feature of LR, well maybe not the most, but it bugs me every time I start the app. The slowness with which the image counts are displayed in the Folders panel of the Library module. What is going on here? The number of files has not changed since I shut down. It isn't going to change the number if I have added files to the OS folders while it was shut down. And even if I have disconnected the library it will still display the last number of files that it knew about. This isn't a complicated DB query, and the query would not return them on a folder by folder basis, it would return the entire set and it could simply be displayed.
Sure, yeah, I know, I don't have to wait for the counts, I can select a folder and go on my merry way. It is contributing to the feel of the application. And the feel is lethargic in general
I suppose that there needs to be some reconciliation of the Catalog files to the OS Files, but does every folder need to be reconciled on startup? If I access 5% of the folders in a session it is a lot. Typically I'm working in 1 or 2. The other 100s are reconciled for naught. Maybe I simply need to have my entire computing storage space as SSDs, then this might happen in a snap... somehow I doubt it.
Are other folks experiencing this oozing of folder file counts on startup? Maybe it is just me.
Yes, I know how frustrating that is! I found that the startup portion became significantly faster when I changed my iMac from a standard hard drive to a solid state. This is with the catalog and preview files on the hard drive. The original images are on an external. Originally my iMac was taking a good couple of minutes before LR was in a useable state with all the numbers populated and the previews shown, now it is around 20 seconds. For reference, my catalog file is approximately 3.5GB.