Very slow navigation from one image to another
Hello. I'm wondering if anyone else is experiencing the issue that I'm about to describe.
Prior to posting here I've searched for similar posts and I only found one from 2019 on dpreview with no solution. Here's the link to that one: https://www.dpreview.com/forums/post/62778883
Summary:
This issue looks as if Capture One is only caching or storing the preview for the 2 most recently viewed images and nothing else.
Whenever I navigate in any folder of any catalog, each image is displayed pixelated for a few seconds before the real image is shown.
[Edit]: I've just tried this on my 1080p display and the images are displayed pixelated for way less time, less than 1/3 of the duration that it takes on the 4k display
Short overview of system:
I'm using Windows 10 on a SSD. Images and catalog are stored on HDD. I can edit 4k video from the HDD so it's not a bottleneck or anything.
As for hardware, the system has 24GB DDR4, the CPU is an i5-10600K@4.10GHz and the graphics card is a GeForce GTX 1060 6GB
The main display is 4k and I also have a secondary 1080p one.
I'm working with various image sizes, ranging from 12.3 to 24.3 megapixels NEF (Nikon Raw) files, sometimes also with 12MP GPR files (GoPro Raw images)
What I tried:
1. Using "Regenerate Previews".
2. Verified that the previews are actually generated in the Catalog_folder\Cache\Previews\...
3. Modifying the "Preview Size" to various settings, including the native 3840px of the display.
4. Enabling/Disabling OpenCL for Display. Currently I have it set to "Auto" for Display and "Never" for Processing.
Detailed description
What I'm doing:
I open any catalog with any number of images in it, from under 100 to over 2000.
I go to any folder in the catalog and start browsing through the images using either the arrow keys on the keyboard or the mouse.
The issue:
When clicking on the image, first I see a very pixelated version (as if the thumbnail is stretched to fit the view area). Let's call this image A.
Then, after about 2 seconds the actual image appears.
Now I navigate to the next image and the same thing happens. First I see a pixelated version and after 2 seconds the actual image is shown. Let's call this image B.
If I go back and forth between A and B, they are displayed instantly in their full size. However, as soon as I navigate to a third image, the pixelated version appears and I have to wait another 2 seconds. Let's call this third one image C
Now if I go back and forth between this image C and the one I was previously viewing, all is good, no pixels. However, as soon as I go to another image, there's the pixelated version again.
So considering the above, the short version would be:
A: pixels then OK.
B: pixels then OK.
A < > B: OK.
C: pixels then OK.
B < > C: OK.
A: pixels then OK
Any other image: pixels then OK
-
As a possible technical solution for this, it would be great if the users would have the ability to set a custom Maximum Cache Size or something like that, and then C1 would cache the images in RAM, up to the max cache size.
It would seem that at this time, Capture One 21 only stores the most recent 2 images in memory and that's it.
At this point it is faster to navigate through actual NEF raw files using the Windows Photos app than it is to navigate through C1's "generated previews" in the C1 software.
I mean why waste the time and resources to generate previews in the first place if using them is actually slower than rendering actual RAW files?
While searching for a solution on the issue that I described in the post, I ran into a lot of posts in which people are complaining about how slow it is to import images into C1 because of the "Generating Preview" process.
So I'm wondering why is C1 even bothering to generate these previews since it is faster to just decode and display the NEF files on the fly, as the Photos app is doing.
1 -
Hi Darius,
I firmly believe decoding a big raw file and applying the C1 adjustments is definitly not faster than loading a small jpg-like preview file, let alone the memory needed to do so.
Did you actually check the catalog on SSD vs. HDD? Don't compare one big video file and a video application with several hundreds of small files (preview, thumbnails etc) with a photo editing & catalog application. Apples with oranges.e
You need to have a big enough preview file size in the preferences AND have the previews regenerated (select the images + F5). C1 will only generate a new preview file if it doesn't find any, it does not compare the actual size of existing previews with the preferred size and auto generate.
0 -
Forget my last paragraph, I see you did check the previews are regenerated.
Here's my advice: If you have a very small preview size configured and generated then they won't be used on your 4k screen. Compare this performance of C1 with the biggest preview size performance. But do this test with the catalog on SSD. There should be a difference.
You can also set the viewer to 100% and then scroll through your images, previews won't be used but rather at least the visible part of the image will be decoded and adjustments applied to, which should give you an impression of how fast or slow the raw image development actually is. It should be slower than loading the biggest size previews.
[Edit]: I've just tried this on my 1080p display and the images are displayed pixelated for way less time, less than 1/3 of the duration that it takes on the 4k display
No question, a 5k preview file for a 4k monitor loads and shows slower than a 2k preview file for a lower resultion monitor.
0 -
@BeO Thanks for replying.
I'll try copying a catalog to a NVMe SSD and see what happens. I'll get back with an update.
The reason why I didn't try that yet is that once a preview exists, C1 should show the image instantly regardless of the storage media type. I mean the preview is a 3Mb file, it's nothing. A 3Mb jpg file loads instantly even from a slow SD card in most apps.
Although I didn't write this in the original post or in the previous comment, I've tried scrolling through images after setting the size to 100% from the top-right corner of the viewing area.
The same thing happens - a pixelated version is shown for around 2 seconds and then the actual size appears.
I firmly believe decoding a big raw file and applying the C1 adjustments is definitly not faster than loading a small jpg-like preview file, let alone the memory needed to do so.
I agree that it should work like this, however C1 behaves exactly the same with images that don't have any adjustments on them, same loading time.
Also the Photos app in Windows loads the NEF files much faster than C1 spends on the pixelated version. What's interesting is that the Photos app also displays a somewhat pixelated/blurry image but only for a fraction of a second on the 4k display.
This leads me to think that perhaps C1 is not using the previews in the way we think it is. There's also the fact that the two most recently viewed images are loaded instantly in C1.
This actually made me check the file creation time on previews while scrolling through images, I wanted to check if C1 is maybe always regenerating the previews. I found that the previews are not being regenerated while scrolling through the images in C1, so that part is ok.
However, another interesting thing happens - if I manually delete the previews from disk, they are immediately re-created - without me having to click on "Regenerate Previews" or touch C1 in any way.
Also one weird thing that I found is that if in C1 I rename the files and then either manually delete the previews on disk from outside C1 or use the "Regenerate Preview" function, the previews that are generated have the same names as before I renamed them. I did this multiple times and the same old name was used.
However, if I close C1 and then reopen it, new previews are generated with the new names and in different subfolders of the "Previews" folder.
Not sure if that has anything to do with the original issue though, it's just a weird behavior that I noticed.
0 -
@BeO I've copied a catalog to a NVMe SSD, the performance in C1 is exactly the same, there's absolutely no change.
After testing, I manually deleted all the previews from the SSD catalog and regenerated them, just to make sure C1 is not somehow using the previews from the original HDD catalog. All previews were generated in the new one, on the SSD.
By the way, with clean, non-edited, clean 12MP NEF images the blur takes about 2 seconds.
With basic edits (exposure, crop and a few more), 24MB NEF images, the blur takes a bit more and I can clearly see 2 steps:
1. blur (~2-3 seconds)
2. no noise reduction(~1 second)
3. final version
0 -
Darius,
The Preview file is set up to be a usable view of the data making up the image for display on a specific screen size. (With a little flexibility around that initial screen size before a full recalculation from the original file is required if the onscreen results are likely to be useful viewing at a different size.)
If the Preview is too large for a screen it will be recalculated to "fit".
If it is too small for "fit" it will be recalculated to make it larger.
If one loads to a screen at, for example, a resolution that is about 25% of the original file's maximum pixel dimension potential and then zooms in to 100% the chance are that the original data will be recalculated since 75% or it (or more) will likely be missing from the preview.
In addition to the base rendition, C1 then applies the specific edits that have been created for the variant to make Enhancements. Possibly also making things like Watermarks visible.
C1 also attempts to pre-prepare additional files in memory to make the transition from one image to another in an editing session as fast as possible whilst optimizing memory usage, etc.
NR applied to an image may require very little processing or a lot of processing. NR can really only be accurately calculated and viewed at 100% or original file size. So to make sense of NR adjustments a recalculation is almost always required.
SSDs are great things but mainly for transferring large files in continuous "streams". If one's initial load involves a lot of small files the data transfer speed will not be near the advertised performance numbers in the specifications. In addition, the specification of internal components moving data within the system (not just to and from the disk) can be very influential concerning the user's perceived performance.
I think if you really feel a need for faster performance you should start with a machine using a quite recent i7 or higher specification processor to see how that compares with your own i5 experiences.
I would also recommend a system built for Pro commercial use since the premium price is also likely to be reflected in the components used throughout the system, not just the headline items like processors and SSDs. That can make a significant difference to high-intensity use such as processing large numbers of images expecting rapid responses to one's processing inputs.
0 -
I've tried scrolling through images after setting the size to 100% from the top-right corner of the viewing area.
The same thing happens - a pixelated version is shown for around 2 seconds and then the actual size appears
If it takes the same time I believe that even in "zoomed out" mode, the preview files are not used but rather the raws are interpreted.
This leads me to think that perhaps C1 is not using the previews in the way we think it is.
That is very much likely (but not only for previews :-))
Maybe it is not the HDD or SSD but other parts of the CPU or chipset which is the bottleneck, but loading a small preview file as slow as rendering the visible part of a raw doesn't sound right. Maybe C1 has a dependency between loading the preview and pre-preparing the raw... who knows.
In general I have to agree with SFA, a lower spec computer in combination with both, C1 and a 4k display, is probably not very speedy.
0 -
Bring your raw files offline and test again. If they are offline C1 cannot calculate the viewer content based on the raws so the preview files must be used. You probably can draw conclusions then depending on the speed and quality of the image shown.
0 -
@BeO Thanks for the idea. I tried it just now by renaming on disk (using windows explorer) one of the folders that contain images while C1 is opened to that folder.
I made sure that the question mark appears in the lower right of the thumbnail and also that the "Offline" text appears at the top of the viewer window.
I am experiencing the same issue for the same amount of time. Testing with 12MP images.
Switching between the most recent 2 images is instantaneous just like before, but going to a different image leads to the same pixelated enlarged thumbnail being displayed for ~2 seconds before showing the actual image
Any other ideas? My use case is previewing small portions of timelapses, so I would greatly appreciate any potential solution.
In the meantime, I'll install C1 on a different system and see how it behaves over there.
@SFA
I think if you really feel a need for faster performance you should start with a machine using a quite recent i7
Come on now, let's be serious. It's about displaying photos, not 8K video. By the way, I am editing 4k video on this machine without any issue whatsoever. And it's an i5-10600K@4.10GHz
Are you really saying that this CPU cannot show a JPEG preview in less than 2-3 seconds?
I mean look, even the Windows Photos app has better performance. And this is comparing using fresh raw unedited NEF files, same directory, same files.
This is without even considering that C1 is supposed to display the "preview" files that a lot of people on this forum are waiting from 20 minutes to hours to be generated.
[Edit]
I've just installed IrfanView and all plugins for it. The same NEF Raw files for which the "preview" takes 2-3 seconds to load in CaptureOne - I can navigate through these instantly using IrfanView.
So no, it is Not a bottleneck in the chipset.
Maybe it is not the HDD or SSD but other parts of the CPU or chipset which is the bottleneck
Don't get me wrong, I appreciate the input as well as any ideas regarding what else can be done. However, this seems to be quite a common reaction on this forum: It's never C1's fault, C1 is always perfect, never at fault, there's always something else like a "bottleneck in the chipset" without any potential explanation or evidence.
[Edit] Even so, I've installed IrfanView (see the edit above) and its behavior demonstrates that the overall system is more than capable of displaying NEF Raw files instantly.
The reason why I'm posting here is because I want to help if possible to make C1 better. There is a legitimate issue here and just saying that the bottleneck is in the chipset is not helping anyone.
I think that this is related to the implementation. For some reason, the people at C1 decided to show an enlarged thumbnail in the viewer prior to showing the actual preview of the image. I don't understand why not just show the current image until the new one is loaded and ready for display.
I'd rather have a "slow navigation" than blocks of pixels on my screen. Of course the best would be to have instant navigation (you know, like IrfanView does with acual Raw files)
0 -
Darius,
Offline test
As you are having the same performance issues with the previews it is likely that the preview files are used even when the raws are online. I was hoping for the opposite, it would have narrowed the potential issue down.Comparisons with other apps
I mean look, even the Windows Photos app has better performance. And this is comparing using fresh raw unedited NEF files, same directory, same files.
Yes, but C1 is a catalog software and is doing more in the background than just showing one file. E.g. C1 is monitoring the folders (try renaming a file with Explorer and see what happens to the online status), it is caching browser thumbnails, and probably some more stuff which I would not even think of.
Note, this is trying to explain, not to excuse. (And believe me how much I wish that C1 would be less hungry for hardware. C1 is the only reason why my HW is as expensive as it is. But I have no choice if want to use C1 with acceptable speed)
Come on now, let's be serious. It's about displaying photos, not 8K video. By the way, I am editing 4k video on this machine without any issue whatsoever
You probably know that for video editing there are special "features" in the Intel based CPU architectures, so any comparison with video performance is not meaningful imo.
Bottleneck:
I think this is a misperception. A bottleneck is always to be seen in the context of the process in question.Here, the process and components in question is to display a preview with the current version of C1.
We all know in some respect C1 is faster than LR for example, in other respects it is not, and in displaying previews in the viewer it is slower than IrfanView or Photos to show images, and you can edit 4k videos with another app on the same machine. Yes. Ok. But what does this tell you? Nothing relevant if you want to display images in the C1 catalog. If you want to improve the performance of C1 you need to find out what the bottleneck for C1 is. And you can submit requests to C1.
This is fact, no excuse. You can be upset but you cannot change things which you cannot change.
Claims that C1 is perfect
In the end, it does not help you at all if we rail against C1, it might possibly help you though if you understand C1's behavior better, accept its weaknesses and find a way to work around or improve. And sometimes this might be a better suited hardware, sometime even a better suited software.All this is not meant to excuse or protect C1, it is meant to help you gain a better expierence with C1. And it is just not true (for SFA or me) that we claim it is never C1's fault, C1 is always perfect etc. Read my other posts and feature requests and discover that I am not always satisfied either, but want the software to improve.
I assume you know the recommended section and the note about 4k monitors:
I would assume this is mainly for editing raws, not loading and rendering pre-generated previews even if they have 4 times the size. Anyhow, it is a know thing that C1 and 4k/5k is slow.
The question is, do you still think about a bug in the software or an issue with your system (e.g. driver, HW accelaration, or anything else) and want to dig deeper? Then maybe the log files of C1 (application.log, imgcore.log etc) might have additional information and unexpected messages which could potentially give you a hint. Or, is is more likely that the HW is just not sufficient for this hungry blo ody slow old C1 (see, I did you a favor... :-)
C:\Users\yourname\AppData\Local\CaptureOne\Logs
If I have another idea I will let you know.
Cheers,
BeO0 -
I think Irfan view will simply display the embedded jpg file from the RAW.
But my point was mainly that, unless I also have a lot of other applications running OR I'm loading from a NAS over a wireless connection, neither my 2012 era i7 running Win 7 nor my 2020 era i7 running Win 10 are anything like as slow as you mention for your system.
Now there are some other considerations in the background here and one of those may be that 1 is designed with the expectation that some editing is likely to take place and other applications are not - they start up as just viewers. Irfanview is an example. As is Faststone.
If I just want to view at speed they are programs I might choose to use. Things slow down for editing if using Freestone - for example.
It's a different approach and I don't think it makes sense to compare the two directly when taking all objectives into account.
But either way, the numbers you mention for your system seem slower than I would expect from mine doing something similar under normal use circumstances.
The key, as you alluded to in your first post, may be the 4k screen and its corresponding setup requirements for optimised performance in C1.
I see the BeO has already covered some of this in greater detail than I have as I have been preparing this response.
I think the key point may be that in C1 the preview file act as an interpretation base - usually for RAW files but it carries through as a method for other file types as well. Beyond the core interpretation all the other edits one applies are overlaid on the Preview during display and editing activity.
That is slightly different to the methods of an application that may start by displaying an embedded jpg for a RAW file and concern itself with changes based on that, initially, for speed of onscreen presentation. But that is probably a discussion for a different headline subject.
0 -
@BeO and @SFA thanks for the detailed answers.
Yes definitely I'm not into bashing C1 either. I paid for it and I will probably pay for the next version as well. Mostly due to a lack of better alternatives.
and you can edit 4k videos with another app on the same machine. Yes. Ok. But what does this tell you? Nothing relevant if you want to display images in the C1 catalog.
True, I'm mostly frustrated by the fact that such a good software fails at such a simple task. There's great potential and I suspect a lot of people would use C1 if one of the selling points would be performance.
I assume you know the recommended section and the note about 4k monitors:
I didn't know about that specific post but I was aware in broad terms on the requirements.
As a note. In my original post I mentioned 24Gb DDR4. The system actually has 32Gb DDR4@3200MHz. It was late at night and I was thinking of another system.
The SSD that I'm using for the tests in this thread is a WD Blue SN550 PCI Express 3.0 x4, M.2.
The motherboard is an Asus Prime Z490M-Plus
The i5-10600K should be more than enough.
The question is, do you still think about a bug in the software or an issue with your system (e.g. driver, HW accelaration, or anything else) and want to dig deeper?
Dig deeper since the issue is still present. I'll install C1 on another system, a laptop running on i7-7700HQ with 16GB RAM and a GeForce GTX 1050 4Gb. It is lower in specs than my main system, but I'm curious how it would perform there.
I am inclined to think that this is either a bug or simply a lack of optimization in the implementation.
Logs: I'm looking through the logs now, thanks for providing the location on disk.
This is one of the recent lines - there are hundreds of such lines, more or less identical at the end of Application.log:
[2021-09-08 00:58:00.472][596][ID:018, ]{PFORM} | Memory Statistics: Virtual: 62111MB Private: 4280MB Managed: 172MB TargetId count: 3 CalibrationCache: 0MB/0 RGBCache: 0MB/0 ColorProfileCache: 0MB/4 ThumbnailCache: 4MB/3 ProcessedThumbnailCache: 0MB/0 PreviewCache: 139MB/8 RAWCache: 214MB/9 LCCCache: 0MB/1 FocusMaskCache: 0MB/0 TileCacheOpenCL: 260MB/6 MaskPrepareCache: 0MB/0 PyramidCache: 0MB/0
@SFA
I think Irfan view will simply display the embedded jpg file from the RAW.
Good point. I didn't suspect this because at first IrfanView did not show any image in that folder and requested the installation of a plugin for displaying Raw files, so I thought that if it displays the embedded jpegs it wouldn't need a plugin.
However I think that line of thinking was not correct because the plugin might actually do exactly that, point irfanview to where the jpeg is located in the raw file. I'll see if I can remove the embedded jpegs from all raw files and do another test
the expectation that some editing is likely to take place
Yes, this could be the case.
It's a different approach and I don't think it makes sense to compare the two directly when taking all objectives into account.
Right, I only used IrfanView to see if maybe there's some hardware issue or some other thing that prevents the system from displaying Raw or jpg files properly.
The key, as you alluded to in your first post, may be the 4k screen and its corresponding setup requirements for optimised performance in C1.
It is true that if I move C1 on the 1080p screen, the pixelated version is shown for less time, under a second.
I think the key point may be that in C1 the preview file act as an interpretation base - usually for RAW files but it carries through as a method for other file types as well. Beyond the core interpretation all the other edits one applies are overlaid on the Preview during display and editing activity.
Yes, it could be the case that the preview is passed through a number of functions that would apply various edits and just passing the file along results in this delay even if no edits are actually there to be applied.
I'm going to add 32 Gb of Ram this week for a total of 64Gb and see if that improves things.
As for the graphics card I'm not really keen on the prospect of having to upgrade it. It does everything I need except for this.
However I need the Ram. Mostly for Google Chrome lol.
As a side note, one may wonder why am I bothered by having to look for 2-3 seconds at enlarged pixels.
Well what I'm doing this week is go though a set of ~1000 raw images taken as a timelapse of the night sky during a meteor shower, and out of those 1000 I'd like to keep only the ones that have meteors in them and not only satellite streaks.
For me to be able to do this I frequently need to go back and forth over 4-5 images to see if a streak is a meteor or it is a satellite. Basically if the streak is moving along over the span of 3 images, it is a satellite.
However if I always have a mess of blurred pixels in between the images it is difficult to do this.
The next batch will contain about 2000 images, then 3000 and more. Anyway, I'll probably do this in IrfanView now that I installed it again after 20 years of not using it :)
0 -
Update on IrfanView:
- Indeed IrfanView is showing the embedded jpeg by default, as @SFA pointed.
- There are 3 levels for this setting: embedded Jpg, half-size raw and full-size raw
- Embedded jpeg is instantaneous, half-size raw is almost instantaneous, something like 1/2 second delay. Full-size raw takes between 1-2 seconds to display, but there's no blur inbetween. It only feels like a slow navigation.
0 -
As a side note, one may wonder why am I bothered by having to look for 2-3 seconds at enlarged pixels.
Not at all. I certainly would be bothered too.
I'm going to add 32 Gb of Ram this week for a total of 64Gb and see if that improves things.
I doubt it will. C1 needs Ram no question, but 32GB is plenty, especially for "only" showing the preview files.
I'll install C1 on another system, a laptop running on i7-7700HQ with 16GB RAM and a GeForce GTX 1050 4Gb. It is lower in specs than my main system, but I'm curious how it would perform there.
Me too.
0 -
@Darius
"- Embedded jpeg is instantaneous, half-size raw is almost instantaneous, something like 1/2 second delay. Full-size raw takes between 1-2 seconds to display, but there's no blur inbetween. It only feels like a slow navigation."
This would be the equivalent of changing Preview sizes I would guess.
Some years ago, long before small computers had anything like the power and storage potential that they have now and therefore most processes were slow by current standards, I ran a processing speed comparison between the Photo Editing application I preferred at the time (very similar to Capture One in many ways and without any DAM capabilities - so the processes were only managing the edits not the DAM requirements in parallel - and one of the Lightroom V1 versions. This was probably quite early in the life of Lightroom.
I set up an "Edit" that could be considered a typical sort of development and was available in both applications and then timed how long it took to process one image from hitting the "go" button to the point that the adjustment was considered "complete" and further editing could be undertaken on that or any other image.
My favoured application always seemed slow on screen, taking about 3 seconds to complete the process with, basically, nothing on screen changing until the very end of the process steps. That made it LOOK very slow. Like C1 it used its own thumbnails and a form of preview jpg which, as I recall at the time I did the test, had just been combined with the edit instruction file in the form of a jpg. Users could choose how what dimension they wanted to support for the jpg. Screens were, typically, lower resolution that the are today.
Nothing appeared to be happening until all was complete. We humans don't like that sort of presentation when we are trying to assess for speed.
LightRoom also took about 3 seconds to fully complete the process and hand back control of the screen. I think it used the image's own embedded jpeg when dealing with RAW files. However since LR was always based on a Catalogue concpet with imported files it may have been using an internally stored preview file.
The main difference was that LR LOOKED like it was much faster by presenting instant screen changes in the area being viewed. So the major effect of a a set of adjustments appeared to be presented almost instantly. However, if one observed carefully, espacially when viewing the process run at 100% scale, one could see the finer adjustments being applied and refined after the initial rush of the great change. At "fit" size it was usually difficult to see them, but at 100% for part of the screen it was a little easier to see how the process was being managed as seemingly random data blocks were adjusted and that screen area rewritten
That is why the overall start to end process time was, in so far as I could measure and on average, about 3 seconds, start to end, for both applications even though one appeared to be much faster than the other.
So those results in my experiment seem to be similar to the Irfanview observations made above.
Full size RAW in the case of my pre-C1 preferred application and embedded jpg transitioning to Full Size RAW in the case of LR V1.x I was using at the time.
As computer ower increased so did image file sizes, especially RAW files. So the results today would probably be quite similar now to what they were back then if working with larger files and therefore more data.
For single image edits they are probably "fast enough" for themajority of users in most use cases on a single file basis.
Where things can improve more obviously would be in batch processing with a large number of images in the batch. But that is not what the discussion headline is about, no matter how interesting comparisons might be.
0 -
@BeO
Right, I checked ram usage multiple times with various catalog sizes and during multiple types of operations, i barely get to 20Gb usage for the entire system.
@SFA
Yes, I agree that it is mostly about the "appearance" of speed rather than actual speed.
I guess I'd prefer to wait on the current image while the next one is loading rather than how it works in C1 at this time, meaning looking at pixels while the image is loading. I can say that C1 is definitely faster than for example darkTable which I just checked.However darkTable is even worse, as it removes the current image from the viewport, leaving me staring at a gray screen while the next image is loading. Didn't time the operation though, but it does feel slower looking at a gray screen.
So anyway, I've installed C1 on another system.
i7-7700HQ, 16Gb DDR4, GT1050 4Gb, SSD only (a laptop)
On the laptop screen it's blazing fast. It's an Asus UX550V so it has a high-dpi screen but this doesn't affect C1 in any way. The performance is just like on my desktop on 1080.
Same thing on the 4k display running in 1080p mode.
However, as soon as I go to native 4k, the issue can be reproduced.
Side note: Have you seen current prices for RAM? I see it's almost 50% more expensive than in January - and this is "on sale". I'll stick to my 32Gb for now I think.
0 -
"Side note: Have you seen current prices for RAM? I see it's almost 50% more expensive than in January - and this is "on sale". I'll stick to my 32Gb for now I think."
Yes - if one can get the spec. one needs.
I bought a new system in December planning to upgrade RAM and add an extra SSD once I was sure it was the way to go.
However the spec., with 16GB, seems to work for me compared to the previous 24GB on the older machine.
And so far I have held off adding a second SSD since right now I don't need one so I'll wait to see how things develop.
I think the thing about 4k native is that it significantly increases the number of pixels in the display and therefore tests all aspects of the system.
If one uses the screen as desktop real estate with only certain parts of the total area being changes at any point in time the additional pressure for screen handling is not so great. Make it likely that most of the screen's will be changing with every adjustment and the game changes.
I recall a presentation from a technical team working at Fujitsu way back in the last century when they were just starting to develop screen sharing type technology for early forms of video conferencing. It was not long after Microsoft had adopted an overall Grey colour theme for Windows based softwareand I distinctly recall them explaining how bad that was for efficient video presentations because the grey colour used all colour channels and offered very poor performance across available networks when the key to speed and efficiency was to map and transmit only changes pixels, preferably in small data blocks describing compressed areas of single colours. Grey simply did not allow for large block of common colours and therefore required more data packets to present every change.
The use of a 4k rendition screen, compared to a 1080 rendition, does not permit the benefits available from typical compression algorithms nor the segmentation and partial display of an image zoomed to 100% or more on a 1080 screen.
Capture One release notes comment specifically about the challenges of specifying a system if a 4 or 5k screen (or screens) are being considered.
A large dimension 4k screen to access more real estate in 1080 mode (or similar) has some appeal to me. I'm not sure I could successfully use a full 4K screen for full size photo editing without moving away from it for a viewing distance equivalent to 1080 at a regular laptop or desktop viewing distance. Or something close to that.
In which case, to me at least, the idea of a 4k screen starts to become rather a waste of time and money.
Other use cases or other users may see things very differently.
0 -
4K
Whenever I read something in the forum about C1 on a 4k monitor it was always that with hardware xyz the performance is poor (though I have certainly not read every post here). What would actually interest me more is the hardware which actually can cope with 4k in a speedy manner. Does this exist?Then one could decide prior to spending the money - for the monitor as well as for new hardware which one only can assume would be capable - to either buy the machine or to postpone the new purchase.
0 -
Well the clarity and details on a 4K screen are night and day from 1080p.
My secondary monitor is a 1080 Dell S2715H. I remember being very impressed by it back when I got it as my primary monitor. After getting the 4k and comparing the two... it's night and day.
@SFA why move away from it? Both the 4k and 1080 are 27 inch screens, the viewing distance is the same for both.
The way I see it it's just like having an extremely high dpi screen. With windows scaling things 150% just like on a high dpi 1080, items on screen are almost the same size. For example taskbar, icons, buttons, text etc. It's just that you get more continuity and clarity due to the fact that the individual pixel units are way smaller.
It's almost like having the desktop printed on a sheet of paper and illuminated from behind. No visible pixels whatsoever unless one's eyeball touches the screen.
Actually reading the most recent comments from both of you made me experiment with different window sizes. So basically instead of using C1 maximized, just resize the window randomly and see how it works.
The result is that if C1 occupies around 70% of the screen, the pixels stay on the screen for a lot less time, almost nothing at all. only after ~70% the effect becomes more apparent.
Not sure how this information helps but at least this is a reliable way to reproduce it.
Anyway, in the meantime I have two workarounds:
1. Use the 1080p display for any work that requires quick navigation through timelapses (or any large batch of images for that matter)
2. Select 4 images at once, look at them, then select the next 4 and so on. This appears to be working better for my specific use case since I actually do need to compare 2-3 images to one another quickly.
I do hope that C1 will get better at this. All that would be needed is to do for multiple images whatever it's doing for the most recent two images that were viewed.
Switching between the most recent 2 is absolutely instantaneous, so if this functionality could be expanded to at least the 2 or 4 images that surround the current image, that would be awesome.
This can even be a user-accessible setting: "Number of images to preload in memory" or "Memory reserved for preloading images"
Actually while writing this and messing around in C1 I found an interesting behavior. I now think that C1 is already doing something like I requested above. Here's what's going on:
If I use the arrow keys and slowly go through them at a rate of around 1 per second, there are no pixels. I only now noticed this. So the pixels appear only if I try to go through the images faster than this.
This in a folder that contains over 900 Raw images, each having 2 variants. Variant 1 is exposure, color correction, noise reduction and Variant 2 is Variant 1 + crop.
However, clicking with the mouse randomly does indeed yield the pixelated result, no matter how slow I go.
In other words, it appears that C1 is already started to do something smart regarding preloading of "next probable image".
0 -
In other words, it appears that C1 is already started to do something smart regarding preloading of "next probable image".
That is something I remember having read sometime in the past somewhere, but i don't remember the details nor where it is written.
One thing is prefetching preview files. Another thing is prefetching previews and applying certain develop settings to it, another thing is prefetching raw files maybe pre-demosaicing and precalculating raw files based on the develop settings.
I do hope that C1 will get better at this. All that would be needed is to do for multiple images whatever it's doing for the most recent two images that were viewed.
Maybe you want to submit a request to C1 with a summary of your findings.
The workaround 1 is something I wanted to propose too, but as this is not a solution for your 4k problem I did not do this yet.
____
Discussing this topic with you I have another theory.
This theory is based on my observation that not all settings are applied to the raw file at all zoom levels. Take for example noise reduction. At lower than 67% zoom NR is not applied (apart from maybe some default NR during demosaicing). The exact zoom level at which the NR tool settings are applied is maybe not written in stone and may vary on certain factors, so it might be different for you.
You can test this by looking at a noisy image, ideally a black frame meant to identify hot sensor pixels which has hot pixels and a lot of magenta noise (increase the exposure), set NR sliders to a higher value, zoom in and out and observe. Do this on your low res monitor because of the rather classic zoom levels.
It somehow makes sense to not apply settings which, under normal circumstances, cannot be seen on screen, as is the case for normal ISO images with not a lot of noise at low zoom levels. It is said by many that C1 is not as good with high ISO images as other raw developers, and my explanation for this is that possibly this is a heritage from what I believe C1 was made for, i.e. the genres P1/C1 was used for usually don't shoot with high ISO, in fashion and portrait you have good lighting, in landscape you have tripods, in cultural heritage/reproduction you have both.
(EDIT) removed an unfinished sentence. (end of EDIT)
So here's the theory:
On the 4k screen, if the image is shown to its full dimensions, it is shown at 100% or around 67% (,right?), so NR would be applied. NR calculation takes time, especially if done for the full image.
## But C1 does not bake the NR into the preview file ##
It was historically not needed, it has been forgotten to change for the 4k monitor era, or C1 has deliberately chosen not to do so for performance reasons when generating the preview files.
(Historically, NR in the preview file was not needed, because when no 4k screens existed, for lower res screens the zoom level for a full image view is maybe 33% due to lower screen pixel density, and noise would normally not be visible on low ISO images.)
## What now happens on the 4k screen (and given a big size of C1 viewer) is that the preview file is loaded and because the image is shown full size but with about 100% zoom (or a little lower) the NR is actually applied to the preview file (or even the raw file) and this takes some time and leads to an initial blurry image until the calculation is finished. ##
(## is the theory)
--
Edited again for a few grammar glitches
0 -
So the questions are
- Do the generated preview files contain all adjustments, including but not limited to NR?
- When a preview file is shown at a high zoom level, as is the case on a 4K monitor even in full image view, will there be additional adjustments calculated?
- If so, can the preview generation process be amended to include all adjustments
- And can the preview rendering amended so that no. 2 is not happening anymore
SFA, no. 3 would be an additional argument (due to slower preview generation) for a configurable auto-preview generation discussed another thread :-)
0 -
Dear Marius, welcome to the desert of the real.
I have moaned about this extensively for years. It is an architectural idiosyncrasy of Capture One (some say the Mac version does not suffer from it, but I am not sure).
One thing to understand is that the preview file is not a 3MB JPEG. It is a RAW proxy that still needs to be rendered.
I've been told, if memory serves me well, that an AVX/AVX2 capable CPU mitigates this behavior. Nevertheless, for me it runs about the same on a 2008 AMD Athlon (100GFLOP no AVX) with 8GB RAM as on a 2014 Ivy Bridge 20 core / 40 thread workstation (1TERAFLOP with AVX) with 64GB of RAM.2 -
@Darius
I can confirm all your observations (running C1 on Windows in full screen mode).Your hardware is more than powerful enough.
Like Gustavo, I understand C1 does not store ready-to-display images, but still has to process some pre-processed data.
BTW, the lack of NR for previews below a certain zoom level threshold is not present because "it wasn't needed in the past", it is a performance optimization which in some cases can lead to a drastically different rendering of an image, depending on whether one looks at it at "Fit" or 100% zoom level.
It's just a compromise to trade off accuracy against speed which mostly works acceptably.
FWIW, I set my preview size deliberately too low to force C1 to render an image from the original data. Otherwise C1 scales the preview which leads to a slightly blurry rendering. Many have reported and complained about this effect. Most do not seem to be bothered but the issue is a very real one and again a result of trading accuracy against performance.
0 -
Has anyone find a solve for this issue?
I am using C1 on a Mac mini with a M1 ship and a 5K display and I am having the exact same issues described in the original post.
2 -
Can we have this problem addressed?
0 -
Etienne Cosnefroy Artur Zielazny
Well here are some updates:On an 27inch 4k display:
C1 still displays pixels but they're a bit better. Looks more like a blurred image than a blocky one.
C1 still shows clearly only the 2 most recently viewed images, everything else is a bit blurred.
However, the amount of time until the image is clear has greatly decreased for me, instead of the original >2 seconds, I now get the blur for only half a second to a second.
An improvement would be for C1 to take what it does with the 2 most recently viewed images and apply it to the entire current folder or album, or apply it to the most recently N viewed images, up to a memory limit that can be set by the user.
For me, the 2 most important use cases that are affected by this are:
- Trying to see which shot is the best out of a series of 4-5 or more similar photos.
- Timelapses.
In the meantime I've upgraded my cameras and my system, so the new situation is as follows:
Images: Raw, .ARW Sony images, 7008 x 4672 pixels.
System: Asus UX582HS Laptop
CPU: Intel i9-11900H @ 2.5GHz
Memory: 32 GB
Graphics: Intel UHD and NVidia GeForce RTX 3080
Storage: Nvme Samsung 980 Pro 2TB
0 -
I am a Mac user and I recently upgraded my laptop to a MacBook Pro with a M2 Max chip and 32GB of integrated memory. I am using my computer with a 5K display. I don't use external storage, all my pics are on the local SSD.
Throwing more power at C1 does help a little but I am still experiencing some lag when moving across my pics. I still appalled at how poorly C1 manages this.
0 -
Same here.
Macbook 2016, iMac 2017, Mac Studio M2 (last osx verions) - Catalog ~ 30 gb; 2-3 seconds per photo.
0 -
This is the only reason I am seriously contemplating alternative software now. It was like that always wi CO. Saying this is because of the hardware is untrue. Alternatives worked seamlessly years back.
Also, going through my RAWs with FastRawViewer is a breeze, while Capture One struggles, no matter what I have set for the preview size.
I really wish CO addressed this problem.
0 -
These are issues that would be so simple to fix. They already do it well with the most recent 2 images. I'd take a job at C1 just to fix this crappy functionality and then quit. It's so frustrating.
Warning, there's a rant below, mostly due to yet another mind bending bug for which I'll create another post (adjustments lost when zooming, yeah...).
Really, C1 is by no means suitable for professional work. I've been lying to myself that it's worth the hassle because the alternative is the crappy subscription model at LR, but I keep getting more and more work and don't have time anymore to waste on C1's issues.
I'm considering going back to LR. I mean yes, I really despise their subscription model but there is really no alternative. And they lowered the price, plus there's a perpetual mode in which LR still works after subscription ends, but with limited features.
C1 was the most promising software out there but they are doing a really bad job lately.
I've been experiencing so many issues, I've reported bugs but for nothing. I gave them really good steps to reproduce the issues but nothing, they keep jerking me around asking for more and more logs.
I really don't have time to waste on being a QA engineer for C1. Come on now. I've been sending reports from the software itself but nobody ever got back to me, nor were the issues ever fixed - for issues that cause hanging, the "send report" window comes up when you restart C1 so one can directly send a report from that window.
I can't even count how many issues I've had with C1 in a professional setting. Even the insane stuff that happened with the previous version when I couldn't work on my images because they were taken with a new Sony - the A7IV - and C1 didn't even see those images.
Anyway the workaround there was to just change the metadata of the files and everything worked fine.
Before you ask, yes I did buy C1 23 later so no need to change the metadata anymore and I did pay for the ability to work on A7IV images.
But come on, out in the field with no internet and C1 throws this shit at me? Show me a warning that "hey we don't guarantee results because this is an unsupported camera" or whatever, but don't just stop working with no message or explanation.
And don't even get me started about the batshit crazy "a version for each camera model" stuff. This seems to be the pinnacle of artificial limits in software. It's the *exact same software*, but with metadata-driven artificial limits. Why? What's the goal? Losing customers? Because if so, C1 has indeed met its goal.
So yes, no subscription model at C1 but still very poor judgement when choosing these business practices. Artificial limits like those are even worse than a subscription model.
It's not even about the money, it's about the punch in the face that C1 throws at us with this crap - artificial limits, no ability to create my own lens profile or use a profile built by the *manufacturer* (see irix blackstone for example), bugs that are never addressed and so on.
Yes, C1 is great when it works and I really like it, the UI is easy to use and you have more tools than you'll ever need, but... I don't know, at this point I'm tired of taking crap from C1.
1
Please sign in to leave a comment.
Comments
53 comments