PTGui 9, Performance, and best Hardware

97 views
Skip to first unread message

enridp

unread,
Sep 23, 2010, 4:42:53 PM9/23/10
to PTGui Support
Hi ! I was reading a lot about performance in PTGui and differents
configurations in this group, but far from having the things clear,
I'm really confused now.

Please can you make some type of wiki or FAQ about the best hardware
and configurations?

This is what I "understood" (but I'm not sure if I'm right):

1) Use PTGui with 2 cores
2) Close Antivirus
3) a) use HDD RAID0 for temp files?
b) use SDD RAID0 for temp files?
c) use RAM disk for temp files?
4) a) don't buy extra memory because PTGui does not use it (unless you
make a RAM disk)
b) buy a lot of memory because PTGui 9 will use it
5) a) buy a processor with just 2 cores and a lot of GHz
b) buy a processor with a lot of cores
6) use MAC when it's possible?

I want to buy a PC only for panoramas (and maybe gigapanos) using
PTGui. And I want to take the best decision.
Please can you help me with it?
I was reading a lot and I'm really confused.

Also, if we have 8 cores, and we use 2 cores for PTGui, can we open 4
PTGui instances and work with 2 cores in each one? and maybe with a
dedicated disk for each PTGui.

Thanks!
Enrique.

Hans

unread,
Sep 24, 2010, 3:07:12 AM9/24/10
to PTGui Support
To answer your last question No, thats a very bad idea.

I have done the test as you can very easy on a Mac create a duplicate
PTGui and open both.
I have an iMac i7 with 8 threads as auto setting but using 2 is the
fastest.

My test set was an 8 images 16bit - 21 mp images and output 14800x7400
16bit.

Time for running it with one PTGui was 3.35
Running 2 identical panoramas with 2 PTGui took 16.15

Hans

PTGui Support

unread,
Sep 24, 2010, 4:12:29 AM9/24/10
to pt...@googlegroups.com
Hi Enrique,

I can only give some general guidelines, performance is an extremely
complex subject since it is caused by the interaction of different
hardware components (CPU, memory, disk and caching). Further, stitching
places a different kind of load on your system than blending: stitching
generates a continuous stream of data, blending requires much random and
fragmented access. Also the PTGui blender is currently limited to a
single core. Finally much depends on the size of the panoramas you are
going to stitch.

That said:

If you are planning to stitch many small to medium sized panoramas, get
lots of ram and a fast processor. Having enough RAM prevents that PTGui
will need your hard disk for temporary storage. Then the CPU becomes the
bottleneck so a faster processor will speed things up.

If you are going to do gigapixels the main bottleneck is the hard disk,
so get a fast RAID or possibly an SSD. I'm not a hardware expert but
others can give you some advice here. Once the hard disk is the
bottleneck the processor speed or the number of cores won't improve the
stitching speed, and using too many cores may indeed slow things down
because it will cause a more fragmented stream of data to be written to
the disk.

There are two parameters you can tune:

- the amount of RAM PTGui will use at most. Set this as high as possible
but not too high. If PTGui attempts to use more RAM than is available
this will cause other applications to be swapped to disk, which can
bring your computer to a halt.
Also be sure to close other applications such as Photoshop which can
also claim gigabytes of memory.

- the number of cores. Hans will tell you that 2 is the best but this is
not a general thruth. For example here's a test on my quad core machine:
1 core: 43.03s
2 cores: 28.47s
3 cores: 24.13s
4 cores: 21.12s
Of course this is for a small 6000x3000 panorama which fits in RAM.

Get the 64 bit version of PTGui. Now that PTGui (9 beta) for mac is
available in 64 bit too it doesn't make much difference whether you
stitch on Windows or OS X. A RAM disk only made sense with the 32 bit
version since it was limited to 2 GB of RAM.

And yes definately make sure that your Antivirus is not intercepting the
PTGui temporary files.

Joost

PTGui Support

unread,
Sep 24, 2010, 4:34:59 AM9/24/10
to pt...@googlegroups.com
Hi Hans,

How much RAM is your PTGui configured to use?

Joost

Hans

unread,
Sep 24, 2010, 4:49:25 AM9/24/10
to PTGui Support


On Sep 24, 10:34 am, PTGui Support <supp...@ptgui.com> wrote:
> Hi Hans,
>
> How much RAM is your PTGui configured to use?

69% = auto from 8GB

You are right that very small panoramas can benefit from all cores.
Actually it is the actual image size not the final panorama. Thats
what I could see from the Gigapixel test which uses very small images
and can use more cores.
But it changes pretty fast when you go up to what most people stitch
today.

Here are my tests.
6000x3000 8 bit
2-30 sec
4-22
8-25
10000x5000 8 bit
2-68 sec
4-70
8-130

Hans

Hans

PTGui Support

unread,
Sep 24, 2010, 5:07:30 AM9/24/10
to pt...@googlegroups.com
On 24-9-2010 10:49, Hans wrote:
>> How much RAM is your PTGui configured to use?
>
> 69% = auto from 8GB

So two instances will attempt to use 138% of your ram..

> You are right that very small panoramas can benefit from all cores.
> Actually it is the actual image size not the final panorama. Thats
> what I could see from the Gigapixel test which uses very small images
> and can use more cores.

You can easily see how much PTGui needs for a panorama. Go to Project ->
Calculate Temporary Disk space. For your 14800 16 bit panorama this is
about 11 GB. My 6000 pixel 8 bit panorama needs 1.3 GB.

Keep in mind that these are just pessimistic estimates, and there are
many factors in play, but in general once this number exceeds the amount
of RAM the stitching becomes more and more disk bound.

> But it changes pretty fast when you go up to what most people stitch
> today.
>
> Here are my tests.
> 6000x3000 8 bit
> 2-30 sec
> 4-22
> 8-25

Your i7 iMac is in fact just a quad core processor with Hyperthreading.
Hyperthreading allows the CPU to quickly switch to another thread if one
thread is waiting for data from memory. For truly CPU bound processes
(i.e. heavy calculations) the performance gain is minimal. I'll see if
PTGui can be made to use the real number of cores and ignore
hyperthreaded cores.

Joost

Hans

unread,
Sep 24, 2010, 5:18:04 AM9/24/10
to PTGui Support


On Sep 24, 11:07 am, PTGui Support <supp...@ptgui.com> wrote:
> On 24-9-2010 10:49, Hans wrote:
>
> >> How much RAM is your PTGui configured to use?
>
> > 69% = auto from 8GB
>
> So two instances will attempt to use 138% of your ram.


They devided the 69% between the 2 instances.3+2.5 GB at max
The weird thing was that the second PTGui first took over and while
the first one was at 1-2 warping the second had reached 3-4 but when
it came to the last image they both was equal and they saved the
panoramas at the same time.

Hans

PTGui Support

unread,
Sep 24, 2010, 6:18:41 AM9/24/10
to pt...@googlegroups.com
On 24-9-2010 11:18, Hans wrote:
>>>> How much RAM is your PTGui configured to use?
>>
>>> 69% = auto from 8GB
>>
>> So two instances will attempt to use 138% of your ram.
>
>
> They devided the 69% between the 2 instances.3+2.5 GB at max

No they don't. Each PTGui process will (try to) use the configured
amount of RAM.

> The weird thing was that the second PTGui first took over and while
> the first one was at 1-2 warping the second had reached 3-4 but when
> it came to the last image they both was equal and they saved the
> panoramas at the same time.

What you see is two processes fighting for the same resources. The OS is
continuously trying to swap both processes to and from disk.

Joost

enridp

unread,
Sep 24, 2010, 12:46:49 PM9/24/10
to PTGui Support
Thanks Hans and Joost, many things became clear now.
But I'm a fanatical of summaries.
So...
we have two big branches in our performance:
1) Small panoramas
2) Big panoramas

But, what's is small and what's is big? 6000x3000 is small, but
8000x4000?
Also, Hans says that the final output is not important, but the
individual image size yes. Does it mean that we can stitch a panorama
faster if our individual images are small? (and in such case, again,
what is small?)

1) For Small Panoramas:
High CPU, multiple cores is better than GHz and 4 cores is the optimum
Lot of memory
Disk is not important because we don't use it

2) For big Panoramas:
Less cores, and big GHz
Memory is not so important
We need high speed in our disk drive (RAID0 or SDD) -> and here what's
is the best? opinions are very contradictory

About Windows7 vs OSX, I've read that OSX is managing better the
memory assignment, PTGui uses all the memory in OSX but in Windows it
uses only a small part (even when we are configuring it for using
90%):
http://groups.google.com/group/ptgui/browse_thread/thread/52d88fd695f4dd7d/

That's related with RAM disks too, because some members said that the
only way for using the total memory in windows7 is making a RAM disk.
But that's is for PTGui 8.3, is this fixed in PTGui9?
So, what is better? to let PTGui use the memory from the system, or to
force it making a RAM disk?

Also, Hans said that is not a good idea to open multiple PTGui, but
Joost said that it could work if we configure each PTGui to use less
memory (suppose 40% for each one, not 69%). Who is right?

summarizing:
a) what is "small" and "big"? (I want to make panoramas of about
8000x4000 in RAW12/14 because I want apply a tone mapping later)
b) what is better, HDD_RAID0 or SDD? (if we have a SDD we don't need
to make a RAID0?)
c) is solved the Windows7 problem with memory assignment in the new
PTGui9? (or is always better to make a RAM disk?)
d) what about multiple PTGui instances? do you think is possible if we
have multiple cores and a LOT of memory (assigned properly)
suppose 8 cores, 3 PTGui instances with 2 cores, 32GB RAM, 30% for
each PTGui.

Regards!
Enrique.

PTGui Support

unread,
Sep 27, 2010, 3:13:43 AM9/27/10
to pt...@googlegroups.com
On 24-09-10 18:46, enridp wrote:
> Thanks Hans and Joost, many things became clear now.
> But I'm a fanatical of summaries.
> So...
> we have two big branches in our performance:
> 1) Small panoramas
> 2) Big panoramas
>
> But, what's is small and what's is big? 6000x3000 is small, but
> 8000x4000?

See Project -> Calculate Temporary Disk Space.
'big' is when it exceeds the available RAM on your computer by a factor
of 1.5 or so.

> Also, Hans says that the final output is not important, but the
> individual image size yes. Does it mean that we can stitch a panorama
> faster if our individual images are small? (and in such case, again,
> what is small?)

Final output size is the most important factor in memory usage, but
source image size does have some influence.

> About Windows7 vs OSX, I've read that OSX is managing better the
> memory assignment, PTGui uses all the memory in OSX but in Windows it
> uses only a small part (even when we are configuring it for using
> 90%):
> http://groups.google.com/group/ptgui/browse_thread/thread/52d88fd695f4dd7d/

Not true; PTGui's memory management on windows and mac is identical.
There may be some small OS related differences (Windows is a bit more
efficient in handling mutexes for example)

> That's related with RAM disks too, because some members said that the
> only way for using the total memory in windows7 is making a RAM disk.
> But that's is for PTGui 8.3, is this fixed in PTGui9?
> So, what is better? to let PTGui use the memory from the system, or to
> force it making a RAM disk?

On 64 bit windows using a RAM disk should not improve anything.

> Also, Hans said that is not a good idea to open multiple PTGui, but
> Joost said that it could work if we configure each PTGui to use less
> memory (suppose 40% for each one, not 69%). Who is right?

It's possible but you gain nothing so just run a single instance.

Joost

enridp

unread,
Oct 7, 2010, 12:29:36 PM10/7/10
to PTGui Support
Thanks Joost, I'll make some tests and put the results here when I buy
the new hardware.
Reply all
Reply to author
Forward
0 new messages