logo
background
 Home and Links
 Your PC and Security
 Server NAS
 Wargames
 Astronomy
 PhotoStory
 DVD making
 Raspberry Pi
 PIC projects
 Other projects
 Next >>

Hacking the PhotoStory 3 .wp3 Project File

.wp3 hacking
Note. The Project file only defines the contents of your Story. The output is defined by a separate Profile (see my Output Profiles for PhotoStory page)

What's in the .wp3 Project File ?

Everything ! Unlike some applications (eg Windows Movie Maker, most Adobe apps), the Project File is a complete 'archive' containing all the source photo's, source narration and music files and all the 'story build' instructions (in a xml file). The disadvantage is that a .wp3 Project can easily exceed 1Gb .. however the overwhelming advantage is that none of your 'source' will ever get lost !

As a 'bonus', the .wp3 archive is a simple Microsoft '.cab' file = which can be 'unpacked' by numerous Open Source utilities (such as 7-zip), although re-packing is less easy (but see below)

Your photos are saved 'as imported' (i.e. un-cropped, in their original format i.e. .jpg, .bmp etc). So if you do select 'remove black borders' by mistake, 'hacking' the project.xml file (see later) will allow you to 'un-crop' without deleting and re-importing all your photos

Whilst the .wp3 contains all your original photos, the original file names are replaced with a sequential 'number' defined by the 'playing order' (eg 0.jpg, 1.jpg, 2.jpg etc. The original names can be found as 'comments' in the project.xml file on 'first save' but not thereafter.
 
The original photo creation dates are preserved, so, in theory, you could 'back track' to your own Photo Archive (although searching the creation dates of 100,000 photos could take a while unless you archive your photos in date order (like I do :-) )

Where is the 'open' Project File held ?

When you create a new project, 'everything' (build instructions and photo thumbnails) is initially 'held in RAM'. The same happens when you first 'Import' a photo (only a thumbnail is created and that is held with the rest of the project in RAM)

When you Preview or Save your project, all the photos etc. are assembled in the Windows /Temp folder. If this is the first time a new project is Previewed, this is the moment when the Temp folder is created.

When you open an existing project, PhotoStory 3 creates the temp folder (C:\Documents and Settings\(your user name)\Local Settings\Temp\{the PS3 project name}\) to hold the unpacked .wp3
 
The project.xml build instructions are then copied into RAM and the file .xml file deleted. Thumbnails are created and held in RAM, the original photos are left in the Temp folder

When you Preview, any 'newly imported' photos will have to be fetched from the source - and if you Imported from a drive or network 'share' that has since 'gone to sleep', PhotoStory 3 will crash

When you 'Save' your story ('Save Project'), all the photos are assembled in Temp and the build instructions are copied out of RAM into the 'project.xml' file

The whole Temp folder is then compressed using 'MSZip' format into a Microsoft '.cab' file structure and given the ".wp3" extension. The Temp folder is only deleted when you close PhotoStory

Can I get access to the Project files whilst it's 'open' ?

Yes, but only to the photos, music and narration files (not to the build instructions). Immediately after opening an existing .wp3 (and immediately after a 'Preview'), the Temp folder (C:\Documents and Settings\(your user name)\Local Settings\Temp\{the PS3 project title}\") will contain copies of all the photos, music and narration used in the Story

You can 'swap out' a photo (replacing it with one of exactly the same size) and the replacement will be 'picked up' OK when you next Preview or Save the project.This means you could create a 'template' for a generic 'type' of slide show (with titles, timing & music) - for example 'Holiday' - and then 'slot in' a new set of photos without loosing the existing text, timing & music (as would happen if you 'delete' the existing photos and 'import' new ones). You must (of course) remember to 'Save Project' before closing (PS3 won't ask you if you want to 'save' because it won't be aware you made any changes :-) )

The build instructions (.xml) are held in RAM (and copied out of RAM during the 'Save' process). Any version found in any Temp folder will be 'stale'. To 'get at' the build instructions, you have to 'unpack' the saved .wp3 project archive (see below)

Unpacking the .wp3 Project file

To 'extract' the contents of the .wp3 project file, use the Open Source '7-zip' utility. To repack, you will need the freeware 'CAB PACK' utility.

You will discover that all your original photo's have been 'saved' without being cropped (which means you can 'reset' the 'remove black bands' by 'hacking' the .xml).

If you want to process the project.xml using a script, be aware that it lacks 'end of line' characters.You can 'insert' these using Notepad++ (replace '>' with '>\r\n') or use a Hex edit tool. It is not necessary to remove the cr/lf later - PhotoStory 3 doesn't care what 'line ends' it finds in the project.xml file

What's in the project.xml ?

Everything that controls the 'story'. Each photo used is defined as a 'Visual Unit', containing all the transition timings, crop & zoom, Title text and music etc. etc.

Many parameters have default values that you may disagree with - for example, by default, the first photo (VU) in your 'story' will start by 'fading in' from with a blank (black) screen. Whilst this can be changed from the GUI, the GUI imposes limits that you may wish to exceed (for example, the 'Customize Motion' GUI will not allow you to set a transition time less than the photo display time).
 
Some things can not be changed - for example the 10 second 'auto fade out' of your music track at the end of your story

A 'typical' VisualUnit definition is shown below :-

<VisualUnit duration="5" type="1">
duration is the total time, in seconds, for this 'frame' of the story
<Transition duration="1.5" withPrevImage="-1" type="{829BBF89-7707-4567-A0B8-9BF9631C79AD}"/> <Transition duration="0.5" withPrevImage="0" type="{829BBF89-7707-4567-A0B8-9BF9631C79AD}"/>
All VisualUnits (except the last) have a pair of 'transition' entries (all have a Transition2 entry, see later). This helps us arrive at the following explanation :-Each photo (except the last) is (potentially) involved with two others = the previous and the next.
 
'withPrevImage="-1"' means 'with the previous unit' and is one half the transition2 duration time (i.e. set by this unit for it's transition with the previous unit, = see the 'Transition2' (below).
 
'withPrevImage="0"' means 'with the next' and is one half the transition time set by the NEXT unit (in it's own transition2) with this.
 
The 'type="{829BBF89-7707-4567-A0B8-9BF9631C79AD}"' entry appears to be constant = it does not change between the various fade 'types', which are defined by numeric value in the 'Transition2 type=""' field, below)
Note.
The first VisualUnit has no 'withPrevImage="-1"' but may still 'transition in' from a blank (black) frame as set by it's 'transition2' setting (the default this is a 1 second 'fade in' which can confuse other software, which may try to 'crop off' the black start)

The last VisualUnit has no 'withPrevImage="0"' entry, and there appears to be no way to 'fade out' the last photo (although the music DOES fade out ..)
<Narration path="narration0.wav"/>
Name assigned to the recorded narration (.wav) starting with this VisualUnit (if there is no narration starting here, this line is omitted)Note. The narration is held as a normal audio track (stereo, 44.1kHz, 1.411mbs, PCM).
<Image path="0.jpg" comments="OrigFileName.jpg" lastModified="1/20/2008 11:09:42 PM" width="945" height="753" noNarration="-1" useManualDuration="0" narrationTips="">
All photo's are given serial numbers, which are used as the file name when they are saved in /temp. When you first create and 'Save project', the original photo file names are saved in the 'comments =' field. On later edits & 'Save Project', the original file names are replaced by the serial numbers. The width and height are the photo size in pixelsuseManualDuration="-1" means your VisualUnit duration is fixed to the time you set. ="" means 'automatic' duration and PhotoStory may change it to 'accommodate' the pan/zoom and transition timing - if you change anything in 'Customize Motion', the display time will change'narrationTips' is whatever text you entered in the 'Narration Tips' box (it doesn't appear in the final 'story' wmv, so you can put whatever you like in this field = for example, 'codes' to control QBasic script processing of the VU (or the script' itself could use Tips to record a 'log' of changes)
<Edit> <TextOverlay text="1st photo " verticalAlignment="4" horizontalAlignment="1" fontReferenceWidth="320" fontReferenceHeight="240"> <Font faceName="MS Shell Dlg" width="0" height="-21" weight="400" strikeout="0" italic="0" underline="0" charset="0" clipprecision="0" escapement="0" orientation="0" outprecision="0" pitchandfamily="0" quality="0" color="0"/> </TextOverlay> </Edit>
The 'edit' section defines the 'sub-title' overlay text (in this case the characters "1st photo " will be 'written' over the image). The rest of the entry defines the display position, font details (size, colour) etc.
 
If no subtitle text is entered, the whole (edit .. /edit) section is omitted. See below for a definition of the 'color=' codesNote - if you pan / zoom the photo, the text stays behind, 'stuck' to the photo position where it was originally placed (i.e. it's 'burnt in' text, not sub-title text). For sub-titles (which 'stick' to the display screen position no matter how you pan/zoom the photo) use your DVD Author package
<Motion manual="-1" workingImageWidth="1004" workingImageHeight="753"> <Rect upperLeftX="0" upperLeftY="0" width="1004" height="753" weight="100"/> <Rect upperLeftX="0" upperLeftY="0" width="1004" height="753" weight="100"/> </Motion>
The 'Motion' entry defines the 'workingImageWidth' and '..Height' (= the fixed 4:3 window 'bounding box'**). The Rect values are the start and end crop box position and sizes. All pixel co-ordinates are measured from the top left (0,0) of the 'bounding box'**.
 
**The photo will be centred in the 4:3 'bounding box' = PhotoStory 3 adds 'black bands' at the sides (for portrait photo's) or at the top & bottom (for landscape photos). The only case of 'no black bands' is when the photo is an exact 4:3 aspect ratio fit (or when you allow it to 'remove black bands', in which case the photo is cropped to exactly fir the 4:3 window)Note that motion (panning and zooming) starts as soon as the VisualUnit starts, and ends with the Unit end. This means that the transition from the previous Vu will overlap with the start of the pan/zoom, and the end of the pan/zoom will overlap with the transition to the next VuPhotoStory 3 sets 'default' crop start and end positions ('Motion manual="0"') unless 'over-ridden' by the user ('Motion manual="-1"'). The crop box position is defined by it's top left corner (X = width posn, Y = height) and it's size (width= and height= ) in pixels.I've no idea what 'weight' means (I've only ever seen it set to 100)
<Motion2 manual="-1"> <RelativeRect left="0" top="0" width="1" height="1"/> <RelativeRect left="0" top="0" width="1" height="1"/> <RelativeRect left="0" top="0" width="1" height="1"/> <RelativeRect left="0" top="0" width="1" height="1"/> </Motion2>
These settings govern the actual 'movement' of the pan/zoom crop box across the photo frame area i.e. they 'over-ride' the first 'Motion' set .
 
As suggested by the name, the values are 'relative' to the 'bounding box' aka 'workingImageWidth'/ 'workingImageHeight' (they are held to 15 decimal places and will always be between 0 and 1).
 
The first is the crop box start position and size, the second the crop box end position and size.
 
The third and fourth entries are often identical to the first set however sometimes they have been seen 'similar to' but 'different from' the first (they could perhaps be 'auto' pan and zoom used when the 'manual' option is 'turned off' ??)
<Transition2 type="1" useManualDuration="-1" duration="3"/>
The 'Transition2' entry defines this photos transition with the PREVIOUS photo.
 
If 'type="0"', no transition occurs (you can expect 'useManualDuration="-1"', and any 'duration="?"' time setting will be ignored). 'type="1"' means cross-fade, 'type="24"' means scroll from left (there is a separate code for each of the other effects).
 
The transition time (duration) is 'automatic' when 'useManualDuration="0"' (and user configured when ="-1").For all but the first and last, the GUI** prevents you entering a 'duration' greater than the display time of the current photo (or 6 seconds, if less). The first & last photo transition times appear to be limited to half that photos display time, however sometimes the values allowed seem almost random.**If you enter a longer time, it is 'reset' when you 'save' the photo display time.
 
Note that the 'duration=""' value set here is the total transition time. One half is 'spent' at the end of the previous photo and one half at the start of this. This means that, to change the transition times using an automated 'script' (see below), you need to access both this Visual unit and the previous Vu
<MusicTrack type="1" volume="100" colorIndex="0"> {if type = "1" .. <SoundTrack comments="TitleOfMusicTrack.wav" path="SoundTrack0.wav"/> or if type = "2" .. <DMusic genre="All" style="AMADEUS.sty" band="Default" mood="NEWORLNS.CDM" intensity="1" tempo="97"/> } </MusicTrack>
If a music track starts with this Vu, it is referenced here. type="1" means a music file (.wav, .mp3 etc) has been added. type="2" means MIDI music has been selected.
 
The volume setting (100 = 100%) is applied during Preview and output and allows you to 'balance' the music with the narration (there is no playback volume setting for Narration, however you can set the volume during recording)
 
A music track is 'saved' in it's original format (so if you import .mp3 you will see 'path="SoundTrack0.mp3"' etc)Note that there is no 'end' reference - your music plays until the track is complete, or it is replaced (by new track, generated music or 'silence'). If no music starts here, the whole (MusicTrack .. /MusicTrack) section is omittedNote that the music 'time-line' displayed in the GUI is only 'correct' for CBR music tracks eg .wav 1411kbps (.mp3 and other VBR can lead to display errors of minutes)
</Image> </VisualUnit>
End of this VisualUnit definition (others follow)

What are the easiest parameters to change ?

The timing, i.e. 'VisualUnit duration' and 'Transition duration' (just make sure to split the new transition time between the two VisualUnits).

Be careful not to set new transitions times that 'overlap' = the sum of the start & end transitions must be no more than the total 'VisualUnit duration'.

It's also very easy to swap out the music track or just add additional tracks - there is no 'end of track' setting that needs to be found & 'adjusted'. A new track will start to play at the 'VisualUnit' it is referenced (and will play until finished or replaced by a track referenced in a later VisualUnit)

Can I replace the images ?

Yes - the simplest approach is to replace an image with one of exactly the same size.

Images are referenced by their sequence number (0.jpg, 1.jpg etc). The 'comments' and 'lastModified' fields can be ignored

If you replace an image with a different sized one, you need** to adjust the 'width=""' and 'height=""' in the 'Image path' setting, the 'workingImageWidth' & 'workingImageHeight' (a 4:3 'window' within which the image will be centred with 'black bands' at the sides or top & bottom depending on how it fits) and both 'Rect' settings. If the new photo as the same aspect ratio as the original, the 'Motion2' settings can be ignored (they are all expressed in 'fractions of the photo size')

** If you fail to 'reset' the widths & heights, PhotoStory 3 may still open the Project, however your 'start' and 'end' crops are likely now 'invalid'. If you then make changes to the start and end crop from within PhotoStory, chances are PhotoStory 3 will crash when you try to 'Save' the Project

Can I modify the crop / pan & zoom ?

Yes. In Motion manual, the first 'Rect' defines the crop box 'start' position (top left corner) and size, in pixels, X width by Y height. The second defines the end. All 4 corners of both the start and end crop box must be within the '4:3' window defined as the workingImageWidth x workingImageHeight (pixels)

Specifying a crop box that starts or ends outside the workingImageWidth x workingImageHeight is the most common reason why Photo Story refuses to open the modified wp3 with a 'Project is corrupt' error - or crashes later when you 'preview' or 'save' (and it 'spots' the invalid data)

You also have to adjust the Motion2, RelativeRect settings, otherwise they will 'override' the crop box

Do you have any 'tips' on image 'replacement' ?

Yes, for sure. MS PhotoStory 'output' quality depends very much on having 'sufficient' pixels for cropping at the 'zoom in' end. Ideally, you should start with as large an image 'as possible' .. and one way to improve the quality is to use a 'professional' algorithm to 'zoom up' your source images to the maximum (7,000 pixels in height or width). So if you have an 'old' Story you wish to 'enhance', one tip would be to re-size all the images to the maximum (and modify all the .xml image size related values to match - for example by using a 'QBasic' script = see below).

If your existing PhotoStory is 4:3 and you want a 16:9 widescreen (or a 16:9 HD version), you need to 'distort' the existing images by multiplying the height to 133%, so that, after PhotoStory uses it's fixed 3:4 aspect ratio 'crop' tool you end up with pixels that can be 'stretched' from 3:4 to 16:9. See my Converting 4:3 stories to 16:9 page (which references a QBasic script that will convert both the images and the .xml values)

Note that pan and zoom effects are governed by the 'Relative' position entries. Since you are not changing the relative positions (a crop that starts 'half way down' the old photo will still start 'half way down' the 133% adjusted photo) simple 'zooming' of photos won't require any complex calculations

WARNING. If you add a photo that's bigger than 7200 pixels width or height, PhotoStory 3 will typically 'complain' but then 'open' the project anyway. However, you will find that the 'offending' photo no longer appears in the story !! (and when you next 'save', the photo is lost)

It's quite possible to add an 'exact' 7200 pixel square photo. PhotoStory 3 will 'create' a 'bounding box' that is 4/3 = 9600 pixels wide x 7200 high to 'contain' it. It may even 'Preview' OK, however it will then often crash during output 'step 3'. I thus recommend you limit the height of your photo's to 7000 pixels (so the 4/3 bounding box is limited to 9333) = this seems to work 'OK'

Adding, removing and moving 'VisualUnits'

The playing order of the photos in the 'story' is the order in which they are defined as Visual Units in the project.xml. Visual Units are not 'serial numbered' - you can add, remove, re-order and 'copy & paste' Visual Units as you see fit

If you copy a Vu, you don't need to manually copy the existing photo - PhotoStory is happy to 'reference' the same photo twice (or more) and will make copies (and adjust the photo 'serial numbers') when the modified project file is next 'saved' (i.e. photo's are renumbered starting from '0' in the first VisualUnit and so on)

NOTE. When you move / remove / add VisualUnit, watch out for the 'half and half' Transition timings with the previous / next

Can I adjust the Transition timings ?

Yes. When the previous VisualUnit 'duration' time is comparable to this Vu's transition time, the transition can be really annoying as it 'fades out' the end of the previous Vu's pan/zoom and the start of this. Whilst you can 'compensate' by 'over zooming' the previous photo, the 'ideal' solution is to 'complete' the previous pan/zoom, do the transition on a static copy of the last photo PLUS a static copy of the next, and then start the next pan/zoom.

Occasionally this 'transition whilst pan and zooming' can actually result in a fancy looking visual effect. So 'do it static' may not always be the best approach. One way to stop a 'Transition Adjust' QBasic script from mucking up your clever visual effects would be to set 'flags' in the 'Narration tips' field (see at end of this page)

Of course you can 'import' another copy of both the previous and current photo and do this 'manually' - or, better, create a Transition Adjust script to do it for you !

The script examines each Visual Unit to look for a transition. If one is found, the PREVIOUS visual unit has to be adjusted by 'splitting off' a static copy of it's 'end' as well as creating a static copy of the start of this Vu along with the transition. After both 'static' elements have been inserted, the original visual unit is then saved without the transitionNote that, to maintain timing, the first original must have it's display time reduced by half the transition time (being the display time of the 'end' static copy) as does the second (i.e. the second has time is reduced by half the transition time = the same time as each of the static copies)

NB. you must set all the timings to 'manual' (otherwise PhotoStory 3 will 'overwrite' them when it next opens the .wp3). Further, PS3 doesn't 'like' transition times > display times, even on static photos, HOWEVER if you don't 'open' the image transition tab in the PS3 GUI, it won't try to adjust the timings (you can 'Preview' and 'Export' without opening any individual photo timing window)

Can I modify the Titles (overlay text) ?

Yes, however the 'Title' text is effectively 'burnt in' when the photo page ('Visual Unit') is 'started' - so any zoom / pan will quickly 'leave it behind' = so you might as well use your favourite photo-editing package to 'pre-title' your images instead - or (perhaps better) use your DVD authoring software to specify 'proper' sub-titles later.

Title text is defined in the project.xml as follow :-

<TextOverlay text="Example Text" verticalAlignment="8" horizontalAlignment="1" fontReferenceWidth="312" fontReferenceHeight="234">
<Font faceName="Microsoft Sans Serif" width="0" height="-21" weight="400" strikeout="0" italic="0" underline="0" charset="0" clipprecision="2" escapement="0" orientation="0" outprecision="3" pitchandfamily="34" quality="1" color="16777215" />
</TextOverlay>

You can use any 'Font' that exists on your computer. In PhotoStory, text is always defined as 'white' ('color="16777215"') however you can 'hand edit' the definition to change the font & colour etc.

Note that the 'color=' is a decimal value. Some other color values shown below ('how it works' makes more sense if you look at the 'hex' value (yes, it's Windows colour in 'BGR' order).

color (description) Color value B (hex) G (hex) R (hex)
Black 0 00 00 00
Sliver 12632256 C0 C0 C0
Maroon 128 00 00 80
Red 255 00 00 FF
Green 32768 00 80 00
Lime 65280 00 FF 00
Olive 32896 00 80 80
Yellow 65535 00 FF FF
Navy 8388608 80 00 00
Blue 16711680 FF 00 00
Purple 8388736 80 00 80
Fuchsia 16711935 FF 00 FF
Teal 8421376 80 80 00
Aqua 16776960 FF FF 00
Grey 8421504 80 80 80
White 16777215 FF FF FF

What about the 'narrationTips=' field ?

The text in 'narration tips' field does not form part of the final 'exported' .wmv - so you can 'save' there whatever text you like. One 'trick' would be to add 'processing instructions' for interpretation by a QBasic script - for example "don't zoom" or "don't split off the transition" ..

Repacking the project wp3 file

PhotoStory 3 will ignore any 'line end' codes inserted into the 'project.xml' file - so you can 'repack' the cab. without removing them

To repack you need software that can create MSZip format ".cab" files (which 7-Zip can not). One way to do this is to use the Freeware 'CabPack' utility - whilst released for NT4, this utility works just fine for me on XP Pro.

In case it can't be found, I host a copy here :- 'CAB PACK' utility (right click and Save As' to download).
 
Microsoft's own Cab. Pack utility, 'CABARC', is part of the Cab. SDK 'cabsdk.exe', however this is no longer available from the Microsoft web site (it might be found elsewhere, however with all such 'copies' you have to watch out for trojans, toots kits and virus infections)

Alternatively, there is the Shareware 'Total Commander' (if you rename your .wp3 to .wp_ then TC will automatically run when you double click on the Project.wp_ file).

PhotoStory can be quite 'forgiving' of changes made to it's .xml, however occasionally you will slip up and PhotoStory will respond with a 'Project file is corrupted' error'. So make sure to keep back-ups :-)

You can include whatever files you like in the wp3 'cabinet' archive (for example 'Copy of project.xml' as a back-up). PhotoStory 3 will ignore any file it doesn't need (of course, these files will be 'left behind' next time you use 'Save Project' :-) )

Optimising photos for output

To convert a 4:3 PhotoStory into 16:9 for wide-screen / HD display, the photos have to be 133% height pre-distorted. For a full explanation of why, see my Converting 4x3 to 16x9 page

At output time, the used (cropped) area of the original photo is extracted and used to create a series of 'sub-photos' at the required output size. Transition, pan and zoom instructions are then stored along with the sub-photos and used to 'morph' from one sub-photo to the next during playback.

This means that each sub-photo is reduced to the output video frame size - for example, if your output is DVD 768 x 576, each sub-photo will be 768x576.

The bigger your original photos, the more pixels PhotoStory 3 will have to create accurate sub-photos, so 'zooming up' before output can improve the quality.

If you simply 'zoom up' all the photo's to 7200 pixels you will end up with a massive Project file that takes ages to 'open' or 'save'. A practical limit would be 'twice the output size' (so, for DVD 768 x 576, zoom so the smallest 'crop box' is 1536 x 1152)
 
Of course, there is no point in 'zooming up' the whole photo when, chances are, up to half of each photo is not actually used (i.e. not part of the cropped, zoomed or panned area)So the first step is to 'cut out' the unused area, and the second is to 'zoom up' the used area to twice the output size

The first step is to work out the 'used area' of the photo, then work out the 'optimum' zoom factor. With these figures, the actual width and height of the final zoomed up area can be calculated, and if this is within the 7200 limit, the 'used area' can then be adjusted to better fit** PhotoStory 3's 4:3 display window

**There is no point in 'chopping off' areas of the photo that PhotoStory 3 will end up replacing with 'black bars' (when it displays the photo in the 4:3 'bounding box') - remember, unused area will not be part of the sub-photos at output time, so the display area can be whatever you like

If the final output is intended for 16:9 display, then the original photos have to be 'pre-distorted' (133% height adjusted) so PhotoStory can 'crop' them at 4:3 and get a 16:9 area. To avoid multiple interpolations degrading photo sharpness, the height distort should be performed at the same time as the 'zoom'

When calculating the display area (an 'adding back' original photo pixels), the 133% distort has to he taken into account

Output 'jitter'

If you make changes to the Project file, you might discover that your Story has gained unacceptable output 'jitter'. This is typically due to the changes made to the cropping positions or source photo sizes that means the 'Motion2' values are no longer correct

PhotoStory only recalculates Montion2 if you 'open' a photo in the GUI and change the 'crop box' positions or sizes.

1) Always recalculate the Motion2 (RelRect) values if you make position changes. Note this also applies if you pre-distort for 16:9 (this is so vital that I have created a QBasic script that does nothing but recalculate the RelRect values - see my QBasic scripts page, next)

Jitter can also sometimes be seen at high output resolutions

2) ONLY BUILD AT 30 fps. PhotoStory 3 output is a series of 'key frames' with 'morphing' instructions that controls the play back from one key-frame to the next. The fps has ZERO effect on later conversion (because the conversion fps is used, not the build fps).

The PhotoStory 3 'build' is plainly optimised for 30fps playback = the further away from 30fps the worse the 'jitter'. The cause is believed to be inaccuracies in 'morphing' from one sub-photo to the next that only really show up when 30fps is not used.

Whilst zooming up the photo should allow 'more accurate' sub-photos to be generated, it can do nothing to prevent 'jitter' due to morphing inaccuracies. The only thing that seems to help is to reduce the rate at which the frames are changing (i.e. the pan and zoom 'speed' in pixels moved per second).

If jitter is noticeable at 30fps (typically, only for higher resolution output e.g. 1440 x 1080, for AVCHD), one 'solution' is to halve the panning and zooming speed by doubling all the photo display times (and all the transition times) prior to output from PhotoStory
 
The 'half speed' story can then be converted (eg. into AVI), after which the speed can be 'doubled up' again (of course the audio from PhotoStory has to be stripped off and replaced after the video speed is 'doubled')
 
If AVI is used, one way to 'double up' the speed again is to use the AVI Frame Rate Changer utility. If you built a 'half speed' Story (at niminal 30fps) and convereted that to AVI (at 25fps), select your .avi and set the new rate to '50 fps'
 
MediaInfo will show that the 'duration' has been halved (and the fps stays the same i.e. 25fps). Clever movie players (like VLC) will work out that they need to display 'every other frame' in order to hit the total duration (less clever players will just play the first half of the movie :-) )

The pages in this topic are :-


Next subject :- QBasic scripts - (for PhotoStory)

[top]