Would love to see file/DAM performance improvements prioritized
Logged
What problem do you see this solving?
I understand from a product management standpoint the need to add new features to justify ongoing subscriptions and attract new users, but as a long time CO user, I would really, truly, love to see a major push on improving performance, especially when working over network drives, or doing any kind of file operations. Somehow Lightroom is able to render previews quickly, even when not cached, is able to import new images fairly quickly, or when locating a moved folder, the change happens quickly. Not so Capture One - it labors on network drives, often seeming to freeze when simply scrolling a folder, importing is painfully slow (I use Photo Mechanic to ingest) and using catalogs on remote drives is a last resort. I think my network is about average so I imagine I'm not the only one experiencing this. Please, please, hire some Adobe guys to speed things up!
When was the last time you were affected by this lack of functionality, or specific tool?
It is a daily issue as most of my images are on network drives
Are you using any workarounds or other solutions to achieve your goals in Capture One?
I have switched from Catalogs to Sessions to try and speed things up, but it is still very slow. I also have a folder of jpgs on my laptop which lets me search (in a limited way) for images from a past shoot.
Are you happy to be contacted further about this suggestion or request?
Yes
-
I type in the search field and I can watch the text slowly appear. Smart albums are also very slow. I see the Mac "Beach Ball" far too much
Typical. In the former case I suspect that C1 is trying to refine the search at each typed keys, which has a sort of multiplicative effect on the “standard” slowness.
Yes I can see this happening. But, other programs don't see this lagginess.
I don't want to be the grumbly guy, I just want Capture One to be a better program. I like so much about it. Hopefully this will be addressed in future releases.
Thanks
Mionty
1 -
There is NO imperative that one must follow Groups > Projects > Albums as a hierarchy (if that is what you meant in your statement).
No, I meant it the way: In groups I can collect albums and projects, in projects I can collect only albums (and no groups, I believe?) and in albums I can collect only images - which none of the other elements can. But I admit, that was not clear in my sentence before.
The other way round: Without an album no project. And although a group can consist of albums and projects, you never see all images in that group.
However, in Aperture this hierarchical way was not needed. An image could be in a project or an album or both. And in a group (or folder) I can see every image of every album and project in this folder. I don't use slideshows, book-projects and light tables often, but I think, after moving them into a folder, the containing pictures were shown already on folder level?
In my Capture One user collections I have top level projects with albums and no groups. I have top level groups with albums and no projects.
Me too, that was not the reason to post the hierarchy.
In Apple Aperture you could create groups of groups, groups of Projects, and groups of Albums inside or outside of projects. Both Capture One and Apple Aperture have complete flexibility.
Except you can't see what's in a group in C1, but in Aperture. This is not what I call flexibility because C1 slows me down as I need to look into each project/album after the level group.
In Apple Aperture I never created a search by a collection name.
Well, then you know the place of each DAM item by heart? Btw. it's not needed to "create a search" - simply type a part of an assumed album name into the search field.
I don't deny some might find that useful. I simply never found the need to do so myself.
Don't recall my last count of albums/projects/groups but I believe the total number was approaching 1.000 since 2019 - before there's another catalog.
We in this conversation don't know how many people would find that feature useful. This thread is about DAM performance.
Be it keywords or album names: A search possibility is essential and determines also the performance of a DAM. I don't see a DAM as a pile of nicely named card-boxes hidden behind a locker, never to be found again.
If you want a feature for Capture One to search by a user collection name then submit that as a feature request. If lots of people upvote it then Capture One will know that it is a highly sought feature.
I did so a long while ago, after about three requests to support. Now I like you to tell me for what you need groups, projects and albums if it's impossible to find them in another way than opening each top level and reading through all names? That's not even MS-DOS level!
As you said, there's no Aperture competence or knowledge within C1. And my impression is, the person who developed the current C1-DAM (which is not that bad) left the company a while ago and no one dares to continue his work.
0 -
I use the Filters tool to find most anything I need to find. Dates, Places, Metadata, Keywords generally do all I need. I also use the free form text search which searches every field. That of course can be slow due to the number of fields and images in my catalog (catalog with over 66K images). I've never relied on a collection name because I am so accustomed to applying all the searchable items I need in the metadata fields and keywords. We all do things differently. In Capture One I have very few user collections.
I agree that it would be nice to have Groups and Projects be combined to a single entity that works like Folders in the Folders tool. We need to be able to create a hierarchy, and be able to select any one in the hierarchy and see all images included below it.
0 -
Sure, SQLlite (3), my bad (I was working with mySQL on a software project when I was commenting, LOL). Still, SQLlite is a quite fast database for single-user operations; it's a de facto standard for dektop applications requiring a database and I see other apps using it that are quite responsive.
In general, it seems also that there is something that degrades the performance over time — I mean, sometimes it seems that quitting and restarting C1 recovers this degradation.
For instance: managing keywords with another application, I have to periodically sync Smart Albums. I have a piece of software that scans XMPs for keywords and prepare a “batch” Applescript that does the job. It's above 10.000 lines (half of them are updates for the progress bar). I don't have any particular speed requirements for it, as I run once per several weeks overnight; but I've noted that execution time changes dramatically from time to time, from two hours to longer than eight hours. It seems that it's faster when I launch it after restarting C1 and that it gets slower and slower as execution proceeds.
In any case I don't understand why a statement like this:
tell _Workflow to make collection with properties {kind:smart album, name:"edit process 2022-09-08", rules:"<?xml version=\"1.0\" encoding=\"UTF-8\"?><MatchOperator Kind=\"AND\"><Condition Enabled=\"YES\"><Key>IB_S_CONTENT_KEYWORDS</Key><Operator>6</Operator><Criterion>edit process 2022-09-08</Criterion></Condition></MatchOperator>"}runs in the magnitude of seconds: it should just be a batch of inserts into the database.
0 -
Fabrizio Giudici (stoppingdown)
Perhaps once the new smart collection is created Capture One starts searching based on that criteria? In my experience any changes to metadata or other "filterable" data that is applied while a filter is active causes Capture One to slow down by orders of magnitude.
Have you watched Capture One while this script runs? When smart albums are created are they selected? When a smart album is selected it is filtering. At that point based on my experience any changes to filterable data (even data not included in the filter) causes Capture One to slow down dramatically. Keywords are in my experience are particularly bad at causing this.
0 -
I use the Filters tool to find most anything I need to find. Dates, Places, Metadata, Keywords generally do all I need. I also use the free form text search which searches every field. That of course can be slow due to the number of fields and images in my catalog (catalog with over 66K images).
Here Capture One becomes unresponsive also when filtering by rating, color tag, date and keywords. You don't see this?
1 -
When I use the app and filter with the Filters tool or quick filter (top search bar) I do not see dramatic slow down in the app other than trying to apply changes to filterable data. Editing is not slowed down. That said I rarely make edits while any filters are enabled. I sense from experience and from other's responses here that filters should be used sole for filtering and edits should be done with no filters enabled.
0 -
Here, with a catalogue containing 28k+ images, when I select one of the filters, e.g. a color tag, Capture One brings up the result almost immediately and then becomes unresponsive (spinning beach ball) for a around 12 seconds. With larger catalogues the unresponsiveness lasts longer.
1 -
Yes, it makes sense that touching an object that is related to a refresh on the screen might trigger delays — I directly know, as in a previous life I wrote an open source app for DAM. Actually in my case I always ensure that the new albums (that are all created under a single root group) are not visible, i.e. the root group IS collapsed. Not using this tip makes things even worse.Given that C1 does not show global stats (e.g. the number of items) on a group, it should understand that no extra job has to be done in this case.BTW I'm no expert of how applications expose API to AppleScript and don't know whether there's a sort of bottleneck related to it — but I've just read a post about knob-and-button devices using AppleScript, so I presume the interaction in that case is pretty quick.0
-
Apps expose themself to AppleScript via the Apple Event Model framework. I found that out while looking for any form of Python library that could interact with Capture One. There is a Python library that interacts with the AEM that seems would let you do all the same operations with Capture One that you can do in AppleScript. It doesn't seem to be actively supported and I have not tested it personally. The last documentation I can find is still referencing Python 2.x so I would probably not rely on it. Whether it would any faster is unknown. Its just a different language to interact with the AEM to get to Capture One so perhaps it will be no better.
0 -
Fabrizio Giudici (stoppingdown)
In general, it seems also that there is something that degrades the performance over time — I mean, sometimes it seems that quitting and restarting C1 recovers this degradation.
Capture One has quite solid leaks, to the point I would discourage doing intense activities on less than 32 GB RAM (on Windows at least, this is what I can test). I even had it eat everything there was out of 64GB I have...
1 -
By the way, I received a reply from support yesterday, that contained the following passage:
Large Catalog performance needs to improve. That also means we need to investigate in which setups, and how big means big Catalogs. Right now we are not using resources on that front.
I.e.: DAM performance has no priority.
This was a reply to a request for help to find the cause of Capture One's excessive unresponsiveness on my system.
3 -
I thoroughly agree that Capture One needs to improve DAM and file management urgently. I came from LR several years ago and it's chalk and cheese. Just one example from myself, often when I change a folder name in Capture One, it takes a very long time to complete and quite often leaves a huge mess where both the new and old folder name remain on the disk and image files are scattered between both. Sometimes I have lost edits trying to fix that, extremely frustrating. I have had better luck going into windows explorer, changing the folder name, then mapping back the lost folder in Capture One, but that's also extra steps and inconvenient. This happens for me on both my laptop and PC using windows, so seems to be related to Capture One itself. When I try the exact same operations in LR, they perform flawlessly and quickly every time as you would expect. My files are on local hard drives and I have 128GB RAM available on the PC and catalog's in the thousands or tens of thousands of images (not hundreds of thousands).
1
Post is closed for comments.
Comments
73 comments