Reviewing RAW photos in Nikon NEF format is quite slow on my computer, taking about 2-3 seconds per photo. What should I do to increase performance. If I install a GPU card will it help? However, is it necessary rather to upgrade the processor with a more powerful one with more cores? I’m using a computer with an Intel 10700 processor (8 cores), SSD, no GPU card.
The GPU will only accelerate DeepPRIME and DeepPRIME XD processing. Going from image to image usually takes at least a second or two and sometimes longer depending on your computer. If you are expecting switching photos to be instantaneous you will probably be disappointed.
Mark
DxO did not get to use GPU for screen rendering yet ? what a shame …
Unless something has changed, the GPU does not accelerate screen rendering. However, in my experience over the last few years screen rendering performance has improved, especially when viewing at 100% or greater zoom levels.
Mark
I have noticed the same thing with PL 7.02 yesterday.
Faster than 6.xx, and it remains reasonably fast even after a couple of hours, without noticeable slowdowns. Something has been improved in terms of optimization.
PL7, applied no correction preset, task manager shows GPU utilization, with mouse wheel I scroll rendered image from 10 to 50% zoom and I see that GPU is used very well when I zoom in - zoom out… note that I did not go above 50% to avoid any chance that DxO PL will start rendering details like it does @ what - 75-80% and above ?
plus licenses texts for OpenGL and Vulcan libraries are in Licenses directories… and it is typically GPU accelerated rendering stuff
I saw the same in version 6 and of some strange reasons it was much faster in Developing mode than with PhotoLibrary. Can you try to walk through your images in Developing mode too and get back and tell us if it is just in PhotoLibray it is that slow?
I don´t think this have something to do with the graphics card at all because then the Developing mode should not be that much faster than PictureLibrary should it?
I don´t see that slow action in version 7 in Picture Library. My Graphics Card is pretty good (Nvidia RTX 3060 Ti) in a one year old computer and despite that it was slow too with my PL 6. Picture Library ought to be much faster since Developing mode is refreshing the high res preview images on the fly.
Thank you for your reply. Does DxO have plans to address this performance issue, in any way? Whether by hardware acceleration or algorithm optimization. Why this is important: we have functionality in Photolab to filter images, among other things, by rating. Unfortunately, with low browsing performance, the sense of this functionality is very limited.
I performed a comparison test, which shows that there is no perceptible difference. It should be added that such tests, without knowing implementation details, are very prone to misinterpretation. Does Photolab cache prerendering results? Does the performance depend on the monitor resolution, and is it a linear relationship? Does switching to full screen (F11) change anything in performance? Does it improve or lower it? Does Photolab prerender photos slower and slower over time? And so on. I did a review of 10 NEF files in the PhotoLibray window and in Development mode. Full screen (F11), monitor resolution 2560x1440. Raves not processed (no DOP files). Photolab 7 right after startup, no other applications on the computer.
PhotoLibray: 17,41 s. (1,74 s per file)
Development mode: 16.9 sec. (1,69 s per file)
Time measured on a smartphone stopwatch, where the accuracy of the finger is surely 0.2 to 0.3 s. Conclusion: there is no difference, it is the same. What could change completely if the conditioning changes, one of the long list I mentioned at the beginning…
PC: HP Elite Desk G6 16G RAM, SSD, Intel 10700, GPU in CPU
24 MP raw files.
taking this opportunity, I would love to see the measured results on hardware equipped with a graphics card with opencl acceleration according to DXO requirements
Greetings 
No idea if you get that lucky that DXO will get back to you, because DXO rarely participates in any type of dialogue in DXO Forums.
There ought to be a negative impact on performance if you like me use "high resolution previews. For me it is not an option to use anything else than high resolution previews.
I guess we will always get disturbed from time to time by poor performance when culling images in Photolab because it is just not optimised for that. Photolab is a compromise and so are Lightroom and Capture One as well. Photolab´s PictureLibrary is not worse than for example Capture One, quite the opposite in fact in most cases. Even Lightroom has been criticized for poor performance when it comes to handling large amounts of files and like in Photolab that is by design. All these softwares are compromises where there is a trade of between speed and preview quality. The recommendation for Lightroom when I used it was to reduce the preview quality and if one did, one had to pay the price when developing the images, because then the rendering took longer time instead.
If culling performance and/or metadata management really is important for you, you can always choose to use much more effective tools like PhotoMechanic for those processes. PM integrates really well with Photolab but there is still a price to pay and not just for the software but also through a learning curve and some extra configuration.
The only thing you need to do from the Photolab side is to check one check box. Then all the changes done in an external software that saves them in XMP-files in a folder Photolab is aware about has will automatically update the database in Photolab.
A really useful feature in Photolab that is especially nice when using external software like a Viewer is “External Searches”. It remembers all these Viewer selected image batches you have opened via that software and you can recall these batches anytime you like from inside Photolab. This way you will never have to wait for Photolab to render 1000 images just because it happens to be 1000 files in that folder. That way you can speed up these processes substantially, almost for free. XnView and Irfan View are a couple of examples of popular external viewers you can try if you haven´t already done so.
1 Like
PhotoMechanic license is not cheap, so you need to be well convinced that it will do the job before buying. When I’m less busy, I’ll try to test it.
My current workflow is as follows: 1) I directly select JPG photos suitable for archiving from the camera card, transferring them to the computer disk. 1a) I transfer the corresponding RAW files, 2) I select the JPG photos that potentially “deserve” to be processed, creating a list of file names. 2a) in the list I automatically convert the extensions from JPG to NEF and move the RAW photos to a subfolder using that list (Total Commander), 3) from Photolab I operate on the selected RAW files using the rating.
As you can see, I perform operations 1 through 2 without opening the RAWs. I use the usual photo viewer built into Windows, which works very fast on JPG files, and has convenient zoom control. Flow is effective, with the downside that I have to perform file name conversions and that subdirectories of “best” RAW files are created.
To gain the benefits from using a faster and better application for culling and selecting images you might not need PM Plus. There is a much lower threshold learning to use for example XnView than PM and it doesn´t cost anything. The real reason to use PM Plus is the metadata maintenance tools. If you don´t use anything than keywords, as many seems to do then look elsewhere than to PM.
In order to make a selection of images to work with and use “External Searches” you don´t even need PM. It will do with just some fast external viewer.
As you can see below it is easy to open a selection you just made in for example XnView.
External Searches: I don´t know if External Searches is unique as a tool in converters but I can´t remember seeing it anywhere else than in Photolab and maybe the DXO developers have thought of just the fact that the users might run into trouble with the rendering speeds when opening folders with large amounts of images. When importing images into CO or LR people are expecting a certain ingestion time but opening any image folder on the fly you might not.
Your selection is stored in External Searches, so you can reopen them any time later if you need. It is fine to use Windows Photo Viewer image by Image but if you are to open a folder in PL with a lot of images you will be better off if you don´t need to wait for Photolab to render the previews of all of them before you can proceed working and that is where external viewers comes in.
I don´t know if External Searches is widely used by PL users and it took me years to realize that that function actually was there but now, I really like it.
I’m running PhotoSupreme Server Postgres (single user have same functionality but used SQLite) version as DAM.
Fully automated ingestion, copying, naming, sorting, stacking, versioning etc.
I’ve scripted which version thumbnail should be used in previews so a if there’s a raw + in camera jpeg, it displays the jpeg. And if developed a .nef in PL and export it, it’s saved into a sub folder on my server and PSu will use that jpeg version as thumbnail for the version stack instead.
Extremely powerful meta data management and although it have its quirky UX and cost some it’s impressive and works very well with PhotoLab.
30-day test is available.
And it’s a lifetime license you purchase for each version. Then it’s to your choice to upgrade or not. You own and control the database and it’s a standardised one.
But as Stenis says. It’s hard to beat xnview on price/performance.
with DPL7 on macOS and Intel CPU. the load presents itself like this:
- Applying presets and browsing images in PhotoLibrary (light table only): GPU not involved
- Applying presets and browsing images in Customize view: GPU is involved depending on preset
Overall load during the test was about 15 CPU minutes, GPU was about 2.5 seconds.
While using the GPU might speed up rendering in PhotoLibrary view, the easier way would be to just show the built-in previews like many other apps do for better performance. Alternatively, previews could be made by binning pixels which could sensibly provide previews of 1/2, 1/4, 1/8 etc. of the original file size, or 1/3, 1/6 etc. with Fuji x-Trans RAW files.