Pages: 1 [2] 3   Go Down

Author Topic: Lightroom development  (Read 2620 times)

Frodo

  • Full Member
  • ***
  • Offline Offline
  • Posts: 116
Re: Lightroom development
« Reply #20 on: September 14, 2018, 06:32:32 AM »

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
« Last Edit: September 14, 2018, 06:45:09 AM by Frodo »
Logged

FranciscoDisilvestro

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1320
    • Frank Disilvestro
Re: Lightroom development
« Reply #21 on: September 14, 2018, 08:35:55 AM »

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.

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 11995
    • http://www.markdsegal.com
Re: Lightroom development
« Reply #22 on: September 14, 2018, 09:27:55 AM »

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.
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

kers

  • Sr. Member
  • ****
  • Online Online
  • Posts: 1904
    • Pieter Kers
Re: Lightroom development
« Reply #23 on: September 14, 2018, 10:16:10 AM »

...
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...


« Last Edit: September 14, 2018, 10:19:43 AM by kers »
Logged

larkis

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 288
    • My photography blog
Re: Lightroom development
« Reply #24 on: September 14, 2018, 01:52:45 PM »

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.

digitaldog

  • Sr. Member
  • ****
  • Online Online
  • Posts: 14710
    • http://www.digitaldog.net/
Re: Lightroom development
« Reply #25 on: September 14, 2018, 03:03:52 PM »

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!
Logged
Andrew Rodney
Author ďColor Management for Photographers"

FranciscoDisilvestro

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1320
    • Frank Disilvestro
Re: Lightroom development
« Reply #26 on: September 14, 2018, 05:36:29 PM »

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.

Schewe

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 6225
    • http:www.schewephoto.com
Re: Lightroom development
« Reply #27 on: September 14, 2018, 06:35:33 PM »

Just scrolling a large number in Grid, too slow!

I donít scroll...I use page down...thats faster :-)
Logged

FabienP

  • Full Member
  • ***
  • Offline Offline
  • Posts: 112
Re: Lightroom development
« Reply #28 on: September 14, 2018, 08:04:18 PM »

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
Logged

leuallen

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 376
Re: Lightroom development
« Reply #29 on: September 14, 2018, 08:58:52 PM »

Quote
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
Logged

FranciscoDisilvestro

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1320
    • Frank Disilvestro
Re: Lightroom development
« Reply #30 on: September 14, 2018, 09:56:26 PM »


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

FranciscoDisilvestro

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1320
    • Frank Disilvestro
Re: Lightroom development
« Reply #31 on: September 14, 2018, 10:04:03 PM »

I donít scroll...I use page down...thats faster :-)

That's sufficient evidence to prove there is a performance problem with the software

Schewe

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 6225
    • http:www.schewephoto.com
Re: Lightroom development
« Reply #32 on: September 15, 2018, 12:03:24 AM »

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'
Logged

FranciscoDisilvestro

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1320
    • Frank Disilvestro
Re: Lightroom development
« Reply #33 on: September 15, 2018, 12:23:50 AM »

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
« Last Edit: September 15, 2018, 12:40:09 AM by FranciscoDisilvestro »
Logged

Schewe

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 6225
    • http:www.schewephoto.com
Re: Lightroom development
« Reply #34 on: September 15, 2018, 12:41:14 AM »

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.
Logged

FranciscoDisilvestro

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1320
    • Frank Disilvestro
Re: Lightroom development
« Reply #35 on: September 15, 2018, 01:16:04 AM »

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.

digitaldog

  • Sr. Member
  • ****
  • Online Online
  • Posts: 14710
    • http://www.digitaldog.net/
Re: Lightroom development
« Reply #36 on: September 15, 2018, 11:41:39 AM »

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:

Logged
Andrew Rodney
Author ďColor Management for Photographers"

Dave Rosser

  • Full Member
  • ***
  • Offline Offline
  • Posts: 174
    • My Website
Re: Lightroom development
« Reply #37 on: September 15, 2018, 12:44:51 PM »

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.

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 11995
    • http://www.markdsegal.com
Re: Lightroom development
« Reply #38 on: September 15, 2018, 12:46:34 PM »

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.
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

Etrsi_645

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 52
Re: Lightroom development
« Reply #39 on: September 15, 2018, 02:04:13 PM »

I turned off the use of "Windows Ink" and that helped my develop module immensely!  YMMV...
Logged
Pentax K-5 with lenses: DA* 16-50 f/2.8,
Pages: 1 [2] 3   Go Up