V6.3.4 -- Memory leak still around?
I just downloaded & installed v6.3.4.
So far, I really don't see any improvement for Win 7 users. On a group of 128 photos (not really large) it took CO over 7 min to create all the proxies, while the Image Core Process grew to >4.7G and stayed there. When I selected about a dozen photos to "auto process", CO usage grew to >1G. Even as it sat there, the CPU was running at about 14% even though I was doing nothing.
It seems like the memory leak still exists, and the use of processing is not optimized.
While I restarted the program after the proxie creation, I have had no crashes.
So far, I really don't see any improvement for Win 7 users. On a group of 128 photos (not really large) it took CO over 7 min to create all the proxies, while the Image Core Process grew to >4.7G and stayed there. When I selected about a dozen photos to "auto process", CO usage grew to >1G. Even as it sat there, the CPU was running at about 14% even though I was doing nothing.
It seems like the memory leak still exists, and the use of processing is not optimized.
While I restarted the program after the proxie creation, I have had no crashes.
0
-
With that sort of performance issues I think you need to do a complete uninstall and then re-install. It worked for me, but was quite a painful experience ☹️
http://forum.phaseone.com/En/viewtopic. ... =30#p54392
Full uninstall instruction here (although I had to read between the lines a bit to find all the directories to delete). Be careful not to delete any saved styles or presets.
http://www.phaseone.com/en/search/artic ... nguageid=1
Spike0 -
[quote="Neil421" wrote:
With that sort of performance issues I think you need to do a complete uninstall and then re-install. It worked for me, but was quite a painful experience ☹️
I was hoping to avoid that; though it might be the best solution.0 -
I am also adding my name to the list along with a blog entry I created with a screen shot of ImgCoreProcess.exe exceeding 5 GBs.
http://blog.ronaldnztan.com/phaseoneww- ... act-sheet/
I want to comment that if you look at the screen shot, that same amount of RAM does NOT, I repeat, NOT released or flushed post-Web Contact Sheet! 5GBs is a lot to be in stasis and idle. To remedy, I had to exit and restart C1PRO. I don't this this is "workflow"-oriented if I want to resume editing my files in the RAW state.
I honestly thought 6.3.4 augmented the fix, but it turned out otherwise.
Jim: the best solution I could ask is for you to re-submit to Tech Support and reference this post. I think if enough of us supply logs, it would give a better roadmap for the develop to track down and obliterate the bug/error that is impeding on workflow.0 -
Hiya Neil,
I followed the steps outlined in the KB article and the lag/performance issue still persist after the "clean" install. It is starting to bother me because I use the internal Web Contact Sheet a lot to create proofs for my subjects and clients.
Request for you, Neil: you said that your performance quagmire was fixed and augmented when you performed the "clean" re-install. Will you try the following steps as outlined below.
1) Clear the Cache folder inside of the "CaptureOne" folder, while NOT touching the Settings50 folder.
2) Load your session so that the images for the proofs are around 200-300 frames.
3) Make the contact sheet within C1PRO.
4) Pull up your Task Manager so you could monitor the memory habitation of ImgCoreProcess.exe.
5) Take note of the GBs ImgCoreProcess.exe takes up during and after the web contact sheet.
Follow-up Questions for you: What GB amount does ImgCoreProcess.exe takes up during the web contact sheet generation? Does the memory occupancy remain the same AFTER the contact sheet has been created and exported into the designated directory?
I contacted P1 Tech Support, referencing and linking to this post. I am hoping with our compliance and help, the P1 Team will obliterate the inconvenience lag/performance issue impeding workflow.[quote="Neil421" wrote:
With that sort of performance issues I think you need to do a complete uninstall and then re-install. It worked for me, but was quite a painful experience ☹️
http://forum.phaseone.com/En/viewtopic. ... =30#p54392
Full uninstall instruction here (although I had to read between the lines a bit to find all the directories to delete). Be careful not to delete any saved styles or presets.
http://www.phaseone.com/en/search/artic ... nguageid=1
Spike0 -
[quote="ronaldnztan" wrote:
....
I honestly thought 6.3.4 augmented the fix, but it turned out otherwise.
Jim: the best solution I could ask is for you to re-submit to Tech Support and reference this post. ....
I agree, and I did.0 -
I have the same problem!
Not even enough for a 16Gb
And windows closes one of the processes of Capture One!
Please urgently fix the error! The memory leak!0 -
Contact PhaseONE Tech Support. Reference this thread (link to this thread).
It seems now there are three of us that are experiencing this inconvenience.
As a temp fix. I was recommended to keep the image preview under Preference to 1000 px. Keeping at this value make my 6.3.4 PRO x64 run "normal."
I agree! The "leak" should NOT occur. I want to keep my previews large at 1600 px.[quote="NNN634656390074110174" wrote:
I have the same problem!
Not even enough for a 16Gb
And windows closes one of the processes of Capture One!
Please urgently fix the error! The memory leak!0 -
[quote="ronaldnztan" wrote:
.....
As a temp fix. I was recommended to keep the image preview under Preference to 1000 px. Keeping at this value make my 6.3.4 PRO x64 run "normal."
Thanks, I'll try this.
I just reset from 1600 to 1000.0 -
In addition I have another problem
I just do not see a difference when I change the "preview size" in the settings.
For any value of the parameter "cashe size" quality preview is very low.
Before any change for the test I shut Capture One and delete the folder manually with the cache.0 -
I am copying and pasting my results I replied to PhaseONE Tech Support.
*** METHOD ***
1) I went into the preferences and decreased the preview image size from 1600 to 1000 (default). Exited C1PRO.
2) I went into the CaptureONE folder and deleted the Proxies folder within the Cache folder.
3) I ran the associated col50 session file and the session was loaded.
4) I waited for the completion of rendering the proxies of 145 physical Canon 7D CR2 files.
5) I executed the Web Contact Sheet (WCS) within C1PRO.
*** RESULTS ***
-Decreasing the preview image size to 1000 px seemed to "fix" the performance lag. The WCS rendered relatively "fast," e.g. normal as expected.
-Monitoring ImgCoreProcess.exe during WCS and after, via Windows Task Manager indicated the RAM occupancy remained within (below) 1.X GB barrier.
*** RESULTS 2 ***
The aforementioned METHOD was repeated and the following augmented: increased image preview size from 1000 px to 1600 px. Exited C1PRO. Expunged the Proxies folder. Loaded the col50 file associated with the session.
Monitoring of the ImgCoreProcess.exe showed memory usage increased to 5.4X GBs (initial < 1GB) during and remained at/around 5.4X GB post-WCS.[quote="NNN634656390074110174" wrote:
In addition I have another problem
I just do not see a difference when I change the "preview size" in the settings.
For any value of the parameter "cashe size" quality preview is very low.
Before any change for the test I shut Capture One and delete the folder manually with the cache.0 -
I am now directly replying to your post. In my experience as evidenced from the previous post, leaving the image preview size at 1000 px "seemed" to "fix" the problem for me. I put those words in quotes to emphasis unpredictability and still an inconvenience. Having larger image previews speeds up image rendering on my system: Core i5 750 2.67 GHz @ 16 GB DDR3 SDRAM with nVIDIA GT 430 openCL enabled.
Will you try the method I provided to see if the lag/slowness solve your problem?[quote="NNN634656390074110174" wrote:
In addition I have another problem
I just do not see a difference when I change the "preview size" in the settings.
For any value of the parameter "cashe size" quality preview is very low.
Before any change for the test I shut Capture One and delete the folder manually with the cache.0 -
I confirm that the memory leak is not visible when you install "cache size" in 1000 px and is present at the large values of for example 1600 px.
But I also repeat. I see no difference in the quality of the preview. For example, between 1000px and 2600px.
Why is it so? When I enlarge my Browser Panel quality preview of a very low!
I specifically checked, the size of the file *.cos increases, when I increase the "cache size"
But this does not affect the quality of the preview!0 -
I'll have to objectively take a second look to see if there is any **significant** speed improvements of image rendering on-screen when cache image preview size is 1600 px versus 1000 px versus max settings. I always assume that by having larger image preview size would speed up the image rendering on-screen.
I am think...if there is no significance improvements, I'd just rather leave the value at 1000 px.0 -
From WEB Help
"The Cache slider can be adjusted to set the size of the proxy file. The higher the Preview Image Size, the higher quality of the Quickproof output recipe and preview image that Capture One generates. A large cache setting will, however, increase the amount of time it takes to load previews and thumbnails in the application."
I do not quite understand what the team calls the "preview".
In my understanding this is what I see in a reduced form in the Browser Panel (Ctrl+B)
So here is the "Cache Preview Size" - does not affect the quality of the thumbnail images.
That is very bad. In the end, I can't quickly find the desired image in good quality. I have to wait when will create the final image from the RAW file.0 -
I have never quite got around to investigating the workings of the Preview system.
However it occurs to me that the overhead of keeping even a reasonably high resolution version (jpg?) of the 'as processed to date' image is relatively high, especially for those who have high volumes of images to process.
In fact it may make more sense, if simply wanting to view the current state of an image, to process it to a readily available jpg file and so allow it so be viewed in a variety of ways. If further edits are then applied - process a new version of the file. And so on.
Whather you wouold keep the outputs in a separate folder or have them in the same folder with a naming convention that keeps them with (or close to) the originals in the thumbnail bar (or whatever) is, I guess, a matter of personal choice. If separate of course C1 would not need to even attempt to open the Original and Edit files.
The same might be true for TIFF BUT they tend to be edit files anyway (unless C1 understand TIFFs with the embedded output jpgs and has a way to display those directly when requested.) In which case you would still have a large file and still a jpg to deal with. But if you want to see the results of the edit without jpg interference then I can't see an alternative to re-processing to get the latest state of edit at what ever size you want to work at. My recollection of earlier versions of, for example, LightRoom did much the same thing although the way that the UI was delivered to screen may have helped to persuade poeple otherwise.
Have I missed something very obvious?
Grant Perkins0 -
[quote="SFA" wrote:
..
However it occurs to me that the overhead of keeping even a reasonably high resolution version (jpg?) of the 'as processed to date' image is relatively high, especially for those who have high volumes of images to process.
.....
Have I missed something very obvious?
Grant Perkins
Grant,
When I started this thread I said
"On a group of 128 photos (not really large) it took CO over 7 min to create all the proxies, while the Image Core Process grew to >4.7G and stayed there. When I selected about a dozen photos to "auto process", CO usage grew to >1G. Even as it sat there, the CPU was running at about 14% even though I was doing nothing."
At that point, I had created no new jpegs or tiffs. All CO was looking at was the original batch of raw files.0 -
[quote="Jim MSP" wrote:
[quote="SFA" wrote:
..
However it occurs to me that the overhead of keeping even a reasonably high resolution version (jpg?) of the 'as processed to date' image is relatively high, especially for those who have high volumes of images to process.
.....
Have I missed something very obvious?
Grant Perkins
Grant,
When I started this thread I said
"On a group of 128 photos (not really large) it took CO over 7 min to create all the proxies, while the Image Core Process grew to >4.7G and stayed there. When I selected about a dozen photos to "auto process", CO usage grew to >1G. Even as it sat there, the CPU was running at about 14% even though I was doing nothing."
At that point, I had created no new jpegs or tiffs. All CO was looking at was the original batch of raw files.
Hi Jim,
Sorry, a little 'Subject Drift' creeping in I suspect. My observations were more connected with the replies from earlier today.
Coincidentally I had a situation last night where creating a zip file from a few hundred images took an excessively long time - hours in fact. I had a few things running but nothing I had not done before. The system is an old dual core cpu with 3Gb RAM running 32bit. 2 C1 windows in play and an instance of Photo Plus. The memory monitor widget was showing around 700 to 800 Mb free at all times, which is about normal too, though it can drop lower especially with a number of IE tabs open.
The slow zip creation and some very poor response from Photo Plus (no idea if that is normal - new version that I have not used much at all) did not seem to improve as I shut things down one at a time. Memory usage stayed about the same as well.
In the end I re-booted for the first time in several weeks and zip creation times returned to what seems to be normal. As yet I have not tried C1 or P+ again.
Now, I'm still running 6.3.2 and I have to say that it mostly seems pretty stable and resistant induced crashes (by hitting too many keys ahead for example).
Opening a large folder of images, even if previously processed, can take a while althogh oddly over a thousand images in a folder does not necessarily mean it will take proportionately longer than a hundred or so. That said the files I am working with are primarily between 10 and 15Mb - yours may be larger.
So overall and allowing for the different system specs. (or maybe because of the different system specs?) I'm not seeing anything that I could pin down as a regular and persistent memory leak. That doesn't mean to say there isn't one but if it does exist it's not normally too much bother. I would certainly appreciate faster in edit process times as well as faster loads from folder opening but for what ever reason the performance I am seeing is probably not to bad for the spec. of the machine. I would hate to spend a lens' worth of cash on a new machine for editing only to find that it made little or no difference!
I'm going to be watching how this works out with great interest.
Grant Perkins0 -
*** UPDATE *** We have verified an issues with the memory usage and we will address it in an upcoming release, although no word on when that will be released.
I have received the aforementioned reply via my P1 account from tech support. I am content and satisfied that the team found the verifiable issue concerning this lag/inconvenience I first reported. I am glad that I wasn't the one experiencing. This is the purpose of the user-to-user forum and I am glad to be apart of this wonderful (albeit), small community of PhaseONE CaptureONE users.
OK! Here is the suggested work-around: Leave the Image Preview in the Cache settings to "1000 px" (or lower if you wish). On my 6.3.4 64-Bit, C1PRO is running relatively fast as expected during Web Contact Sheet.0
投稿コメントは受け付けていません。
コメント
18件のコメント