<code>Tests with a series of different 'source' images and various total Story length settings revealed the following :-

1) WVP2 file size increases for each extra integer 'second' a photo is displayed

<i>From this I concluded that one key frame is added for each complete second of output</i>

2) To within a few bytes, the original source image compression (tested with BMP, x4, x8 and x16 JPG compressed) has no effect on the 'additional' output file size increase per second

<i>Since all source images are being re-compressed by PhotoStory (to it's own internal format) this might be expected.

However it was noted that the 'starting size' of the WVP2 output differed by up to 10% (which suggests that at least some of the detail in the source  images is being 'passed on')</i>

3) When a test Story was built with a single photo and no pan & zoom, the WVP2 file increased by a fixed amount for each extra second the photo was displayed (for a 1600x1200 output, that was 335,755 bytes). When a simple pan and zoonm was added, the same file increase per second was seen.

<i>This confirms that the WVP2 file size is not effected by pan and zoom, since all key frames are being cropped and scaled to the output resolution

However I noted that whilst the output file increases 'per second', the sub-photos being built in the temp folder (C:\Documents and Settings\{your user name}\Local Settings\Temp\PhotoStorySession0) are more varied. Specifically, on a 'pan and zoom' sub-photos are found at 1, 2, 3 or even 4 per second rate, and when no pan/zoom is defined only a single sub-photo is generated (irrespective of the display time).</i>

4) The 'longer and further' the pan/zoom, the higher the sub-photo rate.

<i>For example, a tight 3s pan had 2 sub-photos (a start and end), a short 4s had 4, whilst a wider pan had 7 and an extreme zoom out and pan had 12.

A series of 5s pans of 'different distance' had different subframe counts. The shortest 3, one 4, one 6, another 9, one 11 and one wide pan and zoom had 21 !

Finally, one very wide 8s pan and zoom had 27 sub photos !</i>
</code>

<p>However, <b>despite the temp files generated</b> the final WVP2 output file size is 'the same' (to within a few bytes) for each case, i.e. irrespective of the pan and zoom 'distance'</p>

<pre>Plainly the /temp sub-photos are not 'carried forward' into the WVP2 output.</pre>

<p>The only thing that seems to effect the WVP2 is the timing of each photo, with each extra second resulting in a 'step' to the WVP2 file size.</p>


<p>To investigate the link between Story pan and zoom timing and number of 'key frames' generated, a 'test' Story was built with a short photo display time (approx 3s each) and then rebuilt with the times doubled (6s per photo, so the Story run time doubled) and then doubled again (12s per photo, 4 times longer than the first).</p>

<pre>Each increase in display time led to less jitter in the playback, confirming the above (i.e. the faster pan and zoom, the worse the 'glitches')

This pointed at a possible 'solution' to the playback jitter and glitches that plague WVP2 at 'high' (HD) output resolutions

We can slow down each photo display time before generating the WVP2 output (thus forcing more sub-photos to be 'saved').

Windows Movie Maker will convert the WVP2 into a higther quality .avi / .wmv, which will then have to be speeded up during conversion into mpeg / h264.
</pre>

<p>It was noted above that the size of the WVP2 file 'stepped' on the integer photo display time in seconds. The first step was at 1.0s, the next at 2.0s (and so on).<br>
<br>
To investigate further, a Story was built with a single photo and then rebuilt with 4 identical copies of that photo, each shown for 1/4 of the original time (so the total story time remained constant). The resulting WVP2 was more than twice the size !</p>

<pre>It was noted that the minimum photo display time is 0.1s.

So the same photo was imported 10 times and each set to display 0.1s each.

The total file size was about 8x the size of a single photo shown for 1s, i.e. about the same size as the WVP2 generated for a single photo shown for 32s !

This points to a second method of increasing the key-frames - 'chop down' the photo into multiple (0.1s) steps !

The 'problem' is (of course) that you can't 'chop down' that part of the photo taking part in a 'transition'. When a photo 'starts with a transition', the default 1 second transition actually starts 0.5s into the previous photo and continues for 0.5s into this one - so both the previous and this photo must have a minimium display time of 0.5s

However, even if you 'chop down' a 5s photo into 10x 0.5s, the file size is still more than 4x the single 5s photo file (which suggests more than 4x the key frames) and equivelant to a single photo of approx 36s (so equivalent to a 'slow down' of about 7 times).

NOTE that if you 'open' the settings (using 'Customise Motion') of a 'chopped down' photo set to 0.5s display time with a 1s transition time (and no transition in the next 0.5s photo) PhotoStory 3 GUI will still try to force the display time to 1s (there's a bug in the GUI that won't allow a single photo display time less than it's 'own' transition time - the actual limit is, of course, half it's own transition time (with the previous photo) plus half that of the next (with this)). If you avoid 'opening' the photo however, the values you set in the Project .xml will be acted upon during the build
</pre>