Skip to main content

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

C1 catalogues are exceptionally slow on my Macs

Françoise Nayroles
I work very easily with all my shots in a single session; I then separate RAWs and JPGs.
When I create a catalogue in C1, I import folders that only contain JPGs 2000 pixels wide.
Before that, I would have keyworded the JPGs with PhotoMechanic using up to three levels:
Architecture | church | indoor
The catalogues are correctly created (I conducted many trials), but it went so slowly that I had to limit my catalogue to only 2000 shots. Yet I have more than 12,000 shots to catalogue.
When I use keyword filters---e.g., 16 shots have the tag Family | Dupont ---, 10 thumbnails are shown in the browser in 3 seconds; then 2 more appear after several seconds; 4 of them remain entirely black with the wheel spinning indefinitely. When I click on a black thumbnail, the picture is displayed in thebrowser. At last I have my 16 shots, but the white wheel keeps spinning.
Applying a newfilter is a prowess. Though C1 does not crash, I observe that the CPU load climbs to 170% and more. Activating or disabling OpenCL has no effect.

I work with two Macs with Yosemite 10.10.5
MBA 2 GHz intel core i7 8 Go [RAM]
Macmini 2,6 GHz intel core i7 16Go [RAM]

I have no speed issues with CS6, Lightroom (cataloguing) and Photo Mechanic
C1 is slow, even it is the only open application.

Thanks for help
Françoise
0

Comments

9 comments

Date Votes
  • harald_walker
    Where is the catalog stored? Internal disk or external disk?
    Are the images in the catalog or referenced?

    But I also find keyword searching quiet slow. It works better if you organize images in projects, albums etc. and then search for keywords within such a sub-selection. I have already created a support ticket about it. Maybe do the same. I took a screencast to show them how long it takes to show some results.

    And am wondering why you are using C1 for resized JPG files? Main reason to use C1 for me and probably most of us is the quality of the raw processing.
    0
  • Eric Nepean
    I have been struggling with the same problem for months.

    @soizic - what kind of image files do you ahve in your library - any Panasonic RAWS or JPEGs by any chance?

    I have a catalog with 17000 referenced images, stored on the main hard drive.

    The time to load the catalog is very slow (which I could tolerate) but the time to set up a filter is sublimely ridiculous. Every single key stroke and mouse click used to setup the filter causes the C1 to hang for 1 minute or more. The frustrating part is that screen does not update until C1 is finished its hang. So you are sitting there for minutes at time waiting for confirmation that you have hit the right key or clicked the right icon.

    I think what is happening is that C1 recomputes all the database indices at every user action, before updating the application window.

    God forbid you hit an incorrect key - to delete it requires another minute. And then you get to wait another minute after you type the correct key.

    PhaseOne advertises that a CaptureOne catalog can be used to organize all your images, so that you can find images by searching

    You can, but only if you have Mac Pro, its seems.

    I have mentioned this to Tech support and on this forum, the usual answers are 1) Your Library is too big 2) Your computers are too old 3)You should be using sessions not catalogs.

    I have never hear the comments that should in my opinion be given - "here is the recommended system for this kind of catalog" or "for this kind of HW and operating system you should configure your system thus" or "we recognize our application is unworkable for you"

    I have got very similar results on three systems.
      System 1 is an iMac11,1 with, 2.7GHz quad core i5 and 16GB RAM and 1TB magnetic main drive. OSX 10.9.5
      System 2 is a MacBook Air with, 2.6GHz dual core i7 and 8GB RAM and 0.5TB flash main drive. OSX 10.9.5
      System 3 is a MacMini6,2 with, 2.6GHz quad core i7 and 16GB RAM and 1TB magnetic main drive. OSX 10.9.5
    0
  • Françoise Nayroles
    Thanks, I do not feel alone !
    (sorry for my english which is bad, I am french)

    Pictures : NEF Nikon and ARW Sony

    My MBA (SSD 256 Go) is used for showing pictures, so 2000 pixels max is good for SSD. RAW and heavy JPG are on my Macmini. in my desk.
    Catalog is made with referenced pictures.

    I appreciate quality of the raw processing of C1, all my RAW are worked with C1 in an only session.
    0
  • Eric Nepean
    Now that is a useful reply!

    We can eliminate image type as a common factor since I have many Panasonic images (RAW and JPEG), and no Nikon NEF or Sony ARW, and you the opposite.

    We can also eliminate OS version as you are on 10.10 and I am on 10.9

    We share very similar HW (which should be adequate for this work), we both have 10K-20K referenced files, and we both have 3 levels of keywords.

    I have set "Sync Metadata" to "never" on the theory that updated many XMP files will take some time.

    I think my next step will be to try to remove all the keywords from the images in my test catalog (not the real one) , I have to find a simple way to do it, I cannot afford to do it one by one.
    0
  • Photocor
    Hello,
    I met this when my preview were in a different size between native definition of my screen.
    Today, my screen definition is 2560 x 1440 (cg276), then my preference in C1 for preview is 2560. I think when it is different, C1 redefine each time the preview.
    My config: Yosemite 10.10.5, Mac pro 3,5ghz 6 core, ram 16go, graphic 2 x AMD Fire pro 500.
    Regards
    0
  • Helmut Kaufmann
    Good afteroon,
    There have been quite a few posts regarding slowliness of the catalog on Mac (and probably the same challenge with Windows). The common conclusion mostly was that it matters little how good your hardware is - the system seems not to be built as a DAM, but a raw development engine (which - without doubt - it is a great one). Looking at the size of the database (I have about 50k referenced images), it actually should be easily possible to keep it fully in memory - and querying SHOULD be lightning fast. Fact is: It is not - and there are many possible reasons why this is the case. Personally, I think it is the design of the database and the way it then gets queried plus a lot of I/O when the system fetches the thumbnails/previews from basically a flat directoy structure. I have tried quite a few things, especially generating new indices on the underlying database. It helps a bit but there is no miracle.
    I believe the slowliness is a missed business opportunity in some case as there are many users out there preferring a single DAM/RAW processor and are willign to sacrifice quality and move to Lightroom as a "single engine" as opposed to having a standalone DAM with CO as the raw processor. I would have appreciated a comment from the CaptureOne staff (eg a design engineer) but I understand that this might not be the right place to raise it (and I also don't think a ticket is the right place as the system seems to work as designed).
    Best,
    Mercator
    0
  • harald_walker
    [quote="Eric Nepean" wrote:
    Every single key stroke and mouse click used to setup the filter causes the C1 to hang for 1 minute or more.

    As it seems to start searching while you type or as soon as you wait a fraction of a second. I would prefer a search input field that doesn't start searching until I hit return or a search button.

    [quote="Eric Nepean" wrote:

    I have mentioned this to Tech support and on this forum, the usual answers are 1) Your Library is too big 2) Your computers are too old 3)You should be using sessions not catalogs.


    If that's the answer you got then that is very unfortunate and not a good sign.

    I agree with mercator that it seems mostly to be an architectural issue and it is one that can be solved. This is not rocket science.

    What I am concerned PhaseOne should give performance, DAM features and usability highest priority on their roadmap. I am otherwise quiet happy with the rest. 😊
    0
  • Françoise Nayroles
    Photocor say :`"Today, my screen definition is 2560 x 1440 (cg276), then my preference in C1 for preview is 2560. I think when it is different, C1 redefine each time the preview."

    Not a solution for me, I have a display apple screen when I work in my holidays home with my MBA 11 inchs.
    0
  • Eric Nepean
    Harald and Mercator

    Thanks for two interesting posts, sorry I missed them but email notification does not work on this forum.

    Much like your observation on searching, what I see is happening is the C1 start recomputing its database indexes as soon as it receives any user entry - be it a mouse click or keystroke - and once it start recomputing the database entries it does not accept anymore user input, even if there is a cue. This activity seems to lock out all other processes, so there is no window update, and the operating system reports that C1 is non-responsive.

    There are several poor design choices that interact to make this situation even worse for the user
      the user is left waiting for feedback on his entry until re-indexing is finished - he does not know if he typed the right or the wrong key for a long time
      when the database re-indexing is finished, C1 does not take the whole queue of waiting user inputs, it only takes the next item. If a long word is typed, such as "North America" the database indices are recomputed for each letter in the string, instead of first computing for "N" and then the the rest of the string. In my case it will take 13 minutes to process that simple string if I have the misfortune to enter it into a filter.
      Database re-indexing is very inefficient - running Activity monitor while C1 is busy responding to key strokes reveals that there are almost no disk reads and writes, RAM is not full, and that only a few processor cores are loaded - so C1 is not using the full resources of the computer, and it is not blocked by disk reads or a full memory


    I beleive these issues most likely reflect a poorly chosen SW architecture, something which is very difficult to change.

    I believe this is also means is that buying a machine with more cores or an SSD or more faster GPU will not help much - the speed is limited by the capability of one or two processor cores.
    0

Post is closed for comments.