SSD RAID0 for PTGui swap.

[Greg Takacs]

I'm trying to decide what is more important for PTGui when it writes
to the swap drive. Random or sequential write. The reason for the
question is that while the new Intel x25-m G2 drives seem to have the
best random access speeds of the bunch (within reasonably priced MLC
units) , the OCZ Vertex, hell even the WD Velociraptor blows the pants
off the Intel when it comes to sequential writes. So which is more
important for the PTGui swap?

[supertrogg]

I have 24Gb installed on my workstation and use a virtual RAM drive
(www.farstone.com Virtual Hard Drive Pro) set to 12Gb. This blows the
pants off my Velociraptor RAID! I can even pre-load the images, for a
small pano, to the virtual drive and set the stitch going. It runs
even faster then!!

[Joergen Geerds]

I am doing some test/research into the ptgui disk thrashing behavior,
and from what I can see, sequential writes are completely irrelevant.
ptgui is writing data to many files at the same time, in a very
fragmented way (aka totally randomly), so random _write_ access and IO
per sec are trumping everything (read access doesn't really matter for
ptgui). From what I can see, solid state disks and RAM disks are much
more advisable than any HD based RAID for ptgui scratch at this point.
The random access becomes more important for mid and large sized
panos, since small panos (<10000px) render fast in any setup anyway.

for those who are using solid state disks and ram disks, please post
some numbers how much faster rendering is compared to your previous
setup, hopefully we can compile some real-world numbers, and not only
comments with "it's so much faster"

http://anandtech.com/storage/showdoc.aspx?i=3631 posted a updated view
about SSD, especially the new/used behavior is very important for
ptgui, since you can fill up a SSD in just a single session.

another thing to consider is using a good sata controller, and no port
splitter. each of the new SSD will saturate a single sata channel all
by it's own, and it's pointless to put 2 of them on the same channel.
most raid cards also have a 600mb/s limit, so it might not be worth it
to put more than 2 SSD on the same raid controller.

joergen

[360 Precision]

Does it really matter unless you're batch processing hundreds of
panoramas per day ? It seems that certain people really seem to focus
on the minute details that at the end of the day are completely
irrelevant in the vast majority of workflows.

If you're CPUs are working 24/7 processing thousands of panos then I
guess these questions are important. But for most people these issues
are simply wasted time.

Matt

[Greg Takacs]

I think it does matter. I have an i7 920 with 12GB or RAM and hate to
be I/O bound. Mind you that even with two Intel X25-M 2G drives in
RAID0 panorama stitching will be I/O bound. I think with the latest
hardware available with large chunks of RAM and 8 threads running
consecutively on 4 cores PTGui should re-visit the way it does file
handling and caching. I just can't imagine that it's doing it the best
way possible when I see 8K reads going down to the drives thousand
times a minute.

From the looks of it I think I will be served well with two Intel X25-
M G2s. Now if they could just fill the backorder on them I'd be a very
happy camper.......

[Joergen Geerds]

On Sep 13, 11:22 am, 360 Precision <matt...@360precision.com> wrote:
> Does it really matter unless you're batch processing hundreds of  
> panoramas per day ? It seems that certain people really seem to focus  
> on the minute details that at the end of the day are completely  
> irrelevant in the vast majority of workflows.

Hi Matt,

I beg to differ here. PTgui is currently not a speed daemon, at least
not on my machines. i.e. a simple 11 fisheye tile pano (15x7.5kpx, 16
bit, no brackets) takes 90 minutes to render under 8.22 and 10.6,
which means I can do 16 of those panos in a day, not "thousands", and
to me isn't really utilizing the hardware I have sitting on my desk.
(btw, ptgui 7.6 does the same pano in 45min).

so, if you have a magic setup/setting how ptgui can do thousands of
panos in a day, I would really like to hear about it.

joergen

[Joergen Geerds]

sorry, "hundreds," not "thousands."

joergen

[Ken Warner]

Greg Takacs wrote:

I think it does matter. I have an i7 920 with 12GB or RAM and hate to
be I/O bound. Mind you that even with two Intel X25-M 2G drives in
RAID0 panorama stitching will be I/O bound. I think with the latest
hardware available with large chunks of RAM and 8 threads running
consecutively on 4 cores PTGui should re-visit the way it does file
handling and caching. I just can't imagine that it's doing it the best
way possible when I see 8K reads going down to the drives thousand
times a minute.

Joegen Geerds wrote:

I am doing some test/research into the ptgui disk thrashing behavior,
and from what I can see, sequential writes are completely irrelevant.
ptgui is writing data to many files at the same time, in a very
fragmented way (aka totally randomly), so random _write_ access and IO
per sec are trumping everything (read access doesn't really matter for
ptgui). From what I can see, solid state disks and RAM disks are much
more advisable than any HD based RAID for ptgui scratch at this point.
The random access becomes more important for mid and large sized
panos, since small panos (<10000px) render fast in any setup anyway.

Could you two tell me what kind of software or hardware tools you are
using to get I/O statistics like this? I'm on a Windows Vista 64 machine
and I don't see any way to observe I/O at this level of detail.

[Joergen Geerds]

On Sep 13, 12:54 pm, Ken Warner <kwarner...@verizon.net> wrote:
> Could you two tell me what kind of software or hardware tools you are
> using to get I/O statistics like this?  I'm on a Windows Vista 64 machine
> and I don't see any way to observe I/O at this level of detail.

on win7/64 go to the start menu > all programs > accessories > system
tools > resource monitor
(i am not sure if vista has a similar tool, but I would think it does)

this is how i found the way ptgui is doing it's disk thrashing.

joergen

[Matthew Rogers]

Hi Joergen,

I just tested an 8 image pano output at 15k x 7.5k 16 bit and it took
11min 20secs. The speed difference probably comes down to the
interpolator and blend option you're choosing, neither if which will
be sped up by faster disks but possibly benefit from more RAM. With
the cost of SSD still quite high I'd personally buy a Mac mini or
build a cheap PC to offload the stitching to.

My machine specs are MacPro 2 x 2.66 with 16gb RAM running OS 10.6. I
ran the tests using the standard boot drive for all operations using
PTGui 8.2.2.

Matt

[HansNyberg]

90 minutes . Are you kidding.

My normal output is 11500x7500 8 images which takes around 13 minutes
but I did a test with 8 21Mp images 16bit TIF.
Output 15000x7500 16 bit Fast Transform and Bicubic w PTGui blender.
PTgui 8.2.2
Time 27 min 21 sec. 11 images should have added 10 minutes.
And that is a G5 from 2005. Mac dualcore 2.0 G5 - 8 Gb Ram.

I am surprised that Matt used 11 minutes for the same. I would have
expected it to be faster.

Hans

[Joergen Geerds]

I did a test last night and was able to render 6+6+1 into a 15500x7750
in 46 min, but maybe it is slower because I am using lanzcos, and not
bicubic.
it is really difficult to get a handle on faster rendering... but the
problem only gets worse when you increase the rendering size... those
15k panos are really just toys, my usual work is 30-40k wide.

more testing...

joergen

[Matthew Rogers]

Yes, Lanzcos will dramatically increase the render time but this is
not I/O bound, it's CPU dependent so no number of SSDs will decrease
your render time.

Matt

[Matthew Rogers]

Why though ? opening 8 x 16 bit tiff files takes no more than 10
seconds if that. Writing the scratch file for processing and then the
final output image take up a small fraction of the overall image
rendering time. The vast majority of the time is spent warping and
blending the images. I'd say the I/O would account for no more than
10% of the overall time needed to render an image.

As for the read/write ops I see 2-3 reads per image and about 200-300
writes per minute but that's with other apps open and system processes
running.

Matt

[Jeffrey Martin]

On Sep 13, 5:22 pm, 360 Precision <matt...@360precision.com> wrote:
> Does it really matter unless you're batch processing hundreds of  
> panoramas per day ?

YES :-)

[bv...@gmx.at]

> on win7/64 go to the start menu > all programs > accessories > system
> tools > resource monitor
> (i am not sure if vista has a similar tool, but I would think it does)

Vista has a similar Resource Monitor like Seven, just not so powerful.

May i point to the PTGui Speedtest page? http://hdview.at/speedtest/results.html
This test is heavily I/O bound.

My job has to do a lot with storage and i already spent some time
evaluating current SSD's performance and durability.
From my point of view, i suggest to skip current SSD drive generation
just to increase performance (they still are nice to use as a system
disk). Only the expensive Intel X25-E drives come near to what you
would expect.
Buy a modern SATA disk with a good controller and as much RAM as you
can get. A WD Raptor RAID 0 still easily outperforms a SSD at the same
price range...

* SSDs are prone to disk thrashing and are becoming noticeable slower
over time and with increasing fill level. This is, because SSDs can
only (read and re-)write back complete blocks - even if only a few
bytes are changed.
* Most controllers built in SSDs are relatively weak. I observed
several disks crashing during heavy load.
* No current operating system's file level driver will account for the
physical characteristics of an SSD. Linux can't, Windows has been
announced for Version 7, for Mac i don't know.
* Several companies already announced "slot-in" SSD cards with will
circumvent the SATA whoes & bottlenecks. e.g. OCZ announced a 1TB
drive for under 1500$. Slot-in drives will go probably more towards
your expectations in the near future...

Best regards
Bernhard

[Greg Takacs]

Matt,

If PTGui would do what you propose to do (load all tiffs into memory,
process them in memory then write them out to swap in whole until it
processes the next image) then you are correct, it would not matter so
much how fast your drives are and the whole process would not be I/O
bound. However, this is not the behavior I'm experiencing on my
system. Considering I'm using 8 threads on 4 cores it loads and writes
8 concurrent images from/to disk and it does not do it in large
chunks. It's doing small incremental writes to the temp files which is
a real I/O killer. The majority of my processing is spent reading and
writing small chinks of files onto my RAID0 array. It is not spent
processing warps and stitches. I can tell because my I/O is 100%
saturated with more I/O operations queued than you can throw a stick
at while my 4 cores are twiddling their thumbs waiting for data to be
processed.

As soon as I throw an 8GB RAM drive at the problem and tell PTGui to
use that for swap things become blazing fast. Everything is fine until
I run out of disk space on the 8GB drive at which point it's back to
slow as molasses reads/writes on my secondary swap drive, that is
unless it crashes with out of disk space error in the middle of
processing.

Without the RAM disk I think I/O accounts for about 80% of the time
spent on a panorama as my cores are sitting idle for the most part.

I think PTGui should handle reads/writes smarter and only read and
write data in large chunks instead of 8k segments. There is another
issue with memory not getting utilized, hence the need for the RAM
disk, see my other thread: http://groups.google.com/group/ptgui/browse_thread/thread/52d88fd695f4dd7d

I think most people are still not affected by this issue as having
12GB RAM and 8 processing cores to run stitching is still the
exception than the rule. But these machines will become mainstream in
a matter of time at which point it will be obvious that the way PTGui
handles memory and I/O should be seriously reconsidered. What worked
on a single thread with 2GB RAM certainly doesn't work on 8 threads
with 12GB RAM. At least not 6-8 times better. Which is kind of a buzz
kill when you buy a new machine with the sole purpose to stitch
faster.

[Greg Takacs]

On Sep 14, 12:05 pm, "bv...@gmx.at" <bv...@gmx.at> wrote:
> May i point to the PTGui Speedtest page?http://hdview.at/speedtest/results.html

> This test is heavily I/O bound.

I will try that test tonight and post my results.

> Buy a modern SATA disk with a good controller and as much RAM as you
> can get. A WD Raptor RAID 0 still easily outperforms a SSD at the same
> price range...

I already have 12GB RAM which is pretty much as much as you can get
without having to venture into the realm of crazy pricing at the 4GB
per module level. However, as I have pointed it out in another thread,
more RAM does not mean that PTGui will actually utilize it.

A WD Raptor RAID 0 will only outperform an SSD setup if you write
large chunks of data. As soon as you get into random access reads and
writes, which is exactly what PTGui does, it will not hold a candle to
the Intel SSDs.

> * SSDs are prone to disk thrashing and are becoming noticeable slower
> over time and with increasing fill level. This is, because SSDs can
> only (read and re-)write back complete blocks - even if only a few
> bytes are changed.

Actually the G2 Intel drives show very little performance degradation
over time without TRIM. With TRIM new and used performance should be
identical or very close to it.

> * No current operating system's file level driver will account for the
> physical characteristics of an SSD. Linux can't, Windows has been
> announced for Version 7, for Mac i don't know.

I'm running Windows 7, I think I'll get the benefit of TRIM soon.

> * Several companies already announced "slot-in" SSD cards with will
> circumvent the SATA whoes & bottlenecks. e.g. OCZ announced a 1TB
> drive for under 1500$. Slot-in drives will go probably more towards
> your expectations in the near future...

$1500 is a bit out of my reach, even if it's more economic on a per GB
basis than the current SSD drives. Two Intel X25-n G2 80GB is pretty
much my limit in terms of price. I also figure once they go down in
price and I can afford to upgrade I will move one of them into my
netbook and put the other one into my tiny HTPC in my bedroom.

Thank you for your insight on the matter. I will report back once I
get the drives whether they have produced any kind of measurable
performance boost.

[Joergen Geerds]

I agree with you that the first generation SSD wasn't a good idea to
use for ptgui scratch, but the latest crop of SSD seems to do much
better:

OCZ Vertex review: http://www.barefeats.com/hard118.html
SSD RAID0: http://www.barefeats.com/nehal09.html

More RAM is probably the best thing at the moment (16GB are just
$400). Even if ptgui is using just a tiny fraction of RAM (nowhere
close to what it could use on a 64bt system), maybe using it for a RAM
disk is a good idea. (I did some preliminary tests last night after I
found out that OSX 10.6 allows RAM disks >2GB, so a 16GB drive is no
problem at all anymore, but the results weren't that impressive, the
"disk traffic" just barely doubled.)

joergen

[Matthew Rogers]

Well OS X automatically uses it's own ram-disk at a system level to
cache I/O operations. That might be the reason I'm seeing far fewer I/
O operations to disk and far lower memory usage.

Matt

[Greg Takacs]

Oh no, we're down to a Mac vs. PC discussion now ;-). J/K. In all
seriousness I guess it is hard to discuss issues when people are
running so many different systems and OS and having a different user
experience because of it. People who run 32 bit Windows are completely
aware of the situation that you can't get past the 3.5GB OS memory
limit so they don't even concern themselves with PTGui not being able
to use all their memory as I've seen, PTGui will indeed use all that
memory with the right amount of source files.

Then there are people running 16GB RAM in under OSX and experience no
problems either.

Then there are folks like me, running 12GB RAM on Windows 7 64bit and
notice that there might be problems. I just hope that Joost will see
these and address them....

[Greg Takacs]

OK, I just did the speedtest. It took 1 hour 3 minutes for the render
to complete. I ended up with a 2.3GB TIF file that cannot be opened at
the moment, but the render completed. Some notes:

1) I didn't realize, but I had my virus scanner turned on before, and
it substantially hurt PTGui. Once I had it turned off, the memory
usage actually has crawled up to the 9GB level, but most of it was in
shareable memory meaning that PTGui allocated it but if some other app
was coming along it would have given it back in no time.

Here is how the test time line went:

21:09:00 - I started the render.
It warped all 337 images in 13 minutes 45 seconds. The CPU utilization
was around 30% for this process and the actual memory usage was 1.4GB
even though PTGui has allocated 9GB, but most of it was shared and not
really used.
21:22:45 - Blending started. CPU usage went up high and memory usage
went to the highest point at 10.4GB allocated to PTGui. It was all
used.
21:24:45 - Blending is still going, memory usage has dropped to 6GB
steadily over the time, CPU utilization is at 0%. Files are getting
written to the temp drive heavily at 100MB/s rate.
21:26:30 - Bleding is still going, memory usage is down to 37MB! CPU
usage is at 0%. We're writing files at 45MB/s and reading them at 13MB/
s from the swap partition
21:30:30 - Blending is still going, memory usage is still 37MB, I/O
has changed direction, now we're reading 13MB/s and writing 2.5MB/s.
CPU usage is 0.45% Average. At this point PTGui also started accessing
my pagefile for no real good reason, considering all the free memory I
have, about 11GB total.

I have left the process for a while and eventually in over an hour
blending finally finished and it went on to save the file which went
rather fast, but it was back to my RAID1 system volume so it was
slower than writing onto the RAID0. Total blending time was 1 hour 18
minutes.

From the above you can see that every single operation in the process
was I/O bound. This is very sad. VERY sad. Especially when I had 11GB
of free RAM sitting around for over 40 minutes.

I will run the same test once I get my SSDs in and see how they
perform.

Joost,

Is there an explanation why PTGui does nothing but perform I/O on my
drives for over 40 minutes with absolutely zero memory or CPU
utilization?


> May i point to the PTGui Speedtest page?http://hdview.at/speedtest/results.html

> This test is heavily I/O bound.

You weren't lying. I think I could have run the test on my P4 3GHz
with 4GB RAM and get the same result. Certainly not what I have
expected.

[Matthew Rogers]

My reply wasn't about Mac V PC it's about the fact that it might not
be an issue that PTGui has any control over. The IDE used to create
PTGui may handle the memory allocation and I/O at a level beyond the
control of PTGui.

Matt

[Matthew Rogers]

Well clearly there's something wrong with the activity monitor on the
PC if blending and I/O is occurring with the CPU at 0%. If this is in-
fact the case I wouldn't believe any of the figures reported.

Matt

[Greg Takacs]

I just tried Autopano Giga 2.0.3 64bit. With their built in multiblend
I could stitch the same speed test in 11 minutes 23 seconds. There was
no hard drive thrashing, just smooth 100% CPU usage. That thing was
wicked fast! Using Smartblend it was slow but their own wiki kind of
warns about Smartblend being slow due to being single threaded and
hard drive heavy.

Looks like there might be a new sheriff in town......

[Greg Takacs]

Matt,

I have used Windows 7 built in resource monitor swapping between the
CPU/Memory and Disk tabs. On my 4 core hyper-threaded system during
blending half the CPUs were parked by the OS, meaning they were set to
power saving as they were not in use. The 0% CPU might have been an
oversight, but I don't think it was substantially higher than that.
Clearly the whole process was I/O bound for over 40 minutes of the
processing. This is actually very close to the experience Robert
Riegler recorder on the Gigapixel Speedtest page (footnote 4,
http://hdview.at/speedtest/results.html ) :

Total Stitching Time (46min)
Warping (16min) --> max Mem 3,40GB ; CPU ~ 60-90% (at 3,8Ghz)
Blending (30min) --> max Mem 7,5GB -> 1,60GB (2min 40sec) ; CPU ~
15-20% (at 2,4Ghz); saving time: 1min

He reported 15/20% cpu usage for the slow part and his one stitcked 20
minutes faster than mine on a slower processor. It is clear that he
had a better RAID-0 setup than me, hence the faster render and higher
CPU utilization. There is nothing wrong with the activity monitor.
It's just that badly I/O bound on my system.....

[Mick Crane]

On 15 Sep 2009, at 14:03, Greg Takacs <gtaka...@gmail.com>

It is clear that he
> had a better RAID-0 setup than me, hence the faster render and higher
> CPU utilization. There is nothing wrong with the activity monitor.
> It's just that badly I/O bound on my system.....
>

It's not at all something I am knowledgeable about but I notice that
you make some assumptions.
I'd be wary of making any, particularly about windowsOS.
It does seem likely that the kernel thingy is responsible for disk
writes and stuff.
Regards

Mick

[Greg Takacs]

> It's not at all something I am knowledgeable about but I notice that  
> you make some assumptions.

Would you care to show where my assumptions lie? It is a simple fact
that PTGui was not optimized to use large (2GB+) amounts of RAM in its
internal blending algorithm. Warping goes pretty much as fast as it
can considering the I/O but once it has warped the individual images
it has a hell of a tough time blending them together using optimal
memory and disk management. This is the fact. This is what I, and
others have experienced. As to what it's doing internally or why it is
so severly I/O bound at this stage, we can only make guesses as I am
not the writer of PTGui.

However, having ran Autopano Giga 64bit and PTGui on my system back to
back I can see that Autopano is nowhere near the memory hog nor the I/
O hog that PTGui is. My numbers don't lie. Autopano never used more
than 1GB of RAM yet it still finished the panorama under 12 minutes.

All I'm looking for at this point is some acknowledgment of the issue
and a promise that it will be reconsidered for a rewrite in future
releases. I never said it was an easy problem, I'm just saying it's
not an impossible task to deal with. Autopano is the living proof that
it can be done. If it requires complete rewrite of the way PTGui
manages and blends panoramas, so be it. It doesn't change the fact
that as the way it stands you can throw all the RAM and CPU in the
world at it it will not go any faster.

> I'd be wary of making any, particularly about windowsOS.
> It does seem likely that the kernel thingy is responsible for disk  
> writes and stuff.
> Regards
>
> Mick

The OS only writes what it's asked to write. If it's asked to write
8kb chunks at a time and read 16kb chunks at a time, it will oblige.
It might try to make it better by caching but it doesn't have to.
There has to be internal caching inside PTGui to make sure it doesn't
try to read and write in this fashion and processes things in bulk and
parallel. It is clear that the warping has implemented parallelism
that benefits from multiple threads and cores, the blending is the
part that severely lacks. PTGui's internal blender is not the only one
that has this issue. Smartblend is just as badly written and just as I/
O bound as the internal blender. But as Autopano has proven, it is
certainly possible to do it better/faster.

I have been a PTGui user since PTGui 5.4 so this is not my first try
at panorama stitching. However this is the first time when I have a
super fast machine with tons of RAM that really show the
inefficiencies and lack of proper memory and I/O management in PTGui.
With single threaded processing on 2GB systems the I/O boundness of
the system wasn't so apparent and in all honesty I never bothered with
extensive tests. But with my current setup I expected some major speed
benefit in stitching instead I got idle cores and tons of free RAM
that I can use to surf the net or write posts on discussion groups
while my render is going. Instead of questioning my testing
methodology and pick on assumptions I'd say we should focus on
acknowledging the problem and fixing it in a future release.

I'd welcome anyone else with different OS/System to pefrom the
Gigapixel Test and report their findings. I'd venture to say that my
system will not fair much better than a core2duo with 4GB RAM which is
clearly wrong. There's an assumption for you.

[michael crane]

2009/9/15 Greg Takacs <gtaka...@gmail.com>:

>
>> It's not at all something I am knowledgeable about but I notice that
>> you make some assumptions.
>
> Would you care to show where my assumptions lie? It is a simple fact
> that PTGui was not optimized to use large (2GB+) amounts of RAM in its
> internal blending algorithm. Warping goes pretty much as fast as it
> can considering the I/O but once it has warped the individual images
> it has a hell of a tough time blending them together using optimal
> memory and disk management. This is the fact. This is what I, and
> others have experienced. As to what it's doing internally or why it is
> so severly I/O bound at this stage, we can only make guesses as I am
> not the writer of PTGui.
>
> However, having ran Autopano Giga 64bit and PTGui on my system back to
> back I can see that Autopano is nowhere near the memory hog nor the I/
> O hog that PTGui is. My numbers don't lie. Autopano never used more
> than 1GB of RAM yet it still finished the panorama under 12 minutes.

This assumes that Autopano Giga and ptgui are doing the same calculations.
You may well be right, I don't know.
I'm just saying that you have to be sure that you have eliminated all
other possiblities before you can say some thing for certain.
regards

mick

[Greg Takacs]

> This assumes that Autopano Giga and ptgui are doing the same calculations.
> You may well be right, I don't know.

Actually I would bet money that Autopano Giga and PTGui are NOT doing
the same calculations. At the very least they're not doing it in the
same order. But that is exactly my point! I, even though am a software
engineer by profession, don't care how the application does the
blending as long as I get my final result. And looking at the final
render from Autopano Giga I can certainly say that I do get the result
I'm expecting.

Now try to throw some HDR or a nadir shot that requires viewpoint
correction onto Autopano Giga and you're up poop creek, but that is a
different discussion better suited for the Autopano forum....

[michael crane]

2009/9/15 Greg Takacs <gtaka...@gmail.com>:

you are trying to pressure Joost into working harder to make our lives easier ?

regards

mick

[Joergen Geerds]

well, I have to say that ptgui blending isn't actually the largest
portion of time spent on a pano. ptgui does some preblending while
warping (probably all the color correction and vignetting
adjustments), so the blending process is actually quite fast (in my
case, ptgui would spend 35min warping, and 5 min blending, which isn't
bad at all)... it is mostly the warping process where I see the
gigantic IO overhead, and the crawling "speed".

joergen

[Greg Takacs]

Joergen,

I assume you are talking about your own panoramas not the speed test
sample which probably does not do vignetting or exposure adjustments.
This is why it's very difficult to discuss/confirm issues/problems.
There are just way too many different requirements of final render
from gigapixel partial panoramas to 8 megapixel 360x180 running on
weak PCs with hardly any RAM and slow storage to multi cores with lots
of RAM and fast storage. However I think at this point all of these
would benefit from a I/O and memory management rewrite....

On my current setup I can actually render regular 50 megapixel 360x180
panos from 7 shot fisheyes pretty quickly (I'll have to report back
with actual numbers). Since I'm not into the gigapixel partials the
only reason I ran that test was to get a baseline for performance that
is actually comparable with other people's findings. That test is
pretty brutal to say the least but it certainly displays the
weaknesses of the app.

[Greg Takacs]

> you are trying to pressure Joost into working harder to make our lives easier ?

I was just looking for an acknowledgment of the problems and a promise
that it is actually on the table for improvement. Since Joost
acknowledged receipt of the bugs and they are currently under
investigation ( http://groups.google.com/group/ptgui/msg/25eb9f116df1a366
), my job is done for the interim. I'll be on the lookout for a new
and improved version once it becomes available.

[Joergen Geerds]

yes, of course I was talking about my current panos, I haven't done a
speed test with the official speed test version, but I will report
back when I am done with them. As I have mentioned, ptgui is insanely
fast for things <50MPx, decently fast for 50-100 mpx, but beyond 100
mpx ptgui starts to become unproportionally slow, at least for my
projects.

joergen