Hi,
want to crop several images. But my trial of DPL needs 3 (!) seconds for switching to the next image:
… using a one year old/young PC with AMD Ryzen 7 1700, 3 GHz, 32 GB RAM, Nvidia Quadro K2200 (4 GB)
Any chance to reduce it on half a second…?
Thanks (again and again…), webaschtl
Same here (already posted). DPL takes 1) about 2 seconds until it acknoledges that I have clicked on an other image and 2) displays the large preview after another 2-4 seconds.
The delay in step 1) is independent of customisation settings.
And then I get the following too: After a restart of DPL, changing an image in the “fotothek” is almost instantaneous. Switching to “customise” makes the switching slow. Even if I don’t do anything to the images, just switching there and back again makes changing go slow.
(macOS Sierra on iMac 13,2)
Forget this: When I do the same thing on an external SSD, the effect is much reduced, which makes me think that DPL is always reloading (and recalculating) the image from disk.
Update: After a few rounds in DPL on the SSD, I get the same sluggish switching between images. Moreover, switching modes (library/customise) takes longish 3-4 seconds.
Update: DPL runs relatively smooth under the root user, see related topic: https://forum.dxo.com/t/photolab-considerably-slower-than-op-11-and-op-10/1920/32
Hello guys,
Yep, performance is a problem for both platforms. We struggle to improve it step by step. Soon Beta testers will get a version with some improvements for the test.
Regards,
Svetlana G.
Thank you.
How can I get this status?
Replied in a PM.
Any chance for an option to turn off the pseudo-DAM soon to be real DAM features and re-enable fast image switching? The speed of switching between images is infuriating, particularly as to create a preset or even copy settings one has to switch to another image and switch back.
For others struggling with this issue, this is why I recommend culling all images outside of PhotoLab (I use FastRawViewer as it’s inexpensive, reliable and good, what it lacks are advanced EXIF editing options other full DAM solutions offer), putting all your selects in a single folder and proceeding methodically through one’s images, adjusting a preset or two as you go. Even then working with PhotoLab is horrifically slow.
Speed is the only feature which really matters now. As a workflow tool, PhotoLab is broken.
Thanks for this tipp!
Guys,
I just reproduced this “test” my machine. Yes, about 2 sec (barely). I’m running older Samsung 850 Pro’s in RAID 0 on a Z97 chipset, 4th gen Devil’s Canyon CPU with 16gigs of RAM. System isn’t what I’d call fast by any means but its not pokie either.
Click acknowledgement is instant. I have fully rendered photo in that 2 sec time period.
Switching back and forth between Photo Library and Customize is imperceptible. Micro second, not even that, and many of the folders I’m testing with have over 1,000 full res RAW images in each.
After about 10 min of clicking, I got one photo which took a full 3 sec. Given the age of my hardware, I don’t feel like this is an issue. For me anyway.
The slow-down has started quite early as you can see from this post: https://forum.dxo.com/t/photolab-considerably-slower-than-op-11-and-op-10/1920
At this stage of development, DPL had no DAM functionality yet. At that time, we got a new viewer (not sure though and unable to research in detail for now) and local corrections. I suppose that sound ui/ux handling was lost or forgotten with the excitement about the new features. OP 11 is still my benchmark for quick response to user actions.
Good to read, not the struggle but the improvement 
, so you know the painpoints which slowing down the overall UI experience?
lens corrections profiles would be one of them i fear.
Just a question out of interest: is the (one of) solution a coarse and developement display modes?
i recon this would be a quick way to release pressure of the calculating by jumping from one image to an other. (a small switch button at the top of the command row would be fine to let the user decide which mode he/she needs/want)
Hello,
Thank you,
Regards,
Svetlana G.
…indeed. Let me know if you need my support or more (or better, more precise) feedback.
This is very dangerous language Peter. Coarse renders are unsightly, distracting and hard to use (iView MediaPro acquired coarse render under either Microsoft or C1: people had to abandon the software due to flashing when switching from rough to HQ). We had something similar here with PhotoLab, people were not happy.,
What could work are pre-rendered cached files preview files (screen resolution, moderate jpegs, say 80, to avoid too much disk reading, i.e. 2 or 3 MB and not 15 or 25 MB) of last known render. So switching between them is instant. It’s only when you want to adjust a palette that PhotoLab will slow down to manipulate the original.
This would mean an import process (building the thumbnails and previews) as Lightroom and C1 have. One can circumvent complaints about import by allowing the application to function as it does now during import. The downside is that during import the rest of the application is less responsive.
But please no coarse or rough previews. They are the kiss of death. iView MediaPro never recovered from that change.
i live on the edge LOL
No i ment use the embedded lenscorrections in the rawfile (i think there in there) or a fast and quicky version of optical module when you are in library mode. (caorse mode/ or fastmode) So you can scroll fast through your images with out the “popping in scale”. Saves seconds changingtime. By switching to customize go to present mode( the one we have now). (with the possibility to temporally switch to “coarse/fast” view if user wants this.)
when i come to this: now we have a “no correction” and a “corrected preview” splitscreen. By clicking “compare” you can change “corrected preview” in “no corrections”. Imho pointless, it’s already on the left.
And i would like a trail image split. (showing two different image’s in the row. say: 1 2 3 4 5 6 , next click: 1 2 3 4 5 6 ) This way i can look and compare to image numbers next to each other.
A ctrl click for select two in the film strip for comparing would be the cream on top.
The compare button is stil usable for the correction/no corrections toggle.
This can also work when you do this in indexing library so it’s “on the shelf to pick” ready
I think the photolibrary mode needs a speedy smooth viewer with flexible comparing possibility modes you can with fast stone viewer. (up to four)
BUT FIRST a solution for the cumstomize modes UI speed.
No not in Develop mode/ Customize. (only when deliberately asked by user which disables the local adjustment en other detail editors.) This you now can be do by clicking between Photolibrary and Customize, So i think it 's there already.
A good to know, i thought that “popping in to scale” from the optical module is causing waiting time and each new screen build up after a change in zoom or something as Local adjustements needs this build up again.
Please see my reply to @uncoy as detailed view of my “coarse view” modes.
Thanks.
This is all terribly complicated. To make the feeling of slowness go away while browsing or switching between images, all DxO needs to do here is make sure that the latest version of the image is stored as a compact preview so they can show instant accurate previews when switching between images in 1. the file browser 2. the photo editor/customise.
The other requests belong in a thread about image comparison which is an enhancement and not a performance issue.
Why complicated? IF they want that we use the new DAM function it needs some user choices to compare images before you put the selected in a “project”. and switch to “customize-modes”.
Other wise don’t bother at all building a DAM. (you use FRV for this because it is fast and you can cull by comparing and some tagging/rating i believe)
It will be a performance issue if they don’t get the image change slugginess out the library mode and they adding new items and possibility’s in this DAM/Photolibrary.
Like a the rawfile embedded jpeg which by the way FastStone uses for showing rawfile image?
But then a real accured image? will that not be a monster of a DataBase to store all those “rendered images” next to the dopfile info?
Other wise don’t bother at all building a DAM.
This thread is not about building a DAM, this thread is about performance issues with existing functionality.
(you use FRV for this because it is fast and you can cull by comparing and some tagging/rating i believe)
FastRawViewer does not have compare functionality. It’s fast enough switching between images that just switching between them is fine. One can colour code a set of images if one has to choose between a group (i.e. you can filter that colour only). DAM functionality in FastRawViewer is limited – it’s a great fast image browser and tool for culling. I also looked closely at Lyn but unfortunately Lyn’s rating changes aren’t picked up by most RAW tools. I wanted a tool which plays well with others. FRV works well as part of an open post-production workflow.
These days I use FRV to browse my export folders as well, although even more often I use LilyView as there’s zero chrome on it. I could get by with just FRV as, like LilyView, it supports 4K monitors. Apple’s Preview does not.
Part of the price of improved performance are larger caches. No way around it. Can’t all be cached in RAM.
Peter, you have hijacked a performance thread to turn it into a new functionality for the DAM thread. It’s confusing (perhaps not to you but to me and any developers trying to read through it). Honestly, we’d all be better served if you create a new message or feature request about functionality improvements to DAM. Even better yet find an existing message or feature request which covers similar ground and add to it.
if you feel that way ok not my intention:
it were only side tracks. Things which pop up when talking about preformens as a UI.
The deeper coding ( in photolibrary or customize) which slows down a change in the UI (what i see on screen) i can’t see or imagin without more detailed information about which processes are running/starting to claim CPU time and RAM memory when you command something in that same UI.
Yes i can run a Speccy to see when my pc is raising its heartbeat and start clicking around to see the spikes, but that’s a bit clumsy and amaturistic.
My point is if the slugginess is starting to be annoying when the photolibrary is grow fatter and also when the new tools in customize mode are delaying it’s UI refreshment. That’s the place you need to search for answers.(speed up the new) if it is just a build up from more refreshments of each module and added tool extra’s then you need to speed up all refreshments actions (or build more lanes/ use all the core’s there are to use)
and if you rewrite some parts take in the possible improvements along with it.
That’s all.
(stepping out, no hard feelings, just a knowlegde barrier) 
I agree with @uncoy, the problem is relatively easy to solve: cache a few recent rendered images in memory, at 100% resolution. Problem solved. Typical user workflow involves switching between several versions of the same shot to pick the best one. I’ve seen a friend do it in Capture One. It’s instantaneous. On my machine, it takes 1-2seconds. And I have a pretty beefy PC: Intel i7-9700K, 32 GB RAM, NVidia GeForce RTX 2080. PhotoLab should be flying on it.
