Re: PS memory/disk space bug: more info
- From: "Michael J. Mahon" <mjmahon@xxxxxxx>
- Date: Mon, 04 Aug 2008 11:41:22 -0700
spam2you wrote:
Michael J. Mahon schreef:spam2you wrote:spam2you schreef:Trying to generate a 1024x786 video (288 photo's).
I get the message:
'There is not enough memory or disk space to complete this operation... yada... yada...'.
Anyone has a workaround for this bug?
(Preferably one where I don't have to break up files.)
Note: this is not a problem that is in any way related to disk space or memory shortage. Plenty of memory and disk space (on all required disks!!) available.
Neither is it a PS install or WMP install problem.
Because when generating smaller files (< 100 photo's), everyting works fine.
Well, I've done some more tests and maybe I've found something.
I've created a new PS and imported all 200+ images that I want in the slideshow.
Next I update the project.xml: change all movements to manual movements.
Next I generate the wmv file, accepting all default movements.
To my surprise: this works!
Resulting in a 310MB wmv file.
The only difference between this succesfull PS file, and the one that failed before, is that on the old situation I updated the movement for *every* photo. So none of the photo's had movement that PS originally proposed.
In my opinion this should not make any difference.
What's the diff when I make a movement myself or when I accept the defaul movement PS proposes?
Any thoughts on this one?
I had a similar experience about a year ago, and chalked it up to
flakiness...
Apparently, PS3 treats user-specified transitions (starting and ending
positions) differently than its own, or perhaps it simply fails to
recover the space used by its original "suggestions".
To respond to PapaJohn's suggestion that it had to do with requiring
more space for the manual operations (because of more use of the
original photo, for example), most of my "touch ups" were simply to
the starting and ending positions, and my changes should have netted
out to the same or less of the original photos being used.
Photo Story 3 is clearly not designed for large projects, and does
not reclaim space or encode transitions in a particularly space-
efficient way. If it did, then it would simply save the photos,
the music, and the parameters of the transitions, which would be
tiny by comparison with the photos and music.
The "idea" behind Photo Story was to use the capabilities of modern
video cards to do the pans and zooms, so very little actual computation
would be required unless encoding the result as a .wmv file. This
makes it all the more curious that its intermediate file is the
apparent limitation to story complexity.
Maybe Photo Story 4 will do a better job with large projects...
-michael
I think you're right.
It's just disappointing that the software doesn't deliver, even when you use it well within it's limits.
One last thing though: what is this intermediate file?
The only thing I can find when PS is doing it's wmv magic, is a directory with a large number of jpegs.
That is my theory to explain the limits--signed 32-bit integer
byte pointers into a (max 2GB) temporary file holding all the
resources (photos, sounds, transitions) used by the story.
There are other possibilities--like using a 32-bit address space
to *map* all the resources used by the program, even though most of
them are actually in separate files (like the JPEGs you found).
-michael
"The wastebasket is our most important design
tool--and it's seriously underused."
.
- References:
- PS memory/disk space bug
- From: spam2you
- Re: PS memory/disk space bug: more info
- From: spam2you
- Re: PS memory/disk space bug: more info
- From: Michael J. Mahon
- Re: PS memory/disk space bug: more info
- From: spam2you
- PS memory/disk space bug
- Prev by Date: Re: PS memory/disk space bug
- Next by Date: Re: PS memory/disk space bug
- Previous by thread: Re: PS memory/disk space bug: more info
- Next by thread: Re: PS memory/disk space bug
- Index(es):
Relevant Pages
|
