Win: Queue processing slow & does not use full cpu capacity

[eos60d]

I am currently re-evaluating hf (latest build) because my eos 60d now works w/ remote. I am on a box that has to be considered rather low-end (core i3, 4gb, win7-64), thus I am trying to queue my 18mp tif stacks and let them be process overnight. However, I am not exactly successful at doing that and am wondering if something's broke on my system:

* The parameter tab (radius etc) is only available when a picture is loaded - but I don't want immediate processing, just to reach the settings for the items to be queued.
[Edit: Ok, I figured out this is only because I deleted the sample images which are otherwise loaded on program startup]

* When queuing some subfolders, it taktes a very long time for hf to return to a resonsive state. Queueing the same subfolders with different settings takes a long time again. And after all that, there is no menu option "run queue", but I have to call "view queue" ... which takes ages again to appear (like 1hour+). During that, the cpu usage in 2 cores never even reaches 50%, the other 2 (hyperthreaded) cores are dormant [Edit: & HeliconFocus.exe keeps reading through the tif files from disk, I had a look w/ Process Explorer and Process Monitor].

Without putting too fine a point on it: Am I missing something here? 3D Modeling and all is very nice, but unless the basics run on my system, I won't even reach that stage. Queueing files shouldn't require any processing or time - after all, that's what the queue is there for...

[eos60d]

I discovered that queueing works ok when I manually load an image batch and then add it, while it slows to a crawl when adding folders or subfolders...

[Stas Yatsenko]

I think we already optimized the speed of adding to queue but it will do no harm to check it again. We tested with about 1000-2000 of images and dozens of stacks, maybe you worked with much larger amounts of images? While we are trying to reproduce this bug I would appreciate if you send us more information about your stacks.

[eos60d]

The stacks are from a midrange canon eos, exported from lightroom, 18MP photopro tif (I tried 24bpp & 48bpp, compressed and uncompressed), each of the 20 folder contains ~30 images.

I've had another systematic look at it, and here's the result: The problem simply seems to be that the more stacks are queued, the slower queueing new items (manually or via add folder) gets and esp. "view queue" takes ages when many stacks are queued. I guess that's the reason why adding the 20 folders via "add subfolders" is so agonizing slow. Manually loading images and adding them seems to have a small edge over "add folder", but I didn't time that, so I'm not really sure.

After being really annoyed (I want to take pictures, not debug software), I dug out an old version v4 of hf, and everything's working there just fine - while there unfortunately is no option to queue folders or even subfolders, loading images -> add to queue -> clear list -> ... & view queue works in a snap, so it's really a bug with v5.

[Stas Yatsenko]

Thanks for this information. This bug will be fixed in the next release.