I am testing PL7 and when I opened a new folder with 1500 photos for the first time in PL7.0, I was pleasantly surprised that it loaded extremely quickly! I could scroll down and all photo thumbnails showed up instantly. Those were the integrated thumbnails from the camera, and step by step they were updated by the photolab thumbnails, but that was fine to me, at least, I could see the files quickly.
I already thought, nice, maybe I should really consider upgrading to PL7. But today (after I upgraded to PL7.01, I don’t know if that has anything to do with it), I opened the same folder, and everything was extremely slow again. I do not see any thumbnails at all, just the “Loading, please wait…” black tiles all over, and one after one the thumbnails are generated very slowly, and even after many minutes I do not see all the images.
Why is that, that on the first time loading the thumbnails show up so quickly, and after that it becomes so slow? I was really happy at first that this seemed to be improved, but unfortunately it seems it is not. But as it works the first time, it should be possible to fix this once and for all, no?
After a minor update the problem was fixed, but from time to time it occurs again.
Just tested with 4.3.6 Build 32 and no problem with older subdirectories. Newer one take some time, but that’s normal. And also closing PL4 and opening again shows no lag.
And I remember that we have had tis problem from time to time over the versions…no idea why
I have this problem, also. In fact, I noticed it while testing the performance difference between HDD and SSD for photo storage. I saw little difference.
There must be something systematically wrong that should be fixable. If it is possible to load it fast the first time, without ever having seen the files before, why does it not work afterwards? I am not sure, maybe it loads slower if there exists a dop file in the folder? Then it should be possible to reorganize the priorities of charging the files, first load the images and then the dop files. For me this is a big issue. I was on the edge of investing into PL7 if that would have been fixed.
Selected a folder of 1277 .CR2 files. Rendering took about 22 CPU-minutes with load of less than 200%.
Let load go down to 0%, every thumbnail now showed rendered (instead of built in) preview.
Quit and reopened DPL and scrolled through the complete folder. Previews came up along with the scrolling, no beachballs or messages. Again, loads of less than 200%. Same in customize view. Got no lags.
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
6
It’s a rule of thumb not to add more than a thousand images into any folder. Almost any application will have problems with that.
If you still insist on 1500 it will ve a good idea ti use a third party viewer to open a smalker subset at the time from inside that external application the explorer in Windows or whatever you use in a Mac.
In the database in Photolab you can see these subsets of External Searches in the left Panel of Picture Library. Any time you wish you can reopen any of these searches.
The thing is, it seems to be working fast sometimes, as I had described in my initial post. So why would it work fast in one version and slow in another?
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
8
From what I recall I reacted over how slow it was when moving from image to image in PhotoLibrary especially. I have a new and fast machine with i7 with 16 GB, 1 TB SSD and pretty fast graphics card that exports 33 Mp images in 7-8 sec bjt just to move to a new image in PhotoLibrary tool 2-3 seconds in version 6.
BUT, when moving between exactly the same images in the Customize module it’s many times faster and instant. Explan that!
Well, it is a best practise in the enterprise DAM-world not to store more than 1000 images in a folder of efficiency reasons… These systems are all about metadata and zero about folder structures and use to be rigged to automatically create a new folder when the current folder reaches 1000 files. DAM Managers are very aware of these facts but most other people are not.
wrong word was used - this is not “enterprise” level when application can’t deal w/ > 1000 images ( in a folder on top of that , instead of enterprise level dabatase ) … this tell-tale sign of a purely designed low grade consumer level ( single user mostly ) app ( which some self-proclaimed “DAM Managers” apparently are using ? ) …
One might expect that what we see in the image browser in both PhotoLibrary and Customize is being cached and put into the database. For years, I’ve found that in Customize as well as in PhotoLibrary, behavior when switching between images has been very inconsistent. Often I have to switch repeatedly between images before caching is complete. This is still the case. I just restarted PL6.10 on Windows after moving all of my images to a new SSD. (They were previously on my C: SSD - plus, I experimented with having them on an internal HDD.) When I pointed PL6 to the folder I want to work on, it naturally took a while for all of the images in that folder to be preprocessed. However, I noticed that the speed was the same in both PhotoLibrary and Customize. Nothing unreasonable, but not quick. There was more stuttering in PhotoLibrary mode because the image browser has both height and width. In Customize, my image browser is one long filmstrip, one image in height and many in width, so scrolling through it isn’t as taxing. I also noticed that switching between two images (RGB or RAW) is still very slow in both PhotoLibrary and Customize. When I switch between RAW images, I immediately see the unprocessed preview image - there’s no slowness there. But it takes several seconds for initial adjustments to be applied. I still have to switch back and forth between two images many times before the images are properly cached and there is no longer a delay in showing the fully processed image in the viewer. After about five tries, give or take, I can switch between the two images and see the full results instantaneously. Some individual images seem to be cached on the first try, while others take at least five tries, sometimes many more.
I reported all of this to DxO years ago. They gathered my data and made sure I was making full use of caching in PhotoLab. Yet they’ve never acknowledged a problem or tried to improve the behavior.
Once all of the images are fully preprocessed in the image browser, scrolling still isn’t exactly smooth. It’s a little bit smoother in Customize. But a few images that I had clicked on still show the circular arrows as if they are still being preprocessed - even though that work seems to have finished.
When I close and restart PL6, all of the thumbnails in the Image Browser have to load again from scratch. “Loading, please wait…” It’s as if it had not been done before. And now I see that no matter how many times I switch between two RAW images in PhotoLibrary their processed states are never cached. But if I switch to Customize, switching between these same two images eventually caches most of the adjustments. But now I can see that there are still some uncached adjustments: the images continue to shift slightly in one direction or another a few seconds after being brought up in the image viewer.
PL6 eventually became unresponsive and crashed while I was doing this.
Unfortunately, things seem to be getting worse, not better.
2 Likes
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
11
Well, unlike Capture One or Lightroom Photolab doesn´t import or ingest images. What happens when ingesting or importing images is that they get indexed and smaller thumbnails are created. That process will get affected the more images you have in a folder. That is a one-time job. Photolab works a little bit different since it works straight on the folder-level without ingesting.
When people like me using Photolab as I do, I always use as high resolution as I can. There is a compromise in any RAW-converter with an integrated database. In Lightroom some users prioritising speed configures LR to use smaller previews. That gives a faster database but when starting to develop the images will then forcing the system to scale the presets in that module instead.
In the fastest of them all PhotoMechanic they don´t have to bother with this compromise at all. As soon as the images are ingested, smaller previews are made the system is as fast as the lightning. Either LR, PL och C1 will ever be able to match that. PhotoMechanic doesn´t even need either the folders or the images to let us search their catalogs. It solely relies on its indexes and optimized previews and that is totally different to Photolab which is working online all the time towards the folders and images. We can´t compare that to Photolab - it´s a completely different world. PM is designed to manage millions of images extremely fast. Photolab not so.
There is a best practise rigging Enterprise DAM-systems automated workflows saying not to use folders bigger than 1000 images and that is for a reason. Either we learn from that or we suffer of unnecessary poor performance. The choice is ours and nobody else regardless of possible bugs in Photolab. You can easily test this on an unindexed windows-partition with the “Explorer” or whatever other viewer.
That said, I agree with you on our findings when it comes to the very slow performance of PictureLibrary at least until version 6 and I don´t understand either that it has taken so long to fix that problem but for me now I think version 7 is much faster. I don´t see these problems anymore I think. I just tested.
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
12
Can´t you download a trial of version 7 and test even you?
I can’t verify your problem switching between RAW and JPEG in version 7 either. It works fine when it once have opened a folder and rendered the previews in PhotoLibrary. It’s fast even in Customize. Absolutely better compared to version 6.x.
I’m glad to hear that! But please allow me clarify my position. In my experience, PL6 is an improvement over PL5 but is getting less stable in recent updates. I have found PL7 to be a mixed bag. I was testing it and am no longer doing so because it doesn’t meet my needs. There are regressions that aren’t fixed yet. So yeah, the product has been getting worse for me.
3 Likes
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
14
… but since you seem really affected by and concerned about the performance issues in version 6 and the same very problems seems to be solved what I can see in version 7 I don’t really understand why you seem relectant to test version 7.
It won’t cost you anything more than a few minutes of your time to begin with. By gones are by gones and nothing to get irritated about. I doubt DXO will do anything at all to fix these problems in version 6 if they haven’t done it so far.
I think there are a few really important improvements in version 7 that justifies an upgrade for me and I also see this as a way to support DXO, so they can continue to improve the product.
I have been testing version 7 all throughout the Early Access period and have tested the final release also. I appreciate your enthusiasm - enjoy the upgrade my friend.
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
16
Thanks Greg
I see you are an EA!
These days we have to try to keep the spirit up, don´t we?
I do think that this is all part of the problem of PhotoLab trying to be a DAM. I often keep folders which may have a couple of images up to a few thousand.
The viewing was fine with viewers showing the embedded previews… even if you go all the way back to a G5 PowerMac. The filesystems have improved, the speed of the SSD vs old fashioned HDDs has improved, the processing and GPUs have improved.
So why, does something which used to be fast wit other applications, sometimes become painfully slow with PhotoLab.
PhotoLab is a great raw processor and a very poor DAM.
Rules of thumb can be good, but sometimes they should be updated as technology improves. Like the keep 10% of the RAID free made sense with smaller RAIDs but not with those made from 20TB+ disks.
Well, unlike Capture One or Lightroom Photolab doesn´t import or ingest images. What happens when ingesting or importing images is that they get indexed and smaller thumbnails are created. That process will get affected the more images you have in a folder. That is a one-time job. Photolab works a little bit different since it works straight on the folder-level without ingesting.