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

Preview, cache, etc..

NNN635158767546269381
Hello,

I am a bit confused about the "preview" in CaptureOne Pro. Maybe someone could clarify.

Well, there is the "preview size" value in the preferences. Is it the size of the preview used for thumbnail and to display the picture if it is offline ? Is it the width or height ?
Anyway, to optimise my catalog space (I only got a limited SSD for catalog storage), I supposed it is the width and sat it to 1440. My main display is 2560x1440.

What about caching ?
when I review my photos, I use the "viewer" and switch between then. It takes some seconds to display each pictures completely. And it takes the same amount of time, if I choose a picture, I looked at a few minutes ago.
Could not (let's say) the 10 last displayed pictures be cached ? Could not CaptureOne "pre-rendered" in background the (let's say) 4 up-coming pictures ?

One non-compressed RGB picture need about 10Mb of memory. 15 in cache about 150MB. This would not be that much for current computers.

My system: MBP 13' 2012, i7 (dual-core), 16Mb RAM, SSD.

Thanks
Regards
0

Comments

5 comments

Date Votes
  • VirtualRain
    Looking forward to answers to this, as I have the same questions. I've tried several different preview sizes and I can't seem to tell the difference between any of them in the viewer. ☹️ And I share your frustration with not cacheing images while you're browsing.
    0
  • PhaseoneUser55657
    The preview size should be set to at least the longest width of your monitor. So for your display, you should select the 2880 size. Yes, this uses more catalog space. It is always easier to down size an image, so the thumb nails and other than zoomed in images, the previews are used. So when you have your preview size less than your monitor size, it has to re-create the image each time you display the picture. I do not think they cache any images other than the "Preview" one, so each time they have to re-create the image. From other threads it is a issue with the 5K iMacs because you cannot even create a preview image of the right size, so every time it needs to be recreated.

    Robert
    0
  • NNN635158767546269381
    Ah Thanks for this insight.

    I sat up the preview size to 2560 (it matches!). Well, it is indeed really faster. Nice 😄

    Well, then, I have another question... SSD being pretty expensive and my catalog getting bigger and bigger, would it be possible to limit the maximal on-disk preview's cache inside the catalog ?

    CaptureOne could delete the oldest preview first. For example, add a "purge" button n the preferences. This would delete preview until the cache reaches the limitation.
    "Purge all" maybe as well.

    Maybe PhaseOne team is listening 😊.

    Have a nice day
    0
  • PhaseoneUser55657
    That would be nice, but have not seen anything in CO to do that.
    0
  • SFA
    [quote="NNN635158767546269381" wrote:
    Ah Thanks for this insight.

    I sat up the preview size to 2560 (it matches!). Well, it is indeed really faster. Nice 😄

    Well, then, I have another question... SSD being pretty expensive and my catalog getting bigger and bigger, would it be possible to limit the maximal on-disk preview's cache inside the catalog ?

    CaptureOne could delete the oldest preview first. For example, add a "purge" button n the preferences. This would delete preview until the cache reaches the limitation.
    "Purge all" maybe as well.

    Maybe PhaseOne team is listening 😊.

    Have a nice day




    Create a Support Case indicating that it is an "Enhancement Idea:" in the title. That way you know Phase will hear you. (There was a post a few days ago about the preferred wording in the description - I'm not sure I got it right in the text above.)

    I sometimes use a different system that keeps a rolling Cache for each image preview create. The amount of disk allocated is managed by the user. The maximum happens to be 5Gb. Great!

    However once that is used the system has to try to decide how best to reorganise the cache to get the next image into it. Which takes a little time. Every time. And sometimes does some odd things. You can take some time to clear the cache ... but who really does that? And it's all or nothing so no selectivity - but really that would be pointless anyway if seeking time saving.

    I suspect that a further complication is that C1, so it seems, is rather interactive in most usage situations. For one example - change an output recipe when working in a session and all the previews and the current Viewer image(s) will be adjusted to reflect that. So there is a trade off between keeping the current image in the viewer calculated to the the latest state of settings or keeping that and the rest of the images in the Cache updated to the latest settings at the viewing size.

    One might end up performing a lot of calculations that are never used. Whether the overall result would be beneficial is maybe not so easy to assess. There are, for example, some views that suggest SSDs are not ideal for extended lives due to concerns about how many read/write cycles they can perform reliably. Assuming this is a real matter for concern in practical use increasing the number of calculations that will almost certainly need to use the disk in some way even if only to record the 'last used state' may not be the best way forward.

    If using spinning disks then there is less of a problem in that respect but you might not get the speed .... and so on.

    I'm sure there are some design issues and trade-offs here, not least how the database is set up - you usually have to tune the operations to best suit you purpose overall rather than making it ideal for all situations. Databases can be like that. Plus there are multiple platforms and hardware configurations to take into account.

    I suspect that the best results will come from the anticipated increase in the computing power of components and screens in the next year or two. Then everything will move up a level and we will start a new performance development circle!

    My thoughts, for what they are worth.


    Grant
    0

Post is closed for comments.