Prev: Error from task scheduler
Next: Synctoy (2.0) not yet synchronized?
From: spam2you on 3 Aug 2008 18:26
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?
From: PapaJohn on 3 Aug 2008 20:32
I think the specific choices of movements.... starting to ending
positions.... makes major differences in memory needed to save the strory.

Tight zooms of large pix need more than wide-angle zooms.
--
website references are to www.papajohn.org

PapaJohn (MVP)


"spam2you" <spam2you(a)home.com> wrote in message
news:48963086$0$49845$e4fe514c(a)news.xs4all.nl...
> 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?


From: Michael J. Mahon on 3 Aug 2008 21:35
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

"The wastebasket is our most important design
tool--and it's seriously underused."
From: spam2you on 4 Aug 2008 05:41
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.
From: Michael J. Mahon on 4 Aug 2008 14:41
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."
 | 
Pages: 1
Prev: Error from task scheduler
Next: Synctoy (2.0) not yet synchronized?