CaptureOne Freezes or Crashes on Mac all the time.
I love working with Capture One but is crashing frequently. My version is Capture 20 Build 13 0 3 29
There is definitely memory leak.
It can not handle large catalogs. So, I decided to limit my catalogs per SD card.
It has poor performance on my iMac i5 8 GB RAM 1 TB Disk. Responsiveness sucks when drawing mask on layers over D850 NEF RAW images.
Healing Layer performance is not good or intuitive. Hopefully, new version to come will change this.
-
8 GB is barely enough memory to to run a Mac these days. As I type this I'm using about 6GB of memory with nothing more than the OS, a safari window, a mail window, and a couple of terminal windows open. With 8GB there's not much room left for anything else.
[opinion] You can get by with 16GB and have enough for todays use with 32GB. I expect I'm going to have to add memory to my machine (current at 32GB) sometime in the next couple of years. If my machine didn't have the ability to add memory I would have ordered it with more memory from the start.[/opinion]
0 -
No software should freeze or crash due to lack of memory. It may run slower but in fact there is not much reason to run slowly either. Really, biggest RAW file is 100 MB. I don't see any reason for hogging memory and CPU for simple tasks. If Lightroom and PhotoMechanic can importt photos with same memory size so should Capture One.
My laptop has i7 and 16 GB. That one also crashes and freezes. When I bought my iMac it was i5 and 8 Gb. LR amd PS are also heavy programs.0 -
No software should freeze or crash due to lack of memory. It may run slower but in fact there is not much reason to run slowly either.
In a perfect world I agree. However... Open a terminal window and issue the command "vm_stat". It will list about 20 lines of "Virtual Memory" statistics. The last two lines labeled Swapins and Swapouts are of particular interest. Time spent swapping is time not available for doing useful work.
When memory space is needed and none is available the OS will "swap out" the memory used by some other program, writing a copy of the contents to disk. That takes time. When it is time to run the program that was swapped out it needs to restore what was swapped out. That's a swap in. It takes time, too. Even worse, without enough memory something else may need to be swapped out before the now needed memory contents can be swapped in. The worst case result is when the system spends more time copying and restoring memory than doing useful work. This is called "thrashing". When thrashing gets bad enough the OS itself may not be able to run unless it kills programs taking up too much memory. Or the entire system may crash.
0 -
This is a perennial debate in SoftwareEngineering circles:
The "C" programmer says "Memory management is too important to be left to programs."
The Lisp programmer says: "Memory management is too important to be left to people."
The more salient question, I guess, is should those wishing to use this software ensure at least 16MB-32MB onboard ram before purchasing this software? If so, does the company disclose this in their recommendations?
0 -
I've been writing software since 1977 and according to what I know about UNIX O/S which MAC OS is based on is not supposed to crash for a reason like this except for faulty code with lots of memory memory leak. I think this is the case here because where it crashes is during catalog building while importing pictures from an external disk.
If the software using dynamic memory and allocates large memory space for doing something like generating previews and when fished doing this function and don't free memory on exit eventually it will exhaust all the memory in the system and cause the system to crash.Crazy memory sizes like 16 Gb and 32 Gb is for hiding these defects. There is no reasonable excuse for such bigotry memory requirements.
1 -
Interesting. I went to Graduate School for CS in 1979 ... and had been working in both academic and commercial settings until I retired a few yers ago ...
That being said, while I am quite sure that numerous leaks and dangling pointers abound in lots of off-the-shelf software (I have no crash logs showing access or segmentation faults, etc.), I wonder if this is meaningful to subscribers to this forum. Perhaps it should be of greater concern to the developers at Capture One? (Who are doubtless aware of these problems)
I retired early to make pictures. Happily, my workflow is hybridized. I am not overly invested in digital processing. I find that I use this software when needed (in situations where I am asked for a quick turnaround comprising of mostly color images for local publications, etc.). For most of my work (that I enjoy doing), I use Affinity and/or GIMP along with PhotoMechanic to handle the most of my images---which are film and not digital.
0 -
Crazy memory sizes like 16 Gb and 32 Gb is for hiding these defects. There is no reasonable excuse for such bigotry memory requirements.
Things have changed since 1977. My mostly idle system has almost 400 processes running and takes up almost 10 GB. Maybe there is no excuse, but it is the way things are.
That said, I thing tomr7 is correct that this is probably not relevant to the subscribers of this forum. I'll shut up, now.
0 -
Please don't take my comment as an attempt to stifle anyone's observations, comments, etc. I'm genuinely interested in what anyone has to say about this issue.
I just don't know that anyone at Capture One is listening.
0
投稿コメントは受け付けていません。
コメント
8件のコメント