Previews of all photos take too long
Any way to fix it?
-
Awesome. I love this. 0 -
Just came across this a year later.
I'm getting increasingly frustrated with C1 for this reason. Even generating previews for 128 RAW files ( small Fuji ones from an X-T3 takes a long time. I calculate that to load and just preview say 500 files from their own location and not even moving them would take me about 20 minutes just to finish it's contortions and let me get on with it. This is amazingly bad!
I've been discussing this for the last week and a bit with their tech support who are acting like this is something unheard of that they don't understand and are getting me to send them logs and images etc. I was really annoyed to find this is documented on here so long ago and yet no-one at their tech team just told me it was the way it is.
I like a lot of things about C1 but I've reluctantly decided to go back to Adobe. There's just too many frustrations here. What a waste of money this has been for me.
1 -
Oh BTW I meant to add I'm on a Mac with 32Gb RAM, SSD drive, and my external drives are also SSD with TB3 connections. Everything is up to date. The Mac is new as of a couple of months ago, and performing well with every other bit of software I have. I also have an external graphics card which benchmarks crazy fast and my processor is powerful enough to blast everything else I use faster than anything I've ever used.
C1 just plods along taking forever and running my Mac hot every time, just the same as on my other two Macs.
0 -
William,
Clearly the majority of users do not have the same experience so it may be a question of asking some questions outside the box to get a lead on why your experience so far has been so abnormal compared to expectations.
From your description I'm not at all sure what you have done so far.
Are you running Mac or Windows?
Have you imported a LightRoom catalogue? If so was it a "cleaned" catalogue processed to eliminate any potential internal issues that that might cause problems outside LR?
Are you using a catalog or are you trying sessions?
Do you have XMP Sync active? If so, do you need it active?
When you write " I calculate that to load and just preview say 500 files from their own location and not even moving them ..." I'm not at all sure what process you are describing in the context of opening the files in Capture One. Also, where are the files located currently?
Which type of Capture One Activation have you deployed? Fuji only perhaps? Express version or a full function activation?
I'm assuming that you will have plenty of RAM memory and working disk capacity in your system configuration.
You may have been asked about all of this already but your fellow users here will not know the answers so not seems like a good time to ask them.
-1 -
Hi, Thank you. Yes good points. I will do my best to explain a bit better. Our posts crossed as I explained in my second post my system. It is an issue for me on three Macs of varying ages.
I have only tried imported images from files not used in LR. These have tried on both internal and external SSDs.
I've tried both Catalogs and Sessions and tried to having the XMP active and inactive.
My Capture One 12 full version. My main disk is about 80% empty and I have 32Gb RAM.
It's so frustrating because I really wanted to use C1 and hate Adobe's business model but I'm losing patience.
I am awaiting a reply from their tech support who are currently examining samples of my files.
If it turns out I'm doing something wrong I'd be delighted
0 -
Apologies in advance, this will be a long reply.
I've encountered all sorts of performance issues over the years, and generally been able to resolve them. Over that time I've gained a fairly in-depth view into how Sessions in particular work; my workflow doesn't work well with Catalogues.
With Sessions, Capture One maintains all metadata, adjustments, previews and thumbnails in a "CaptureOne" subfolder structure in the same location as images. Any folder that contains images, that you open in a Session, will have this subfolder.
The main window usually displays Tools, the Viewer, and the Browser. On Windows these are turned on and off with CTRL-T, CTRL-V, and CTRL-B respectively. Probably CMD-T/V/B on Mac, you'd have to check. This is an easy way for you to identify what I refer to below, if you're not familiar with these.
When you browse to a folder in Sessions, it looks to see what images are in that folder, then it checks to see what supporting files are in the CaptureOne subfolder for each. If you have the Browser open, it loads the thumbnail files for each, starting with the images currently displayed in the Browser. If you have XMP files, it'll check those, too. I believe it then syncs them if they don't match and that option's enabled. If you have the Viewer open, it attempts to load the Preview Image for the selected image(s), but only if the preview image is larger in pixels than the Viewer area. If the Viewer area is larger than the preview, or is zoomed in, then it will render the RAW file on the fly. Rendering is done via OpenCL if that is enabled, or via your CPU if not. This is slower than loading just the Preview.
I suggest you:
- Create a brand-new Session. Location is not important.
- In Capture One ... Preferences: turn off OpenCL hardware acceleration for Display.
- Also in Preferences: Set Auto Sync sidecar XMP to None (I also have both "prefer ... XMP" options checked FWIW)*
- Also in Preferences: What is your "Preview Image Size (px) set to? It must be larger than your viewer or you'll be rendering files as you go. To be safe you can set it to your monitor's max resolution, but the larger the Preview Images, the slower they load. You can reduce the window size of Capture One to shrink the Viewer and use a smaller Preview Size (I have to do this on my slightly aged laptop with my 4k display or images render too slowly). Set your Preview Image Size (px) accordingly. For this test you may want to set it to something like 2048 and make sure your Capture One window is smaller, then re-do the test with larger window and Preview sizes until you find the best that works for your hardware.
- Restart Capture One, opening the same Session as before.
- Create a new folder somewhere on your internal SSD. Let's call it "FOLDER"
- Take your 500 raw images, and copy only these images to FOLDER. Don't copy the CaptureOne directory, .XMP sidecars, etc. - only the raw images. You want to make sure nothing legacy is affecting your speed.
- Once copied, browse to FOLDER in your Session. Capture One will recognize there are no Previews etc, and will go about creating the Preview Image, Thumbnail, and Mask (I didn't mention that earlier, ignore for now). Capture one will usually pop up a little Activities processing window telling you it's generating previews. If it doesn't, you should notice a little spinning starburst icon in the very middle top of the Capture One window (hovering should tell you it's "Activities"). You can click this to view / close this Activities progress window.
- As Previews are being generated, you should be able to browse files slowly; ones that are already generated should open quickly. If you zoom out to fit and flip through some of the first ones, you should find it works quickly. Note that Capture One (on Windows, at least) keeps your current image Preview and the last one viewed in memory, so you need to flip through 3 images to load the Preview from disk.
- After all the Previews are generated, restart Capture One again
- It should go through again and somewhat slowly identify the 500 images in the folder. I've never timed it, but I expect that 500 images would take my computer about 15-60 seconds to fully load. If it's taking a half-hour for you, something is terribly terribly wrong.
- At this point, you can go back and fiddle with the Preferences you changed / window/Viewer sizes, turn OpenCL back on, etc.
- There is a very outside chance that there's something specific to the images you have - maybe that specific camera & firmware level or something. You could always try some other RAW files to see if they're better, and then report back to Capture One. That would be something they'd fix quickly I'm sure.
I sincerely hope this helps you. I switched from Lr to C1 because I found it so much faster; I shoot a lot of sports and need to very very quickly step through bursts and identify the best images. I have had various struggles with it throughout the years, whenever I switch hardware or camera bodies or change something up I end up breaking something and have to learn how to fix it. It's far from perfect, but I still love working with C1, and still despise how Adobe does business (and am saddened to see CaptureOne inching that way).
Good luck, and let us know how it goes!!
* Auto-sync XMP is, IMHO, hot garbage, and should come with all sorts of warnings that it'll make CaptureOne unusable. I had hoped to use it to do better metadata management by using other apps that can store GPS locations etc.,. to XMP, but it slowed everything to a crawl for me. I suggest you abandon all hope of this feature if you're having any performance issues.
1 -
A few more things:
First, a lot of what I wrote above was through my own exploration and testing. I may have misunderstood something, so I welcome anyone improving my knowledge of the under-the-cover workings.
I forgot to say: you can regenerate Previews by selecting multiple images in the Browser and right-click - Regenerate Previews. (CMD-click on Mac?)
Given you've tried 3 computers it's probably not OpenCL, but I've found this article extremely helpful:
These forums are good, but there's a group on FB with a lot of long-time experts that have really in-depth knowledge. You could always try there:
0 -
SFA,
I hate to be a negative opinion but I've said this a year ago. It's not clear that a majority of users don't have his problem. The majority of us just stopped complaining because it makes no difference. It doesn't seem like it'll be addressed. So I have just adapted and kept moving on. I've kept my catalogs smaller which is all I could do. The simple and plain of it is that Lightrooms file and catalog management is so much better. It sucks because everything else is better with Capture.
0 -
I have to agree with Juan Stevens, I too have stopped complaining as has every Capture One user I know.
Everybody knows that the way C1 handles files is cumbersome and makes no sense at all.
NOBODY I know (online or IRL as a photographer) uses big Capture One catalogues, anything over 5.000 - 10.000 files takes forever to open and can't be used on a professional level and that's that.
Even with a few hundred RAW files it takes a long time to open a session, especially when you have filters active and you only want to display a handful.
And no, this does not happen just on something like a NAS drive (something where Capture One is notoriously bad anyway), I'm talking about a superfast Samsung M.2 NVME drive with a write and read speed of a few GB/s.
Think about that:- I have a Session with 685 images.
- Every RAW image has about 50MB
-
the Session file itself has 5,81 MB
- the "Capture"-folder has a total of 3.462 Files in 5 Folders.
That means that for 685 images there are an additional 2.777 files which have been generated by Capture One and all of which have to be read each time you open the session.
That's 4 additional files per image!!Now make the same calculation with every image of a 10.000 image catalogue and think how long it takes to access and open them - even on a super fast drive. And - here's the thing - you don't store your archive on a super fast internal drive.
You know what would make sense? To keep most of these files contained in the Session-file itself! You don't need the thumbnails, the cache and the proxies in subfolders of subfolders of subfolders next to the Session-file. Just make it a bit bigger and that's that.
I get why you don't want to have the Settings included in the Sessions-file. If it gets accidentally deleted or corrupted the edits are gone, that would be bad.
BUT: Make the sessions file bigger. Include thumbnails, include proxies, include the cache and - most importantly - keep all the files displayed that have been there the last time it was opened.-1 - I have a Session with 685 images.
-
I think the Problem is that C1 uses not a lot of cores on an CPU to make this tasks.
I work mostly in sessions but also has a Catalog with 6000 files, the catalog is on a cached PCI-E ssd (via PrimoCache) and loading timesare ok, but it could really be faster.
I've a 24 Core Threadripper 3000 CPU and its almost idle when loading or preparing previews.
In October should a new Beta come (as every year) maybe they adressed this.
-1 -
C-M-B, you said:
> You know what would make sense? To keep most of these files contained in the Session-file itself! You don't need the thumbnails, the cache and the proxies in subfolders of subfolders of subfolders next to the Session-file. Just make it a bit bigger and that's that.
I'm sorry to say, your understanding of how Session files work is not correct.
Generally (sorry to be so forthright but) this is a terrible idea, and is exactly why Catalogues bog down. It wouldn't get a "bit bigger." E.g. I have one session with 63GB of images, but the CaptureOne supporting files are 4GB. That means I'd have to open a 4GB file every time to access these photos, and have 4GB expanded into working memory just to work with these files. It also means that it can't be selective - through foldering in my Session I can only work with a subset at a time, improve load times, etc. And it doesn't load all 4 files for every image in a session - it only checks the raw files exist and opens the thumbnails. The mask is loaded only if you have focus masking enabled. And the preview is only loaded for the current and next file (unless you have multiple opened in the Viewer). And the adjustments file isn't opened until you select focus on a file.
If you want to have all your adjustments, thumbnails etc. in one master file, just create a Catalogue where you would normally create each Session.
This does give me an idea though - we need an "Index" in addition to Catalogues and Sessions. This Index would store settings, metdata, and maybe thumbnails, and allow us to qiuckly search and scan across Sessions without the unbelievable overhead of having all these images in a Catalogue. I think I'll submit this to the company for consideration.
-1 -
The point with sessions is, is that they are not for a huge amount of images, that's what catalogues are for.
And the most important thing to display the images quickly are the Thumbnails and they are very very small.
So even with 10.000 images it would only be about 180mb "large".
Those 4GB of supporting files are most likely 100% preview images that are stored locally and they are not needed to display the images in the Capture One Browser, they can be accessed when needed. No biggie.And no, the adjustments should not be stored in the sessions file, I mentioned above why it's a good idea to keep them separate.
Capture One needs to do two things to speed everything up:
1. Index the files that are contained within a folder/session so when you access the folder/session next time it displays them and AFTERWARDS checks whether the files have been changed since the last access. (just like you mentioned!!)
2. stores the thumbnails in the Sessions file to immediately access and display them.
With these changes it would make working much, much faster!0 -
Hi Rob
I really do appreciate your very lengthy and detailed replies here. This is helpful stuff and I'm grateful you took the time to explain all this for me. I bought C1 a year ago and never got around to developing a proper understanding of it. Just when I'd started to apply myself to learning, COVID kicked in and my workload went crazy. Then the import and generating previews thing just put me off. I need to investigate the library aspects ie Sessions and Catalogues and the differences etc
Anyway, I'm going to go through the steps you suggest and make sure these are all followed. Some of them ( the open GL stuff ) I've done but others I will make sure I do too. Thank you very much.
BTW I've noticed the first time I generate previews it takes ages. After that it's not bad. Is this normal?
1 -
@Rob DuMont
I think you have the basis of the way C1 works just right.
My understanding (as a Session user) is that the images in the current selection (something of a variable to describe since the selected Folder or Album may influence a set number of files whereas a smart album (for example) and some of the other "virtual" images groups in C1 may have to discover how many files are to be found since they are search based and would need to be assessed for results even if the last time they were used had generated a new index at that time. Things may have changed.)
My further understanding is that, up to any free RAM memory plus disk cache constraints (what's available, what may be used by other applications, the system, etc.) the thumbnails and previews will be loaded from disk to RAM memory for speed of access when processing. Speed during processing is somewhat preferred to speed during load in that respect, partly because there are ways to limit the number of files loaded by using filters, etc.
The Preview files are typically base level interpretations of the source images. Most of the edit changes and anything to do with output proofing, watermarks and so one will be applied over the top of the base files - thumbnails and Preview. If one looks at the date info on preview files in the session data one can see that the base files rarely change unless something or someone forces the change - re-sizing or re-generation, etc.
One reason for having the separate simple text based edit instruction files is that that are small and changes can be written to them immediately at all times. No need to remember to "save" or "apply" changes. One can do that with a database as well but that might end up being part of the performance conflict.
The challenge for designers taking that core concept into a "Catalog" style of functionality and adopting a wider database to support extended features (e.g. Collections and so on) is that to find a broadly utilised database product with reasonable performance and cross platform compatibility at a cost that is viable for the desktop/enthusiast market, limits the options somewhat. Too many reasons to list here.
But once one has made a decision to seek out that platform the challenge is how to tune its use.
In general one can tune a database to be extremely fast at working with applications that are mainly crunching data or very good and handling records. Image editing combined with a DAM requires both so a compromise is required. This is also true for many other commercial, business focused data analysis tools.
Discussing this with product managers for business applications I have been involved with and working with them on performance testing across large data sets when using a commonly deployed database - such as SQLite - there was always a discussion about where the balance should be set. The "sweet spot" of performance acceptance was almost invariably around 50k records. By which I means that if the analysis work was using 50k record or less people expected almost instant results to anything they enacted. However if they understood that there were over 50k records that was "big" and if things took a little longer it was to be expected.
If the process could deal with 5million records and return millions of lines of results in a few minutes that would be great for them.
It is always a matter of perception, often based on how much the task being processed would take people to deal with manually.
The other thing about perception is whether "speed" is real or mainly appearance. Clever screen handling (even at the possible expense of real performance time) can make something appear to happen faster than it does. It is quite posisble to have a process (especially a graphical process like images editing) that will take, say, 3 seconds to complete and then write the results to screen. 3 seconds may look very slow to the user.
Drip feed the results to the screen with a "big bang" effect up front for visual impact and then drip feed in the majority of the real changes in ways the human eye will have greater difficulty in spotting and you can make the results look much quicker even if they still take 3 seconds to complete and be ready for the next input to be processed.
That is perhaps one of the reasons why different people at different times may say that they find Product A much slower then Product B whilst someone else will describe product B as being much slower than Product A. Perception can be much more influential than we are prepared to accept, both for the loading and processing of data. Data such as images and edits.
C1, as described in some older articles from several years ago, seeks to tend towards a fast processing experience with some attempts at predicting which image might need to be pre-loaded for the next selected image request. So if one starts with images in an indexed order in memory - say file name - and moves through the list the prediction can be made and preloading memory can be applied in the background and all will likely look quite speedy. (subject to the complexity of editing being deployed.).
If people dive around the data in a different order to anything that can be predicted the perceived speed will most likely suffer somewhat. Not so much on big and powerful system but more obviously when system resources are nearer their capacities.
However the original post for this thread and the many of the subsequent comments are not really focussed on large number of records but some extremely slow loading of relatively small numbers of records and that is clearly abnormal.
If it were not abnormal and everyone experienced the same issues almost no one would be using the application. We could also be rather certain that no one would be likely to claim that they thought the application was fast - or at least faster than some other similar applications.
20 minutes to load 500 files, even if new imports with Previews and Thumbnails to be generated, is absurd. Especially for a session but even for a catalog with a large number of pre-existing imported files and a huge number of active filters to calculate it would seem to be an excessively long activity.
(If converting from some other Catalog format, however, taking 1 minute to process 25 images - approximately 2.4 seconds per image - might not be quite so unreasonable even if it was felt excessive for the purpose. Conversion can often offer some unpredictable curve balls.)
If working with a catalog the catalog file structure contains what would otherwise be the cosessiondb file, the thumbnails, Previews, edits, masks, indexes, etc. Even the images if they are "managed". So one might expect internal memory ot be populated quite quickly.
However the experiences reported through the forum seem just as variable as ever. They range from unusably slow to very acceptably quick although what the true results are across all users is probably known to very few people.
Forum reports are too often based on self reporting and perception (Pro or Con in that respect) to be considered as definitive for the entire product experience across the entire user base but 20 minutes to load 500 images certainly suggests there is something influencing the process that should not be influencing the process and does not influence the process for all user all of the time.
I wonder if the Capture One crew has ever considered creating a Server based version of the application? That should speed things up more than a little. At some cost of course. Well beyond any numbers I could justify - or at least that was the likelihood last time I looked.
1 -
@William Scott
"BTW I've noticed the first time I generate previews it takes ages. After that it's not bad. Is this normal? "
Longer, yes because the first creation of the Preview (or a re-generation) has all the work to do. (especially for a RAW file.)
Afterwards the core interpretation preview file exists and simply needs to be loaded to active memory and have any currently in use variables applied to it - Process recipe settings, Proof preview, Style Overviews if you happen to be playing with them - that sort of thing. Plus everything else in the Edit instruction for each variant. Possible multiple variants of the same image if you have then and they are Expanded at the time. But that calculation effort is in memory and not written back to disk as part of the preview file or thumbnail.
However the difference, whilst potentially noticeable, should not be "ages". At least not in my experience unless something is going wrong or some system component is not working as intended.
1 -
Hi Rob
Sorry not to get back earlier but I've been a bit unwell. I tried your ideas on my laptop in bed and I've found that the first time I loaded images iIt's taken me over 4 minutes ro generate previews of 142 RAW and 142 JPEG Fuji Files. The total size of these images in the folder is 6.61Gb. After that if I close C1 down and open it again the pictures are there all ready to go every time.
I'm just. making sure I've been clear that I'm referring to the first time C1 generated a prevue. I'm also wondering if its normal for previews to take such a long time to generate the first time?
Surely not? I'm still calculating for a modestly captured wedding or event of say 3000 images it would take about 50 mins to generate the original previews, which seems pretty poor. Is this normal for C1. I'm suspiciou now though, as iit seems possible that others share my experience of this level of performance.
I'm totally underwhelmed by support from C1 who have just been writing (with some prompts from me ) every few days suggesting I try new things. Their latest idea is to try C1 20?
C1 is a better RAW converter on a "per image" basis than LR IMHO but it seems likely I will return to Adobe as I'm a bit frustrated by this and also they do not seem really interested in resolving it. I did ask them if my figures were unusual or as expected but they ignored my question so ......
0 -
Hi SFA "However the difference, whilst potentially noticeable, should not be "ages". At least not in my experience unless something is going wrong or some system component is not working as intended."
Would you say given your comments, my figures above are abnormal and something is amiss?
EDIT. sorry I see you answered that. Still a bit woozy. Apologies and thanks. I'm not sure what to do about this
0 -
Hi William, sorry to hear you've been sick, speedy recovery!
Ah, yes, I was kinda answering the wrong question. And yes, generating previews does take some time. To be honest, I don't often notice it, as it rarely impacts my process.
When I start an Import with C1, I use a Recipe that creates a new job folder automatically for me. As soon as C1 creates this folder, I browse to it in my Session. C1 doesn't generate Previews until you browse to a folder of images, so this prompts C1 to start creating the previews while the import is occurring.
I don't know the real ratio, but on my laptop C1 seems about 2x as fast at importing as generating previews. This means that when the import completes, half the previews are done already, and I can start my review at the beginning while previews are generating further down the file list. It does not seem to appreciably affect Preview load time to view files while (other) Previews are being generated.
Personally, I often come back from a job, start up the Import, click on the folder, and then go eat or take a break or something. So quite often all the previews are done by the time I'm back at my computer.
Regarding C1 Support personnel - it's important to realize that these are very junior software experts for the most part, and often don't have as deep an understanding as those of us who have been using the software day-in/out for years. Their job is also primarily break/fix support, not end-user training. Not that there isn't a need there, but I find I have to remember the human on the other side whenever I'm dealing with support, and adjust expectations accordingly. Properly, software companies should have "customer experience support" and provide subject matter experts, but margins are too slim and training and keeping these people is surprisingly difficult.
Ultimately, a strong and helpful user community is far more predictive of success with a software product than relying on vendor support :)
1 -
@ Rob Du Mont
+1 for every word of that post.
I mostly follow the same Import process with the same opinions about performance.
I totally agree with your observations about support and the challenges of helping people grow into it and then retaining them in some way.
Likewise your opinion about a strong user community.
And of course,most importantly, a speedy and complete recovery for William.
2 -
Thank you both for your good wishes. I'm much better now thank you. Right now, it's slightly more of a worry if you get a flu-type bug but fortunately it seems to be nothing too drastic.
RE the performance I'm sorry if I didn't make it clear but I'm very appreciative of the tips you gave me to maximise my C1 experience. As long as I know it's just the way things are then at least I can decide if want to work around the preview generation time or not. Honestly, if I accept it as a "feature" and adjust my expectations in that area, the rest of the workflow is great for me. I really like the way it processes my files and in general much prefer it to LR. I guess if I just need to allow some extra time at that stage, its not too big a deal .Probably, once I get used to Catalogues and Sessions and how to get the best from them, I should be good to go.
I accept support is a challenge for many companies and as long as I can get advice on here and sort things out then, thats also fine.
Added to that, maybe I've been a bit more impatient than usual lately and once I feel back to normal it'll be fine.
Anyway thank you both for your help and I really appreciate it. Although it won't change my experience eo this issue I'm sure it will benefit my use of C1 considerably in the future.
All the best
William
1 -
You're most welcome!
When I was considering moving from Lr, the speed was very enticing, but what clinched it for me was trying a side-by-side edit. I First compared the RAW rendering of a couple files without any enhancements, and noticed skin tones and general colours were much nicer in C1. Then I took a couple photos and did my best job editing in both apps and compared the results. The difference was significant, even though I was much more familiar with Lr at the time, and the rest was history.
We can acknowledge that no software is perfect, nor is there one that's best for every single person. I'm sure you'll choose the best for you. Good luck!
0 -
Rob DuMont, THANK YOU! My (what I thought was) small catalog of about 3700 images took forever to stop loading in the browser every time I opened it, and worse, kept scrolling while loading, so I had to wait many minutes for it to stop before starting any work. I have an I9 19850k, catalog on an ssd (images on hdd), 64gb of ram ... I turned off auto-sync and voila! Now the catalog loads in a reasonably short amount of time.
0
Post is closed for comments.
Comments
52 comments