Speeding up detection

[johnsiilver]

Speeding up detection

by johnsiilver » Wed Mar 06, 2013 6:20 pm

So I've been using autopano for a while. As I've progressed into more pictures per pano, I found the wait time to be painful on my current hardware.

I recently upgraded to a new Core i7 3.8 hexcore with 32 Gigs of ram. Here's the thing though:

Detection in autopano takes about the same time as it did before. This can be 20 minutes or so for 115 images on my test benchmark pano.

Ram spins up to about 4Gigs during detection and CPU usage doesn't get past 3%.

So am I missing a magic setting somewhere that says use my machine to the max?

Also, if anyone knows, I'm curious if enabling GPU causes a system to ignore the CPU mostly during processing. If that's true, when does cpu processing power exceed GPU's capability. If its one or the other, I'd rather be using whichever is faster.

[mediavets]

by mediavets » Wed Mar 06, 2013 6:31 pm

Welcome to the forum...

Which OS and which version of APP or APG are you using?

What format are the import images, what resolution and filesize?

[klausesser]

by klausesser » Wed Mar 06, 2013 9:37 pm

Detection in autopano takes about the same time as it did before. This can be 20 minutes or so for 115 images on my test benchmark pano.

That´s very long indeed. Do you import stacks (bracketed images)?

suggest to process RAWs and/or bracketed sets before stitching.


best, Klaus

[johnsiilver]

by johnsiilver » Sat Mar 09, 2013 8:33 pm

Sorry for the delay, I think I must have turned all email notifications off, so didn't realize anyone responded.

OS: Windows 7
Software: APG 64bit 3.0.4
Images: Tif, 126MB per image, 240DPI, 5760x3840pixels Uncompressed.

These are not bracketed sets.

The thing I found interesting is that APG, in essence, is not using any significant processing power during detection. During render or other operations my processors see a hit as expected, but not during detection. 6 cores, and I'm basically seeing 1% most of the time, 3% max during the detection phase. I assumed that even if kolor optimized the detection for memory consumption processing speed would be unbounded and heavily threaded. I wouldn't imagine it was IO bound (I have enough free memory to stick the entire set of images in memory and my disk is not being thrashed).

Other notes:
I used both detection as normal and the Gigapan import plugin.
My temp folders are stored on an SSD with 368GB free.
I have memory now set at 12GB.
Num CPU is set to 12 (hyperthreading for the x2)
GPU processing: enabled

[gkaefer]

by gkaefer » Sat Mar 09, 2013 10:12 pm

128MB x 115 Images = 14720MB < 12GB set Memory... so why not using the 32GB Ram you've installed?
Georg

[HansKeesom]

by HansKeesom » Sun Mar 10, 2013 11:06 am

So I've been using autopano for a while. As I've progressed into more pictures per pano, I found the wait time to be painful on my current hardware.

I recently upgraded to a new Core i7 3.8 hexcore with 32 Gigs of ram. Here's the thing though:

Detection in autopano takes about the same time as it did before. This can be 20 minutes or so for 115 images on my test benchmark pano.

Ram spins up to about 4Gigs during detection and CPU usage doesn't get past 3%.

So am I missing a magic setting somewhere that says use my machine to the max?

Also, if anyone knows, I'm curious if enabling GPU causes a system to ignore the CPU mostly during processing. If that's true, when does cpu processing power exceed GPU's capability. If its one or the other, I'd rather be using whichever is faster.

GPU is only used to make the preview in the editor. It is not used otherwise. If you want to check this, look for the GPU-Z programm

[johnsiilver]

by johnsiilver » Mon Mar 11, 2013 3:00 am

"128MB x 115 Images = 14720MB < 12GB set Memory... so why not using the 32GB Ram you've installed?"

Well, there are a couple reasons.
1. During the detection, memory isn't really touched that much. Render, different story.
2. Rendering for this particular set looks to use around 10GB. But render speed isn't a problem. If this was the problem, I'd probably set this up to 25 or so (still need room for the OS and the other software I run).

"GPU is only used to make the preview in the editor. It is not used otherwise. If you want to check this, look for the GPU-Z programm"

Yeah, that makes sense.

So, back to the main question, anyone got a clue to why my CPU utilization is pretty much nil? Figure I'm going to be opening a support ticket.

[con]

by con » Wed Mar 13, 2013 11:31 am

Perhaps it's something not so hardware related?

If you turn off optimization option when you run detection what are the results?

[HansKeesom]

by HansKeesom » Fri Mar 29, 2013 1:14 pm

Hi John, if problem is solved fine. Else, can you send us the files using dropbox or wetransfer. I can try the set for you on my 64 GB 8 core Xeon.

[con]

by con » Fri Mar 29, 2013 9:28 pm

Since your ram only spins up to 4gb in the original post, it may be a 64/32bit thing, might be worth investigating.
another path of investigation that would be worth checking out is see how well it does at detecting 8-bit jpg, 8-bit tiffs rather than 16bit tiffs. And then try and do a selection of 30 /60 /90 16bit tiffs and see how they compare...
I know none of these are de facto answers but are just standard trouble shooting tests, would be interesting how it works though

[foundation]

by foundation » Mon Apr 01, 2013 8:17 pm

Just as a double check you do have use multiple cores set to all your cores in the settings menu right?
that being said I think detection is single threaded. With a hexcore and hyperthreading there should be 12 cores available. 100% cpu on a single core would show up as 1/12th or ~8% of your cpu load.

You could also experiment with setting detection quality to low and fewer control points to see if that speeds up the detection process