Zum Hauptinhalt gehen

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

Poor performance when browsing and culling

MatBe
Hi,
I'm using the latest C1 version on a 15' MBP from mid-2015 to process 24MP raw Sony files.; both catalog and images are on the internal SSD.
When browsing through images at a sustained pace (1-2 seconds per photo) the next image is shown pixelated for 1-3 seconds, then becomes sharp.
I've tried changing the preview size to a high, medium and low value, recreating previews in between changes; this had no impact whatsoever.
The issue happens in both single and dual monitor mode, whether I've already viewed the image or not. Memory consumption is below 4GB of the 16GB available.
If i wait for 7-8 seconds the next image will be sharp, no pixelation/blurring occurs.

This is slowing down the culling process a lot, I'm considering switching to another tool.

Any suggestion to fix the issue?
0

Kommentare

20 Kommentare

Datum Stimmen
  • SFA
    I would suggest that it's not normal EXCEPT in a situation whereby you might be putting an exceptional processing load into the edits (perhaps always using a feature that has to do a lot of work - spot correction with a lot of spots for example, LCC corrections, a lot of layers each with a lot of adjustments.) I doubt most people do this so assume you don't either.

    I would suggest you best option would be to create a Support Case and provide the Log files as the Case logging activity will suggest. The Tech team should then be able to assess the logs and, hopefully, identify the activity or activities that are causing the less then preferred performance.

    Anything that does not include assessing the log files would almost certainly be advice based on guesswork in this case as reported.


    HTH.

    Grant
    0
  • MatBe
    Thanks Grant, I'll check with support, it's the first activity I do after the import.
    0
  • SFA
    [quote="MatBe" wrote:
    Thanks Grant, I'll check with support, it's the first activity I do after the import.


    Immediately after import (depending on what you are thinking of as "import") there is usually some activity going on to create previews and thumbnails. That may continue for a while after C1 tells you it is has imported xxx images.

    During that time C1 can be used for editing and so on but if the preview and thumbnail preparation is incomplete there is a chance that you might pick an image that is yet to be processed and/or your disk access and processing demands are competing with the background generation of the thumbnails and previews.

    So the question is - is it possible that such generation is still occurring as you start your culling and, if it is, are things still slow if you allow a short while for those processes to finish before starting the culling process?

    How many images are you typically importing in a single import session? Any other actions going on? Automatic back up for example?


    Grant
    0
  • MatBe
    Thanks Grant,
    I checked with activity monitor, the CPU is idle before the action.
    I've also noticed that flipping back and forth between 3 images also triggers the issue: first i see the highly pixelated version, then comes the preview (slightly blurred) then the real thing. Each folder in the catalog has around 100 images.

    I've reproduced the same behaviour on a 2017 MBP 13'; things are somehow better, despite the slower CPU (but faster GPU) of the device.
    I guess I'm pushing C1 beyond its limit by culling at a sustained pace.

    Have a nice day,
    Matteo
    0
  • SFA
    Out of interest do you have any custom power management profiles set?

    My thinking here is that the firmware will be attempting to keep processor and GPU temperatures under control and may throttle speeds to some extent if it feels there is insufficient cooling rate for the components.

    It's a long shot but now and again I notice that my Windows notebook workstation has got to the point of running the cooling fans flat out all the time even when doing relatively little work and the reason is usually clogged heat exchangers in the area of the fans.

    Difference in performance between machines of relatively similar specification may well be related to either specific hardware performance or some other factor like age and "dust load" - something that is much more finely balanced for laptops than it is for desktops.

    Of course the other similar factors include what may be hogging resource in the background and any disk management activity that is going on but those influencers usually only have relatively temporary effects.

    The other thing that can load the system is if your default Preview size is not in line with your native screen resolution - but I would guess that the C1 support team will cover that angle and of course you have already tried different preview sizes - although anything other than a match to the native screen size may result in some sort of a resizing requirement prior to display.


    Grant
    0
  • MatBe
    I've set the preview to a fairly low res, 1280px, as that would be enough for culling.
    No specific power management profile. I'll try to post a video when I'm back from holiday.

    Enjoy light,
    Matteo
    0
  • SFA
    Do you have an output recipe selected by default?

    If so what is it defined to do and do you have proof profiling active?


    Grant
    0
  • MatBe
    I'm back, time for culling...
    I have no output recipe or proof profiling active.
    I have now installed C1 on a 2017 MBP 13" to compare performances. Although the MBP 13" CPU should be slower, it's snappier and has less lag than the 2015 MBP 15". Maybe the faster GPU makes the difference.
    0
  • Permanently deleted user
    I bitched thoroughly about a year ago and nearly lost my sanity. The 2 image caching is more or less design behaviour. I let go because life goes only so far... (this, along with a whole batch of database issues, are worse in windows)

    What can extremely exacerbate loading times is having your preview size set to a resolution smaller than your largest screen. For your retina 15" it should have been 2880px at a minimum.

    You have to understand that capture one generates proxy 'raw' files, and not 'rendered' jpeg-like previews. If the horizontal resolution of the proxy is lesser than the screen's, C1 will seek and render the original raw file every time you select another image.

    Your new MacBook might still be set to default(auto) and have a bit of luck.

    Cheers.

    PS: The new CPU is not slower. These intel chip upgrades have kept the processing power going up slightly, with significant drop in power consumption and overall architecture optimizations (even if you went from an i7 to an i5).
    0
  • César Barroso
    I'm having the same issue on a very expensive and supposedly powerful 15" macbook pro. Never had this issue on my four-year-old self built pc. On the PC (which granted had 1920x1080 monitors) previews were sharp and snappy.
    0
  • Sheldon Chang
    [quote="MatBe" wrote:
    I have now installed C1 on a 2017 MBP 13" to compare performances. Although the MBP 13" CPU should be slower, it's snappier and has less lag than the 2015 MBP 15". Maybe the faster GPU makes the difference.


    13" MBPs don't have dedicated GPUs. I would expect the 2015 15" MBP to be faster actually.

    I have a 2016 MBP and I got a BlackMagic eGPU to help with culling speed. That didn't work at all. Adding an external GPU actually made culling slower. I'm returning my eGPU because after adding it, my pixelated previews went from happening occasionally and usually lasting less than 1 second to happening more frequently and regularly taking about 3 seconds or more. Additionally I went from having little to no lag in between navigating to the next image to the interface freezing if I advanced too many frames in a second. If I held down an arrow key to quickly run through the photos, the screen sometimes just blacks out. That never happened with just using the onboard Radeon 460 on my 2016 MBP.

    I've found that just using my 2016 fully loaded MBP alone in clamshell mode to drive a 5K monitor as being the best for performance. I'm disappointed about the eGPU. I was hoping that adding it would all but eliminate preview rendering time.

    [quote="SFA" wrote:
    The other thing that can load the system is if your default Preview size is not in line with your native screen resolution...anything other than a match to the native screen size may result in some sort of a resizing requirement prior to display.


    As for preview sizes being set to the size of your largest display being the best way to go, I haven't found that to be true. 5120 is my largest display. Setting the size to that results in everything taking longer. It was previously set to 1024, which was likely what it was set to by default. That seemed to be a pretty good setting for me.

    When are previews used anyway? I really don't think I'm looking at the 1024 sized preview when I'm culling.
    0
  • SFA
    When you say 5120 is your largest display does that imply that you are using multiple displays at the same time with different resolutions?

    What image dimensions do your cameras produce?

    If you are working in the Browser window you are looking at Thumbnail - very small files, low resolution. If you are enlarging then to be more visible on a 5k screen I would guess what you are seeing is not great.

    The Preview files are intended to be intermediate sizes that give a decent starting point for editing purposes without being excessively large in terms of storage, transfer capacity and memory demands. They are the files presented in the viewer (or at least the default size that is expected to be presented in the viewer window) and therefore the images on which your on-screen editing is made visible. However if your editing takes you off to different sizes then the original preview file will be replaced in memory by a revision likely based on the source file with the edit stack applied.

    What you will see of them on screen will depend to some extent on things like process recipe settings and whether or not proofing is in operation.

    This is a very basic outline of the sort of things that are going on in an editing session. I think the description should be close enough to being accurate for the purposes of this part of the discussion.

    If you store at 1024 but view at a significantly larger size by default on the screen then C1 will have no real purpose for the preview and will need to recalculate from the original file in order to the include the detail in the original file (assuming it was larger than 1024) in order to present what you expect to see to best effect.

    Similarly if you store at 5120 but for other screens or other purposes do not naturally display at that resolution and require smaller then it will need to work out what to throw away before it can present the image at the size you are requesting.

    With relatively small files the effect on processing time is usually small (depending on what processing has been or is being applied) but as files grow in size the processing overhead becomes quite significant.

    I've often wondered what the processes do if one is running multiple screens with different resolutions. However since I currently use a notebook and occasionally a larger external screen with the same resolution for me the question is of academic interest rather than for practical usage concerns.

    That said I read some comments recently that questioned the use and benefits of 4k screens (and thus 5k screens by implication), especially small ones. It was an interesting read and made a lot of sense.

    I mention this because I suspect that some aspect of screen size, hardware and expectations could be at the root of your disappointment.

    HTH.


    Grant
    0
  • Eric Valk
    On my 2015 iMac with 5120x2880 display, I was getting reasonable performance with previews set to 2560. The pixellation in the viewer would last between 0.5 seconds and 1 seconds when browsing quickly.

    Upon reading this thread, I changed the preview size to 5120, and let C1 update the entire 16000 image catalog. The pixellation while browsing quickly now lasted much longer!!

    Then I realised that although the screen size is 5120 pixels wide, the image size in Capture One is significantly smaller.
    • With a 3:2 image fitting in the Capture One main window, the horizontal dimension of the image is 3786 pixels.

    • With a 4:3 image fitting in the Capture One main window, the horizontal dimension of the image is 3280 pixels.

    • The vertical dimension is 2870 pixels.


    Now I have changed the preview size to 2880. No results yet, regenerating previews on the whole catalog is a 2 hour job.
    0
  • SFA
    Eric,

    What you have pointed out is something that I have been wondering about for some time.

    I think the standard recommendation to set the default resolution to the native resolution of one's main display will normally make sense, especially for anyone who regularly uses full screen mode and anything up to an HD (1920px) screen.

    At that size even if resizing is applied the level of calculation on a pixel count basis is likely to be quite small. In principle the edit might be applied to the preview and re-displayed - which presumably is what happens when using catalogues and editing in "off-line" mode. If the adjustments can be made to an image map that has already accounted for significant reduction in the number of pixels in play (and to the detail level of the calculations) the apparent speed ot performance may well be much faster than working with the full file.

    If one is starting with full resolution at around 5k but reducing that to around half width and height then there are a lot of pixels to assess and discard every time one does anything at all. Working with final detail editing on a single image that performance is probably mostly acceptable. However for fast review and culling (or similar) it is likely to seem slow in a way that is far more obvious than any relative changes in performance would appear working with lower capacity screens even on the same size of file.

    All of which might lead one to think that there is a case for using sessions at the culling phase and relatively small preview files with the expectation of speed for the task. Then after culling and whatever else one chooses to do at that point, change the preview size and re-generate or, maybe in certain work flows, import to a catalogue running with larger preview sizes.

    There are of course many other factors that would influence such a decision and it may well be that anyone not using a 5k or maybe a 4k screen would gain much less perceived benefit than would justify such a work flow.

    Maybe there is someone out there already using this approach or who has tried it at some point in the past. In which case it would be interesting to hear what they might have to say about it.


    Grant
    0
  • Eric Valk
    Update: With preview size at 2880, fast browsing and culling works much faster than with preview set to 5120.

    The screen arrangement is like this:
    • iMac 27" 5K screen
    • Capture One main windows covers the entire screen except the dock at the bottom and the menu bar at the top
    • Capture One has minimum size ToolBar on the left
    • Capture One has browser on the right
    • Capture One Viewer covers the remaining area, which is about 3:2


    @Grant - I'm in a rush now, but I agree with your thinking.
    0
  • MatBe
    Finally I've done some testing with interesting results.

    The system setting display scale has a huge impact on performance. My MBP 15' has a native resolution of 2880x1800. However, in scaled mode the OS renders at a different logical resolution (3840x2400 with the smallest font size, 2048x1280 with the largest), then scales the image to fill the screen.

    I've done a test flipping back and forth between three 24Mp images (I understand C1 caches in memory only the next image) at 3 different scales. Judge yourself from these cropped captures:



    At the highest resolution it takes about 5 seconds; at the native about one second, and at the lowest, well, it's so fast that the spinner doesn't show up most of the time.

    Please note that the "time to sharpness" and the "time to idle" are different, as C1 needs more time to prefetch the next image.

    Interestingly, changing the preview resolution has no effect whatsoever, I've tried changing it between 2560 and 640 (and recreating previews) without visible difference. Maybe I'm doing it wrong.

    TL;DR: sticking to the native screen scale brings the C1 performance to an acceptable level.

    I also wish that C1 would keep more than 2 images cached in memory, as i often go back and forth a small set of images (3-6) to quickly pick the good one and cull the rest. PhaseOne are you listening?

    Have good light,
    Matteo
    0
  • SFA
    [quote="MatBe" wrote:
    Finally I've done some testing with interesting results.

    The system setting display scale has a huge impact on performance. My MBP 15' has a native resolution of 2880x1800. However, in scaled mode the OS renders at a different logical resolution (3840x2400 with the smallest font size, 2048x1280 with the largest), then scales the image to fill the screen.

    I've done a test flipping back and forth between three 24Mp images (I understand C1 caches in memory only the next image) at 3 different scales. Judge yourself from these cropped captures:



    At the highest resolution it takes about 5 seconds; at the native about one second, and at the lowest, well, it's so fast that the spinner doesn't show up most of the time.

    Please note that the "time to sharpness" and the "time to idle" are different, as C1 needs more time to prefetch the next image.

    Interestingly, changing the preview resolution has no effect whatsoever, I've tried changing it between 2560 and 640 (and recreating previews) without visible difference. Maybe I'm doing it wrong.

    TL;DR: sticking to the native screen scale brings the C1 performance to an acceptable level.

    I also wish that C1 would keep more than 2 images cached in memory, as i often go back and forth a small set of images (3-6) to quickly pick the good one and cull the rest. PhaseOne are you listening?

    Have good light,
    Matteo


    Matteo,

    Interesting observations.

    I think if the system is dealing with scaling as well after whatever is going on to load the preview (and possibly modify it) in the first place there are plenty of extra opportunities for reduced perceived performance. Not all are within Capture One's control. I might guess that the mechanisms might be different in some way for Mac and Windows versions but whether one or the other offers a benefit I don't know. Other may be able to offer an insight about that. As a Windows user it's quite possible I'm not likely to get involved with some of the things that Apple users consider to be normal user choices!

    My understanding of cache operation, based on something I read from a few versions ago, was that there is some attempt, made to predict and prepare what might be the next image likely to be accessed (based on any selection criteria as I recall) plus retaining the previous image viewed in memory (maybe more than one) if possible in case the user wishes to return to it. If "sets" are used there may be some benefits available as well.

    Either way it is probably worth pointing out that if you really want C1 to "listen" to your ideas the best approach is not through the forum - which is primarily a user to user facility - but by creating a Support Case, starting the title with "Enhancement Request" and then outlining what that request is. That way it will be directed to the correct responsible person and assessed according to, amongst other things, how many identical or very similar requests have been received along with technical practicality, etc.

    HTH.


    Grant
    0
  • mbp
    [quote="gusferlizi" wrote:
    What can extremely exacerbate loading times is having your preview size set to a resolution smaller than your largest screen. For your retina 15" it should have been 2880px at a minimum.

    You have to understand that capture one generates proxy 'raw' files, and not 'rendered' jpeg-like previews. If the horizontal resolution of the proxy is lesser than the screen's, C1 will seek and render the original raw file every time you select another image.


    I'm looking for further clarification on preview size for 15" touch bar MacBook Pro's, assume it's the same for all retina models, which have native pixel dimensions of 2880x1800, but according to Apple in the display settings this "looks like 1680x1050"... So which dimensions should we base Capture One preview size on here when using the laptop display?

    I've always used 1680px for retina MacBook Pros, but recently went with your advice and tried 2880px. I did not notice any difference in speed (both seemed fine for me on the i9), however the images in the viewer on a 1920x1080 display were blurry (possibly it's due to being an old DVI monitor, but this is something I have witnessed on other DisplayPort enabled monitors in landscape orientation too).

    It got me thinking more about preview size and wondering what the optimum setting is for portrait orientated images on landscape oriented displays, particularly when using multiple displays, such as pairing a 15" laptop with a 24"-30" 2k or 4k monitor, as I usually work with variations of this setup.

    Correct me if I'm wrong, but you suggest that when using multiple displays that preview size should not be set smaller than the width of the largest display? Is this based on the display's physical dimensions or pixel dimensions? Which is larger if an Eizo 24" is paired with a MacBook Pro 15" and both are set to their native resolution (1920x1200 & 2880x1800 [1680x1050])?


    Thinking about all this has led me to the realisation that the Capture One preview size setting completely favours landscape oriented images for rendering purposes. I noticed that when using the Quickproof output recipe, which creates it's pixel dimensions based on the preview size setting, that it was applying the chosen setting to the long edge of the image, regardless of orientation. And I believe this is exactly what it is doing with the images in the viewer as well; applying the user defined preview size, which is usually based on display width, to the height of a portrait oriented image. This is unnecessarily large and likely what is slowing down render time as well as making the viewer images blurry.

    So if I'm working with portrait oriented images on a landscape oriented 1920x1200 display, shouldn't I set the preview size to something closer to 1200px? This seems to be confirmed by Eric Nepean working on a 5120x2880 iMac 5K display, who has optimum results setting the preview size to 2880px (height of the display, not width).

    [quote="Eric Nepean" wrote:
    Update: With preview size at 2880, fast browsing and culling works much faster than with preview set to 5120.


    I could be way off with my thinking here, but possibly this all comes down to toggling the preview size setting based on image orientation. Leaving it alone is fine for Quickproofing, but it obviously has detrimental affects on preview rendering when not set correctly. An alternative idea is to rotate the monitor 90 degrees to suit the long edge when working with portrait oriented images.

    Either way it's incredible that this has not been definitively settled or at least made more clear. I think all Phase One has to do is mention alongside the setting itself that it is based on the long edge of the image and offer more common sizes to cover portrait (i.e.display height) based pixel dimensions such as, 1050, 1080, 1200, 1600, 1800, 2160.
    0
  • Permanently deleted user
    the best way to cull is outside of C1.
    FRV which cost funny 19$ is rendering RAWs instantly and u need for culling to press and remember 3 keybord buttons 😊
    Creating previews only cost time and disk space.

    If you want significant performance boost in C1, go to application, get info and switch to low resolution mode.
    0
  • Permanently deleted user
    FastRawViewer is **very** fast 😊

    I still miss the fast Preview option in Aperture. I don't understand why other app developers haven't been able to reproduce the feature so many years later.
    0

Post ist für Kommentare geschlossen.