メインコンテンツへスキップ

⚠️ Please note that this topic or post has been archived. The information contained here may no longer be accurate or up-to-date. ⚠️

Maximum recommended number of images in catalog

コメント

10件のコメント

  • Permanently deleted user

    1) Are you sure all the previews have been built after the import ? 1.2 GB seems to me rather small for a 70k images catalogue.

    2) I know people having catalogues up to 70k+ and using it without any issue.

    3) Many people have encountered problems with Capture One when using a NAS to store their images.

    4) Capture One shouldn't crash with about 100 images ! I have a catalogue of about 25k images, and Capture One never crashed with me.

    0
  • billtils

    This is very strange.  As Robert points out 1.2GB for a 70k catalog is odd (it works out at 17kb per image) so whatever you've done, you haven't imported the images from your LR catalog.

    I create a new catalog for each year and keep the older ones on a 3TB external USB.  Out of interest I have just opened one of them created in CaptureOne 12 and updated the catalog to v20.  It contains 16,465 images in 425GB of space and once the catalog was open (about 15 seconds) basic edits were instantaneous.

    One thing to check - are you using a managed or referenced catalog?  I dallied with LR for 9 months but got fed uo with its interface and came back to CaptureOne using a referenced catalog pointing to the  folder on the iMac internal SSD that contains all my download images including those edited in LR.  Opening and editng is instantaneous.

    I don't know what you do with the images from your SD (or CF) card but it may be worth downloading some to a new folder on your hard drive, then deleting and reinstalling CaptureOne and create a referenced catalog pointing to your new image folder.

    If you are unclear about referenced v managed catalogs, look it up in the CaptureOne documentation.

     

     

    0
  • Wandern

    I've made so many catalogs trying to get C1 to import anything without crashing that I referred to the wrong one.  The catalog for 70k images is 23GB (on my SSD). 

    The catalog is most certainly referenced (not managed); the images themselves occupy over 1TB.

    0
  • Jeremiah LaRocco

    I've had similar problems with photos on external drives since version 10 or 11, and unfortunately C1 just doesn't seem to work well with images on an external drive.

    The workaround I use doesn't scale, but I do all my work on the internal drive, then move it all to the external drive when I'm done.

    In some cases, with small sessions, it's faster to copy the whole session onto the HD than it is to switch between images inside C1 with external images.  It's frustrating because it doesn't make any sense.

    0
  • Permanently deleted user

    C1 just doesn't seem to work well with images on an external drive.

    I suspect it has to do with the speed of the external drive and the location of your .cocatalog and/or .cosessiondb files.

    I have a catalog where the .cocatalog file resides in my Pictures folder on my main drive, but all images reside on an external USB C SSD drive.  I have no disk related performance issues with that setup.   I also have a few sessions also located in my Pictures folder.    The sessions reference folders on the external drive.  Again, no disk related performance issues.

    When I write "disk related performance issues" I'm saying that performance is the same when the images are on the external drive as it is when they are on my main (SSD) drive, not that there are no performance issues.  Image import, for example, is much slower than I think it should be.

    0
  • Wandern

    It appears that C1 is still processing previews from the images.  I've had it running in the background for a few weeks and my catalog is now up to 120GB, with C1 using 100-300% CPU from time to time.

    How can I tell how many of the images in the catalog have had previews generated, and show the currently active background tasks taking place in Capture One?

     

    0
  • Wandern

    To continue to update this issue, I removed all of the C1 generated previews from the library, and the newest version of C1 immediately started building previews from the images stored on my NAS.

    The rate of progress is inexplicably almost an order of magnitude better than with the previous version (C1 is processing over twenty 30MP images per minute into 5120 x 2880 previews), and I have not yet had a single crash.  The previous version crashed every few thousand images even after several imports and preview rebuild attempts.

    C1 absolutely needs better thread management, however, as the editing interface is unusable on a quad-core machine when C1 is only using around 2 cores for its background work (and all other processes are perfectly responsive).

    0
  • Wandern

    To close out this thread, I moved all of my images to a USB3.1 connected SSD that benchmarks at 750MB/s+.  C1 built previews on all 70k images in under a day, but it continues to be completely unusable to actually do anything with the library - it appears to be fundamentally broken, because there are absolutely no resource constraints (CPU cores, frequency, memory, disk space, disk I/O bandwidth, etc.) that explain its sluggishness. 

    Every few seconds, regardless of what operation is being performed (anything from clicking on a menu item to adjusting a photo setting), C1 "beach balls" for 30-60 seconds.

    I'm admittedly very disappointed; I've invested a month into trying to use Capture One, but it's simply not a usable product for my needs (I can't operate with a dozen 5,000 image catalogs).

    I'm willing to give Capture One another shot in the future, but I would recommend your development team actually put some resources into establishing minimum performance characteristics as catalog sizes scale.  There's simply no conceivable excuse for this code behavior with so few photos; even the simplest sqlite database backend should be able to handle hundreds of thousands of images easily on a machine with these specs.  Profiling your code and finding the culprit should not be a difficult task.

    1
  • SFA

    You should use the "Submit a request" option to create a support case to discuss you issues directly with the C1 support team and obtain a personalised response.

    Here you are mostly discussing the problem with other users.

    FWIW I mainly use sessions so the number of files rarely exceeds about 6000. But I may have 2 or 3 session open.

    Working on local drives the performance is fine for my needs, even on my old notebook.

    Working from a USB3 drive can be a little erratic but performance mostly OK provided I am not running my C drive short on space to use for the temp filed and memory cache.

    My NAS seems to have a speed of its own - probably partly due to its own file management activities and the many writes that C1 is likely to be making to the files on the NAS. No surprise. I selected the spec. based on price for a backup facility rather than an integral part of a high volume interactive processing requirement.

     

    Your needs may vary form mine. So best ask the C1 Support Team for assistance.

    0
  • Carl Antaki

    I do agree that as users of a professional application we need to know what's the recommended maximum number of images that Capture one supports. Before I had 70k images on Aperture, Photos also seem to support 70k. I have now 43k referenced images on Capture one 20, I haven't tried importing the rest because of fear to destroy my catalog which forces me to remain on High Sierra to be able to re-export my Aperture catalogs in case of an issue. I don't want to have to use different catalogs because it doesn't make sense, 70k or 100k is not a big number. It's important to use the proper data structures in the code to ensure your performance is good. If Apple was able to do it 8 years ago - then Capture one can do it. They need to invest time in optimizing Capture one not just releasing new features

    0

投稿コメントは受け付けていません。