Helicon Soft Forum

Thanks for the details, we will now try to reproduce this situation in our environment.

Stas,

Thank you for your interest in this issue.

Adding a folder of images to create a stack took 172 seconds to create a queue task consisting of 155 images. Changing parameters for the same group of images took an additional 172 seconds. There did not seem to be an efficiency gain to simply change parameters for the same folder.

For a smaller stack it took 2.14 seconds to create a queue task consisting of 12 images.

The increase in time is not linear at all.

My system info is:
Operating System: Windows 7 64-bit
Version: 6.1 Service Pack 1
System architecture: Intel CPU Family:6, Model:10, Stepping:5 with MMX, SSE Integer, SSE FP, SSE2, SSE3, SSE4.1, SSE4.2
Physical processor count: 8
Processor speed: 2806 MHz
Built-in memory: 12279 MB
Free memory: 9588 MB

That is strange, we optimized adding to queue greately. We will check this again but to reproduce your environment we would need to know how many stacks you are adding and how many images are in one stack.

Adding a stack to a queue is still very slow in HF 64-bit Pro. For repeatedly processing the same stack in a folder varying radius and smoothing it would be great to be able to generate a queue automatically. For example for each radius from 3 to 8 vary the smoothing from 2 to 5.

Sending tech details won't hurt but I'd not rely on that much. More efficient way is looks for some dependencies. Maybe even with stopwatch. Does the same folder gives always the same delay? Does it depend on the number of images in the folder? Does it depend o file type? Sorry for asking you to do a test job but we will not be able to fix this bug till we have more information about it.

I've tried it with a C:temp folder, still the same slow delay. There are no removable storage devices. If it helps I could post a system diagnostic/spec list?

That is very strange. It looks like there is a huge delays when reading folders or folder structure. What you can do right now is to call "heliconfocus.exe -notree" from command like. This will disable folder tree on the first tab. Not much hope, but worth trying. I would appreciate if you help to locate this bug. Please try with different folders and see if there is any dependency. Create c:\temp folder, place a few images there and check with this folder. Please also check if any network or removable drives are visible in the folder tree. We would appreciate any additional information about this problem.

I'm having similar issues with 64 Bit pro.

It opens up fine, but transitioning to the "Parameters" tab takes a while when I have large folders. Once there, it's pretty quick unless reading raw files (Canon 7D).

However, I'm wanting to do batches using the queue. Once I select the files I want to add to the queue, it apparently freezes. After a few minutes it resumes though. This makes it take just as long to do each image stack on its own as it does to wait for each stack to get added to the queue. It also takes minutes to open up the queue window.

I've also tried the folder approach, and this takes even longer for things to happen. Looking at my processor (I7) it's processing each stack within seconds, but taking minutes to move to the next stack, any idea why?

Thanks, Stas. The fact that you guys ask for our input to help improve HF is another reason it's such a great program. Keep up the good work!

Thanks for reporting this bug. We are preparing new version which is much reworked, we will make sure that this bug is fixed.

I typically run multiple stacks of 16-bit, 120 MB tiffs. Every time I open HF and try to start a stack, it freezes up. I have to close the program with Windows Task Manager, then reopen HF. The second time it usually works, and once it 'hits its stride' it processes subsequent stacks very quickly. Why is it always so slow to get started, and why do I have to close it out and reopen it to get it to work?

ASUS G73 w/i7 processor
8 GB RAM
Windows 7 Home Premium
Canon 5D Mark II