Building a jitter-free DVD
The only output format supported by MS PhotoStory 3 is the WMV-Image format "WVP2". This is not a 'movie' format - rather it is intended to support 'photo slide shows' using very LIMITED bandwidth. WVP2 generates an output file that consists of a series of photo 'key frames' with 'instructions' on how to 'morph' from one to the next.
Because PhotoStory thinks you are going to play back your movie on some 20 year old PC with an ancient Pentium 4 processor, it artificially limits the 'bandwidth' of the playabck (by setting 'morphoing' values that will result in frames being 'slipped' to 'maintain speed'). This is a fundamental flaw with the WVP2 format (in that it permits the file 'generation' codac to limit the output, rather than having the playabck impose the limit) that frequently result PhotoStory 3 generating files with 'jitter' that appears during playback
WVP2 is a type of .wmv format file. WMV supports Digital Rights Management ('DRM') which means it's virtually impossible to find 'public domain' information on the file format - which in turns makes it virtually impossible to 'hack' the WVP2 data to remove the playback limitations
I have spend many hours trying to overcome the 'jitter' found on my final (PAL) DVD 'productions'. So far the ONLY method I have found that ALWAYS works is as follows :-
First get a jitter free .wmv file from Photostory
In theory, the fps (frame rate) you set is only an 'instruction' to the playback application which determines the 'morpthing' speed. Indeed, the 'fps' setting seems to have virtually no effect on the WVP2 file size. However, in practice, the further you set the WVP2 from 30fps, the more 'jitter' you see in playback. Although Windows Movie Maker can 'convert' from a 30fps Photostory (to 25fps AVI), it always seems to add more jitter when doing so. So start by trying 25fps Photostory output and if that plays back with jitter go to 30fps (if the PhoitoStory 3 .wmv has jitter, there's really nothing you can do 'downstream' to fix it
1) The only way to 'guarantee' that PhotoStory will complete it's output without failing with 'insufficient memory' etc. complaints is to output directly after opening the project. So before trying to output, Save your work to a project.wp3 file and close the PhotoStory 3 application.
2) Output without music
When WVP2 imposes it's internal 'bandwidth limit', audio gets priority and image data gets whatever is left over. Some flaw in the 'encoder' then 'saves bandwidth' by instructing the playback app. to 'skip' which appears as 'jitter'.
To output without music :-
Double click your project to launch PhotoStory 3.
When it finishes 'opening' step through ('Next') to the 'Add background music' window, locate any slide containing a music track and remove (delete) that track.
DO NOT re-save the project after this step :-)
There is no point in wasting time letting PhotoStory add music to the output file anyway After all, you will replace the 2ch stereo with 5.1 surround sound later anyway, so don't waste time (or increase the chance of the 'build' failing) by letting Photostory add music to the output. Click 'Next' to the 'Save your story' window, make sure 'Save your story for playback on your computer' is highlighted, enter a file name and click 'Settings'. In the Settings window, select my 'Profile for creating DVDs - PAL (768x576)' (this profile uses the minimal possible audio bandwidth - PhotoStory 3 will not accept Profiles that are totally without audio) When the output is finished, click 'View your story' to make sure it plays back OK, then 'Exit' (or just 'X') to close Photostory = DO NOT SAVE the project (or you will save without the music track(s) !)2) Next convert the .wmv into DV-AVI 25fps PAL using Windows Movie Maker Version 5.1 (2.1.4028.0 aka 'Ver 2.1') for Windows XP
First, in the 'Tools', 'Options' menu, 'Advanced' window set the Video properties to 'PAL'.
This is what sets the DV-AVI output resolution (720x576) and fps (25).If you were working with 133% height-adjusted photos (to get 16:9 output after PhotoStory 4:3 crop), you should also set '16:9'. This sets a 'flag' in the AVI file that other applications SHOULD use to recognise 16:9 aspect ratio pixels and play back in 'widescreen' correctly. Don't count on it - DVD Flick, for example, will assume 1:1 pixels (and has to be forced to process each video clip as 16x9) DV-AVI is a 'built-in' profile and it's the ONLY way to get jitter free 25fps from PhotoStory 3 output. The key appears to be in forcing Movie Maker into generating each and every frame of the 25fps video - when you use a profile to get VC-1, no matter what other parameters you set, if you stick to 25fps Movie Maker always seems to introduce jitter (30fps is fine - but when your DVD 'author' app. processes that into 25fps, back comes the jitter)For Windows 7 users, getting hold of a version of Movie Maker that offers DV-AVI output is a real pain. Since it's not a Profile you can't just copy the settings across - and Microsoft removed AVI support from Movie Maker (ver 2.5) when they released Vista. However following complaints, MS 'upgraded' MM 2.5 to 'v2.6' which added back DV-AVI output. Needless to say, v2.6 is no longer hosted on the Microsoft web site
You are looking for 'MM26_ENU.msi', of 30 March 2007 23:46:55. The real version is 7,357,440 bytes = and other size and it's a virus / trojan / adware ridden fake. If you can't find it elsewhere, look on my Links pageCauses of jitter
Exhaustive experiments have shown that PhotoStory jitter is minimised at 30fps. So, for playback on a PC, ALWAYS use a 30fps output profile.
It is noted that the final mpeg from MM6 (Movie Maker 6) at 30fps had a larger 'bit-rate' than at 25fps. Since jitter appears to be due to 'artificial' restriction of the bit rate, this may be significant :- Same Story, 720x576 resolution :- 30fps = 6074 Kbps (variable), vid 5833 (no audio) = 183Mb file size, no jitter 25fps = 5730 Kbps (variable), vid 5503 (no audio) = 173Mb file size, jitter on pan/zoomJitter at high resolution (on high panning speeds) and high QVBR
At high resolution, jitter can become quite noticeable. Typically it's only seen at HD (1080h) resolutions (and above) on 'high speed' pan and zooms, especially when you output at anything other than 30fps.
At 100% QVBR quality, jitter starts to be seen on a pan/zoom 'faster' than about 3 seconds across more than 50% of the image and/or more than 50% zoom size change even at DVD resolutions (768x576) and at 30fps. Drop the QVBR by 2% and the jitter typically disappears !Jitter is only seen on movement, i.e. pan and zooms, and not transitions (fades) So what's happening ? Well, PhotoStory slide-show output format (WVP2) is not a movie = it does not consist of X frames per second = instead it's closer to a 'GIF'. The WVP2 generated file contains a series of 'key frames' (held at the output resolution), spaced at roughly 1 second intervals, with some sort of 'morphing' instructions that 'steps' the playback 'viewpoint' from one key-frame to the next. Whilst 'key frame' interval 'jumps' are also possible (at about 1 second intervals), movement jitter appears at some sub-second rates i.e. some small multiple of the output frame rate. This can only be due to incorrect morphing data genrated by PhotoStory itself as the jitter on playback is seen on very different PC's (so is not caused by slow CPU's failing to calculate video display frames fast enough) Further, experiments have shown that reducing the QVBR typically reduces the jitter (this is totally 'counter intuitive' since, with any other system, reducing the quality (i.e. the data rate) would INCREASE the jitter !!!). In other words, it's a fundamental problem with the WVP2 encoding process (and not due to playback problems, such as your CPU being too slow to keep up with the 'morphing' requirements or your hard drive being unable to deliver data fast enough - although Widows Media Player does seem to use /temp folder during playback which can result in jumps) Various tests have shown the following :- Jitter first appears at 100% QVBR (dropping QVBR to 98% often eliminates jitter first seen at 100%) The higher the output resolution, the higher the chances of jitter The 'faster' the pan/zoom i.e. the more 'pixels per second' crossed, the higher the chances of jitter The further your output is from 30fps, the more jitter you will see. Jumps are another matter. During playback, Windows Media player uses the /temp folder. When an application accesses the file system, for some insane reason Windows checks attached network 'shares' - if your network connection is 'down', player access is delayed and jumps can be seen in the playback. VLC doesn't do this (but can't handle 'fade' or other transitions)fps induced jitter ?
PhotoStory 3 'minimum' display time is 0.1s, and when output at 30 fps that is 3 frames (or 3 morphing 'steps'). However at other fps settings, 0.1s is often not an integer frame count - for example at 25fps 0.1s is 2.5 frames !
The problem is that any timing that ends on an 'odd 0.1' second - such as 0.5s - is effected. When 'morphing' at = to do 0.1s, after 2 frames the morphing has to skip a frame (so is 'late' by 0.1s) or output a complete frame (so is now 'early' by 0.1s). Assuming the morphing formula has some sort of 'averaging' effect, the video is now going to be 'jittering' by +/- 0.05s for the rest of the story. Indeed, experiments show that the further away you are from 30fps, the more noticeable high frequency small jitter becomes ! If you want to make PAL (25fps) DVD's, keep photo display times to 'even' 0.2 second intervals (for example, choose 4.6 seconds, NOT 4.5 !) - and always remember that the Transition time you specify is divided into 2 halves, so Transition times should be on a 0.4 second intervals (so 0.8 or 1.2 NOT 1 second (which will 'halve to .5')) To further minimise jitter, keep photo display times to 5 seconds (or more) and avoid 'fast' pan and zooms (pay attention to the 'suggested' i.e. automatic times = when PhotoStory suggests 10 or 20 seconds for your pan / zoom, there's a reason !) Finally, it is to be noted that increasing the image compression (i.e. reducing the QVBR setting from 100% to 98-95%) can significantly reduce if not ELIMINATE all jitter !WARNING - Incorrect Motion2 "RelativeRect" parameters are a proven source of jitter
Any time you 'hack' the project.xml and modify the photo sizes (eg. adjust your PhotoStory Project for 16:9) you MUST ensure the RelativeRect values are 100% correct
It turns out that PhotoStory does NOT recalculate "RelativeRect" values - even when you adjust the crop box positions in the GUI, all it does is 'incrementally modify' the values - and at 'output' time it just uses what-ever values it finds ! So, if the RelativeRect values for a photo pan/zoom are incorrect this can result in anything from major jitter and jumps to 'panning off the edge of the image area' (which usually results in the output being aborted)Since early versions of many of my '133% hight distortion' scripts didn't bother to (re)check the Rel Rect values, I now have an 'archive' full of 'slightly incorrect' projects. To fix this, I wrote a specific script to recalculate the Rel Rect values (it also moves transition timing to a 0.2 s 'boundary' (to avoid morphing step 'rounding errors' at 25fps, see above) and checks that the photo 'fits' exactly symmetrically within the 'bounding box' (i.e. if necessary, it crops the photo by 1 pixel to get an even pixel count in the padding dimension)
You can download REL-RECT.BAS hereTo check for jitter, always 'View your Story' after building it (before wasting any time with Movie Maker etc.)
Profile (.prx) settings
Although there are a number of output Profile settings that you might expect to have an effect on jitter, in fact (other than fps and, to a lesser extent, QVBR) they don't.
"Key Frame interval"
You might expect that the number of 'key frames' would have considerable effect on the output quality (generally, the more the better :-))
However the Profile "Key Frame interval" (tested from 0, in 0.2s steps to 10s then 10s steps to 100 seconds) and the "Buffer size" (tested from 5000 - 99999, starting with small steps then larger ones) in Profile settings have no effect what-so-ever. In every case the exact same PhotoStory 3 WVP2 output file size is generated, with no detectable effect on the quality or smoothness of playback. So it's a safe bet that these values are simply ignored by the WVP2 CodecPlayback fps
You might expect that the 'fps' (frames per second) setting would have a big effect on the output WPV2 file size, but (except in some extreme cases) this is not so. If you double the fps, this only adds a few bytes to the file size (so the 'key frame' count is plainly not determined by fps).
However, the further you get away from 30fps, the worse the playback jitter becomes !Whilst changing the fps may have no effect on the number of key frames generated, a setting of 30fps always delivers the 'smoothest' playback. Extensive tests show that jitter starts to be visible at 25 fps (or less) and also at about 37 fps (and more). At 70 fps (and above) or 15 fps (and lower) playback contains huge 'jumps' - or just delivers a 'black screen'.Rather oddly, a setting of 12.5fps led to a noticeable increase in output file size (which would suggest more 'key frames') but still suffered from a massive deterioration in output quality, with the same huge 'jumps' in the playback first seen at 15fps.
Since 30 fps gives the 'best' playback result, we might suspect that the WVP2 Codec is 'optimised' - or, more likely 'only ever been tested (and debugged)' for NTFS. I suspect that the 'key frame' positions are calculated on the assumption that the playback will be 30fps, so any other fps setting results in a playback sequence that always over- or under-shoots the next key frame. My conclusion is that the WVP2 Codec contains a key-frame 'position' bug that only becomes apparent at playback frame rates other than 30fps (i.e. when the timing results in non-integer frame rate generation) If you want 'jitter free' playback, only output from PhotoStory 3 at '30 fps' OR adjust all your timings to sit on 'integer fps boundaries' (so, for 25 fps that's 0.2s (5 steps), NOT 0.1s (which is 2.5 steps). The same applies whenever you use the WVP2 Codec - for example, when in Windows Movie Maker you convert from WVP2 to VC-1 / h264 (or some other format), you must choose 30fps output (or have adjusted all the timing = see below) If you adjust to 0.2s photo timing (with 0.4s transition) steps, you can usually get PAL DV-AVI at 25fps from Movie Maker with no jitter (except on very fast pan and zooms). If your DV-AVI shows unacceptable jitter (and it may well do so, for very fast pan and zooms), you really have no choice but to output 30fps in Microsoft VC-1 video .wmv format (at 30mbs, the maximum quality possible from WMM) and re-convert (to 25fps mpeg) before 'burning' the DVDSo the first step to minimising jitter is "always output from PhotoStory at 30fps"
I have adjusted all my own .prx Profiles to 30fps (I use the built-in profiles for PAL-DVD 25fps).Although the 'fps' setting in the PhotoStory output file is only used to determine the playback rate, during conversion to some other format - such as 25fps DV-AVI - the 'output' format fps will be used by the WVP2 Codec - and this can generate jitter. In practice, PAL DVD 25fps will be essentially jitter free (even on fast pan and zooms) so long as you adjust the display and transition timings for integer frame steps.
The problem is when the output fps setting you need has no 'integer time' approach - for example, for AVC HD we need 24.976 fps (actually, you can usually 'get away with' 25fps timing), however if you do get jitter you have no choice but to 'convert' using Movie Maker at 30fps (and maximum quality) and then allow the AVCHD author software 'recode' this into 24.976 fps Whilst this takes time, and the image quality will deteriorate a little (i.e. becomes 'smoother'), the result is jitter freeIncreasing the key frame count
Fast pan and zoom causes significantly more '1 second' jumps during playback, and halving the speed halves the 'size' of the jumps. So if we could double the key-frame count, that should have the same effect (i.e. halve the '1 second' jumps).
Whilst none of the .prx Profile settings make the slightest difference, there are two possible ways to increase the key-frame count :-
1) Increase all the timings before building the Story (eg reduce to half speed = double the length), then adjust the playback timing during conversion from WVP2 to something else (such as DV-AVI)
The problem is that none of the applications that 'understand' WVP2 are capable of changing the duration (timing) = i.e. can't take a 10min story and 'convert' it into a 5 min output. The 'best' you can attempt is to get Movie Maker etc. to output at 15fps and then 'hack' the .wmv to change the fps to 30 ..2) Chop each Story photo into multiple sub-components and assemble then as separate elements
Chopping 'works' because PhotoStory always generates at least 2 key-frames for each 'separate' photo. Since it normally generates key-frames at about 1 second intervals anyway, you have to 'chop' into 0.4 second components to double the effective key-frame count. The problem with 'chopping' is that it turns a 4s photo into 10 .4s components, and whilst this more than doubles the key-frames you will run into the 300 photo limit after only 120 seconds of the original story. So 'chopping' has to be 'clever' (i.e. only chop 'fast' pan/zooms)Double the timings
The PhotoStory 3 project (.wp3) file can be unpacked and 'hacked' using a QBasic script to increase all the timings. For the actual script, see my QBasic Scripts for PhotoStory page.
If Movie Maker is then used to generate .avi (for a DVD) the timings can be doubled because it's easy enough to speed up AVI by x2 using the AVI Frame Rate Changer utility**. This means a 25fps PAL AVI can be 'double speeded' to 50fps (with the result that the display time halves). Note that the speed of the Audio is NOT modified .. which means that the Audio / Video 'synchronisation' timing 'reverts' to what it was before you hacked the project.xml (i.e. exactly what you want) If Media Encoder is used (for HD), the timing can be adjusted by up to x2.5 (Media Encoder lets you slow down the 'incoming' WMV-Image speed by 2.5 times during conversion into VC-1 .wmv = see my Using Media Encoder (for AVCHD) page). For more extreme speed-up's using Windows Movie Maker, download Blaine's 'custom speed effects' (adds a set of 'Video effects' (up to x8 speed-up = the installer simply adds 'BlaineSpeedXP.xml' to C:\Program Files\Movie Maker\Shared\AddOnTFX where WMM will find it on next launch) If you are using some other package (eg MS Expressions Encoder on Windows 7), you will need to 'double speed' the VC-1 .wmv or the h.264 (I'm still looking at how to do this - doubling the fps in a Movie editor just generates a lot more movie frames (leaving the overall timing the same), although Avidemux (v2.6.x) looks like it may do the job).**You may be tempted to 'import' a 'doubled speed' .avi into Windows Movie Maker XP and re-output as DV/AVI again - needless to say, not only does WMM fail to 'recognise' the 'frame rate' setting (Preview will show it continues to play at half speed) but when you attempt to output it, the 'time remaining' simply clocks up to infinity :-) (after which is crashes when you try to 'Cancel')
Chopping up the project
Once you are happy with your Story timing but find that the output contains unacceptable jitter, the .wp2 project file can be unpacked and the project.xml chopped up to to force additional Key Frames to be generated. At the same time, the source photos can be 'sliced up' to optimise the number of pixels and the timing can be adjusted to ensure Key Frames fall on 'integer' morphing step positions.
At 25fps, each Key Frame should be on a multiple of 0.2s, however for 23.976 fps (AVCHD) we have a problem. 0.1s is 2.9376 frames .. 1.5s is 44.064 frames and the 'closest' we get to an integer count is at 1.6s = 47.0016 frames (which may be close enough but makes chopping rather 'coarse'). So, for AVCHD, I 'slice' the Story to the 0.4s step timing and then output using a 30fps Profile (which should preserve the timing). I then output from Movie Maker with a 23.976 fps Profile, and this seems to work 'reasonably well'Reducing the chop countTo avoid creating too many sub-components and running into the 300 photo limit, only 'fast' pan and zooms should be chopped into individual 0.4s components - slower parts of the Story should be chopped into larger chunks.
Of course, if you manipulate the project.xml in a way that changes the photo size (and thus the workingImageWidth / Height aka the 'bounding box') or the 'crop' (<Rect) start/end settings in any way, it is VITAL that you recalculate the '<RelativeRect' values (PhotoStory won't do it for you, and setting them to '0' (default) will result in 'corrupted project file' complaints) The '<RelativeRect' parameters control the pan and zoom 'stepping' and are held to an accuracy of 15 significant digits (so, must be 64 bit floating point format), which should be 'more than good enough'The goal is to slice up the photo in a way that optimises the quality whilst minimising jitter. This means chopping the overall display time into a series of shorter timed slices and then cropping and re-sizing the 'source' photo for each slice
Plainly the start (and end) of a pan/zoom can only be on some specific (integer) pixel (as must be the cropped size). However the '<RelativeRect' values, when multiplied by the workingImageWidth / Height, may not 'land' on a specific (start) pixel. Whilst the '<RelativeRect' values can be adjusted to ensure an integer 'start' (and 'size'), as each successive movie frame is generated, it's inevitable that the floating point position (and zoom size) will have to be rounded to the 'nearest pixel'. Further, remember that PhotoStory will 'pad' a non-4:3 aspect ratio photo with top/bottom or side 'bars' to create the 'bounding box' = which is fine until you realise that any photo with an odd pixel height/width count can't possibly result in equal sized 'bars'. So, to stop PhotoStory 'padding' to the 'workingImageWidth / Height', you must pad each photo 'slice' to an exact 4:3 size ratio yourself. This will mean that the '<RelativeRect' will be relative to the photo dimensions (and not the bounding box which might be +/- 1 pixel different to what you are expecting) Finally, to minimise the possibility of jitter, the photo 'source' for each 'slice' will need to be optimally cropped and sized so that only 'just enough' (or 'just twice enough') pixels are provided for any 'pan and zoom' performed on that slice. To avoid PhotoStory 'interpolating-up', the photo 'slice' has to be sized so that the smaller of the two start/end 'crop boxes' is at least as large as the output resolution. In other words, if we are aiming to output 1920x1080 from PhotoStory, the smaller crop box must be at least 1920x1080 (and the other larger), which thus determines the interpolation factor.The QBasic 'slicer'
Goals
The 'slicer' has to optimise (crop, rescale) for the final output resolution, so my 'first version' was aimed at 768x576 (= pre-DVD output, i.e. before the width 'squeezing' (into 720x576) is performed by Windows Movie Maker DV-AVI output)
Jitter is due to movie frame 'crop' position (and size) errors that 'build up' to the point where movie frames are being taken from the 'wrong' pixel locations within the source photos The goal is thus to minimise or prevent such errors by pre-processing the project.xml (and source photos) such that when 25fps movie frames are generated they will be taken from exact (integer pixel) locations - or at least adjust the parameters so that 'fractional pixel errors' won't build up to the point of selecting incorrect pixels. This is achieved by chopping each photo into multiple sub-components. By setting 'short' timings, ensuring 'integer' start (and end) positions and crop and size optimising each 'slice' of the source photo, I hope to prevent playback errors building up and thus eliminate jitter.How it's done
PhotoStory supports a maximum of 300 photos. Fortunately, the Story 'count' is held at the start of the project.xml, so it's possible to work out how many extra 'slices' we can add before processing the first photo ('Visual Unit')
A typical Story might be 50-60 photos with an 'average' time of 4 seconds each for a total time of about 3.5 to 4 minutes (i.e. the length of a typical 'pop' music track) First the start and end 'half' Transition slices have to be 'extracted', so that would be 2 per photo = 120 slices (typically at 0.6 each) for 60 photos. This leaves 3 slices to be 'spread over' the remaining 4-1.2 = 2.8 seconds, giving us a 'slice' time of between 0.8 and 1.2 seconds (at 25fps, that's 20-30 frames)PhotoStory itself will insert key-frames at 1 second intervals. By choosing 0.8s as our 'sub-component' time we can prevent PhotoStory adding it's own key-frames
All timings (for 25fps) have to be 'divisible by 0.2s'. So the first step is to adjust the total time for the current photo to a 0.2s boundary. This means adding 0 or 0.1s to the total timeTo prevent an increase in the overall story timing, if 0.1s is added to one photo, 0.1s will be subtracted from the next 9b before checking for 0.2s divide)
Photos that are not exact 4:3 aspect ratio are 'padded' by PhotoStory to a 4:3 'bounding box', given by the workingImageWidth / Height. The 'relative' position of the pan/zoom 'crop boxes' is then calculated based on the 'bounding box' and NOT the actual image itself
To prevent 'bounding box' errors, we will pad the 'source' image itself, by adding black pixels, so the image is padded to an exact 4:3 ratio
Note, that this means the width is exactly divisible by 4 and the height is exactly 3*width/4.
This will be done using ImageMagick 'convert' utility, with the -extent command (to add 'odd pixels' to the right and/or bottom) to 'centralise' the image, and the -border command (to add black space to the sides or top/bottom) to add the 'box'.
The 'convert' utility command is built as follows :-
First the {source} image is specified, then the -background colour (-background Black) and -extent is then invoked to adjust the right-hand wide and/or bottom so image will fit exactly withing the 4:3 box
Next -bordercolor is set (-bordercolor Black) then -border invoked to add N pixels to either both sides (N x 0) or both the top/bottom (0 x N). Finally the output file is specified.
Although the -extent command (with -gravity center) could be used to position the image into the center of the bounding box area, if we get our size 'wrong' (and end up on non-integer pixel counts) ImageMagick will calculate the center position to the 'nearest' pixel. To avoid any possibility of 'non-integer' approximations, -border (which adds an integer pixel count) is used
Of course, the larger the image pixel count, the 'bigger the steps' between output frames. Further, the more image pixes exist, the more 'scope' for 'getting it wrong' :-)
Each 'slice' taken from the source image will consist of the minimum 'necessary' (i.e. used) image pixels. This means adding the padding first (so the source is an exact 4:£), and then cropping and resizing the original 'source' photo for each individual 'slice' (which will also be an exact 4:3) Maintaining 4:3 ratios is quite easy if only one of the two dimensions is actually calculated. If width, then it's adjusted to the nearest exact 'divide by 4', if height, then nearest 'divide by 3'. The other dimension is then set to 3* width/4 (or 4* height/3) The slicer will, of course, always go back to the (padded) 'source' for each new slice.
The 'padding' subroutine
This 'just' adds black pixels to the source image, so it 'exactly' matches the WorkingImageWidth wiW% (and Height)
The bounding box must be EXACTLY 4:3. This means it's width must be exactly divisible by 4 and the height = width/4 *3. The image then has to be fitted to the bounding box by adding equal pixel counts to the top/bottom or to each side.
' the source image is vuName$ and size is vuW% and vuH%
' the source bounding box is workW% x workH%
' output image size == output bounding box == bboxW% x bboxH%
'
' adjust bbox width so it's divisible by 4
adjW% = workW% MOD 4
bboxW% = workW% + adjW%
' calc. the exact height
bboxH% = (bboxW% / 4) * 3
' we now have an exact 4:3 bounding box, but may need to pad the image to fit centrally within it
padW%= bboxW% - vuW%
padH%= bboxH% - vuH%
borderW% = 0
borderH% = 0
' 3 cases - width is bbox, height is bbox, no bbox (just pad)
IF padH% < 3
' pad H, border W
padW% = padW% MOD 2
borderW% = padW%/2
ELSEIF padW% < 4
' pad W, border H
padH% = padH% MOD 2
borderH% = padH%/2
END IF
' (else just pad both)
'
' do the convert (note, convert reads whole i/p before writing o/p, so can write back to source file)
'
convert vuName$ -background Black -extent {vuW%+padW% x vuH%+padH%} -bordercolor Black -border borderW% x borderH% vuName$
The 'image slice' subroutine
The slice subroutine crops only the used pixels and then re-sizes so that the smaller of the 'start' or 'end' crop box will 'cut' an exact 768x576 pixels.
This is achieved using the ImageMagick 'convert' utility with the -adaptive-resize command and an implicit pre-crop (convert {source.jpg} [Wd x Ht + Xoff + Yoff ] -adaptive-resize outW x outH {dest.jpg} )
To improve quality, the 'exact 768x576 pixels' can be doubled (i.e. 1536x1152), however this will also double the 'speed' of the pan/zoom, and could thus introduce (more) jitter.
The 'obvious' trick is the check the pan/zoom 'speed' and only double the image when the speed suggests it is 'safe' to do so. Unfortunately, there is no obvious way to determine what is a 'safe' speed :-)
Since this will have to be determined by 'trial and error', 'safespeed' is defined as a user adjustable constant
To avoid all that annoying 'parameter passing' and 'global variable' nonsense, 'GOSUB' (and RETURN) can be used (rather than CALL)
islice:
' arrive here to generate one image slice, iSlice$, of minimum width = minW% (768 or 2x768, depending on safespeed#)
' the source crop boxes are defined by position (X, Y) and size (H, W) for start (s) and end (e) i.e. sX% x sY%, sW% x sH% (and eX% etc)
' the source image is vuName$ and size is bboxW% and bboxH%
' the source duration is vuTime, this slice starts at isTime and it's duration isD (the source RelativeRect values are ignored).
'
' on RETURN
' the iSlice size (and bounding box) = iW% (iH% == iW%/4 x 3)
' the iSlice start and end crop boxes = isX% x isY%, isW% x isH% (and ieX% etc)
' the RelativeRect values will be set, for start (s) and end (e) crop positions (isrX#, isrY#, isrW#, isrH# and ierX# etc)
' Option: if speed < safespeed# then minW% will be doubled
'
' calculate the slice start and end crop position (CINT rounds to nearest integer)
isX% = sX% + CINT(isTime * (eX% - sX%) / vuTime)
' (and so on)
' calculate the slice start and end crop size
isW% = sW% + CINT(isTime * (eW% - sW%) / vuTime)
' (and so on)
'
If all else fails
1) Try building your Story at a 'lower resolution' and then 'interpolate up' prior to building the DVD
Jitter is most often found when trying to output at 1920x1080 or above - so try using the 4:3 (1440x1080) profile and 'expand up' to 16:9 using Media Encoder. If there is still too much jitter, the next 'step' is to drop to 'half HD' (16:9 960x540 or 4:3 720x540).
2) In a typical Story, chances are there will only be one or two 'pan and zooms' that are so fast as to cause 'jitter' on playback. This means you could remove the one or two 'offending' pan and zooms and build them separately from the rest of the Story at HD.
Each 'offending' pan and zoom will mean splitting the Story at that point. You will also have to insert a 'static' copy of the photo for each transition effect). The 'offending' pan and zoom can then be built at lower resolution using PhotoStory, or by using some other application (such as PhotoFilmStrip)
End rant
All this 'mucking around' to get decent quality out of a 12 year old Microsoft throw-away app. might seem pointless .. however finding a 'modern day' alternative that will 'do the job' is next to impossible
Many well known applications (such as Adobe 'Premier' Elements and Microsoft 'Live' Movie Maker) that claim to support 'pan and zoom' (aka the 'Ken Burns effect') have been 'dumbed down' to remove any manual positioning and offer the "children's choice" of pre-defined start and end points (usually with a limited choice of timing as well) Then there are the applications such as Ashampoo Slideshow Studio 2013 (free edition) where you can position the start and end pan and zoom 'crop boxes' but will enforce a single timed transition (and also offers a limited choice of one output (wmv), lets you choose 100% quality and then generates VC-1 at the 'joke' resolution of 704x384) HOWEVER Ashampoo does at least use XML as it's Project File ('.sedprj') format (so you can 'hack' it by hand - of which more below) Finally, applications such as PhotoFilmStrip that do support fully customisable pan and zoom are also typically limited to a few fixed output resolutions (PhotoFilmStrip does support 'full HD' = 1920x1080, however, in common with many other apps., it is restricts the output fps to 'PAL' (25 fps) or 'NTSC' only i.e. does not support the 23.976fps required for AVCHD or real BD HD), however again the Project format can be 'hacked' (it's based on a SQL-lite database structure). It actually turns out that PhotoFilmStrip can be used to generate decent quality HD = see my using PhotoFilmStrip page
Most people have moved on from photos to video - even DSLR camera's now incorporate a video mode - so the chances of any new Open Source 'photo story' application becoming available is minimal. About the only way I will ever get the functionality and 'ease of use' I want is to write the (front end) software myself (and use something like PhotoFilmStrip to output my Project Files). Unfortunately this is not a simple task, so I've been avoiding it for years (and finding ways to 'patch up' PhotoStory instead :-) ).