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. ⚠️

Why does Capture One Catalogue need to access raw files ever

Dave R
I am once again considering a complete switch to CO from Lightroom so have set up a catalogue of my entire collection of 35000+ images. I am finding that opening the catalogue each time is very slow on my Win 10 machine (i7, 32gig RAM, Nvidia 960, 1 Terabyte SSD). Now some of my pictures are stored on an online archive which is accessed through my internet connection (fast - 200Mb/s) and I notice that even though CO spent many hours building pre-views each time it starts up it seems to access these on-line pictures again. Thus it spends 2 or 3 minutes on-line to the archive before the catalogue is fully ready to search. While I understand that individual pictures that I want to output, print etc. will need to be retrieved from the archive for processing I do not understand what is happening when the application is launched. This is a bit of a problem - Lightroom does not seem to exhibit this behaviour. Anyone know what is going on?
0

Comments

8 comments

Date Votes
  • Samoreen
    Hi,

    I did some monitoring on the C1 process and also on the catalog database. Indeed, when starting up, it seems that for some reason(s), C1 enumerates the contents of the folders referenced in the catalog, which may takes more time on the network.

    Maybe it simply checks the existence of the RAW files. I don't see any other good reason to access the RAW files while launching since the referenced files can be enumerated from the catalog database itself. When launching, C1 just needs to retrieve the thumbnails and a quick look at the database structure shows that this is possible by directly using the data stored in the catalog without any need to enumerate the files with a call to the OS file system.

    I also noticed a high number of accesses to C:\Users\PatDev\AppData\Roaming\NVIDIA\ComputeCache\ and its sub folders and I'm wondering why since this cache is related to CUDA and 3D, AFAIK. But this is not related to your problem. I'm curious, though...
    0
  • SFA
    [quote="Samoreen" wrote:


    I also noticed a high number of accesses to C:\Users\PatDev\AppData\Roaming\NVIDIA\ComputeCache\ and its sub folders and I'm wondering why since this cache is related to CUDA and 3D, AFAIK. But this is not related to your problem. I'm curious, though...


    This may give some general background to how the computecache is used.

    https://devblogs.nvidia.com/parallelfor ... t-caching/


    HTH.


    Grant
    0
  • SFA
    [quote="David532" wrote:
    Now some of my pictures are stored on an online archive which is accessed through my internet connection (fast - 200Mb/s) and I notice that even though CO spent many hours building pre-views each time it starts up it seems to access these on-line pictures again. Thus it spends 2 or 3 minutes on-line to the archive before the catalogue is fully ready to search. While I understand that individual pictures that I want to output, print etc. will need to be retrieved from the archive for processing I do not understand what is happening when the application is launched. This is a bit of a problem - Lightroom does not seem to exhibit this behaviour. Anyone know what is going on?


    You may have an in-line connection rated at 200Mb/s but is the server at the other end actually delivering at that speed consistently? And can your system receive at that speed consistently? When I run a speed test to a relatively "local" server I usually see numbers that tell me the best speed achieved is within 10% of claimed performance. However, point to a server in a different country or a different part of a large country and the numbers are generally much reduced.

    As for Capture One vs Lightroom -- I suspect that LR presents you with its jpg preview files (small) and then waits for you to do something that requires it to recalculate using the original file.

    Capture One, in the main, is designed to operate on the original file from the start of its processing. The exception, for catalogues, is that it will allow you make "edits" with certain tools if you are using catalogues and the original files are not currently "on-line". It shows you the results based on the preview file. But if you need to see the full image and the real effects as visible at 100% access to the source file is required.

    This comes up so often that it is probably about time there was a webinar or tutorial video produced to explain things in some detail. Absent that we are all mostly guessing what happens and how that might affect performance.


    Grant
    0
  • Christian Gruner
    [quote="SFA" wrote:
    [quote="David532" wrote:

    As for Capture One vs Lightroom -- I suspect that LR presents you with its jpg preview files (small) and then waits for you to do something that requires it to recalculate using the original file.


    CO works in the in same way 😊 Things like massive keystone or massive distortion will prompt a full recalculation of the preview
    0
  • SFA
    [quote="Christian Gruner" wrote:
    [quote="SFA" wrote:
    [quote="David532" wrote:

    As for Capture One vs Lightroom -- I suspect that LR presents you with its jpg preview files (small) and then waits for you to do something that requires it to recalculate using the original file.


    CO works in the in same way 😊 Things like massive keystone or massive distortion will prompt a full recalculation of the preview


    What about something like the Preview size being very different to the current display size? Would that prompt a recalc from the RAW file?

    Or a different output recipe to that used when the preview file was created?



    Grant
    0
  • Christian Gruner
    If the preview size is smaller than the Viewer size, then that will also cause a recalculation. Which is why this should be set to roughly the Display resolution (no smaller or bigger).

    Selecting another recipe will never trigger a deep recalculation from file.
    0
  • SFA
    [quote="Christian Gruner" wrote:
    If the preview size is smaller than the Viewer size, then that will also cause a recalculation. Which is why this should be set to roughly the Display resolution (no smaller or bigger).

    Selecting another recipe will never trigger a deep recalculation from file.



    Even if that recipe has a different proof profile?

    Is it then fair to suggest that full and correct representation of an image only appears at 100% - or at least after a recalculation so maybe 50% or 65% would produce a recalc if the stored preview size was quite small compared to the file size?

    How do crops and crop manipulation fit into that?



    Grant
    0
  • Christian Gruner
    [quote="SFA" wrote:
    [quote="Christian Gruner" wrote:
    If the preview size is smaller than the Viewer size, then that will also cause a recalculation. Which is why this should be set to roughly the Display resolution (no smaller or bigger).

    Selecting another recipe will never trigger a deep recalculation from file.



    Even if that recipe has a different proof profile?

    Is it then fair to suggest that full and correct representation of an image only appears at 100% - or at least after a recalculation so maybe 50% or 65% would produce a recalc if the stored preview size was quite small compared to the file size?

    How do crops and crop manipulation fit into that?

    Yep, the preview doesn't care.
    For a full representation, the image should be viewed at 50% or more. That will force a from file recalc.

    Crops will act the same way as zoom.

    Grant
    0

Post is closed for comments.