 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ABX wrote:
> On Fri, 16 Aug 2002 11:39:49 +0200, Le Forgeron <jgr### [at] free fr> wrote:
>
>>Interesting concept: extracting a frame of a movie,
>>
>
> I'm happy that first response is not completly agains ... :-)
>
>
>>but I wonder if it would not be better to have the timeline as the time
>>elapsed since the beginning of the movie.
>>
>
> There is nothing difficoult to use Interpolate macro or range function to move
> cursor from [0..1] to real time I think.
It's not difficult, BUT then, you have to exactly know the whole length
of the animation and put that knowledge in the script.
Why put the burden on the user when the code could do it.
> I think idea of 0..1 is simliar to
> putting images in <0,0>..<1,1> region even if images has some resolution,
> placing, dimensions already written in it format.
I'm not sure that the similiraty could hold for time as it can for
spatial dimension. It's nice to be able to give the position in a
picture by using percentage. Even if the resolution of the picture
changes, the same element would still be there.
For movies, I'm afraid the resolution will not changed, but instead,
most of the time, the duration of the movie will be extended (see all
the DVD with Director'/Cameraman'/Script'/Producer'/Janitor's cuts, it's
always the same movie with some additional scenes. I would find it
easier to have a timeline which state in plain the time, with a comment
which gives the expected scene such as:
timeline 0:13:30 // Luke Skywalker enters his room with R2D2
(Ok, format of timeline is hard for the parser, but that's another story)
This way, whenever instead of SW-EP4v1(1978), someone want to use
SW-EP4v2(198x) or even SW-EP4v3(199y) (until we get SW-EP4v4(20xx),
all he has to do is, using any player, to find that same scene, probably
around the original 0:13:30 .
With interpolate, he would have to guess the length of MY version in
order to guess the time of the original, then perform also a precise
measure of the full movie length (I have some DVD which have the bad
authoring Idea of having absolutly NO time code information, which means
that you cannot jump back twenty minutes after the start [because you
previously look these twenty minutes two day before], the only way is
fast-forward... BTW, the player cannot tell you it's twenty minutes
away, you have to use the wall-clock!).
Side note: beware about the numbering scheme for frames inside a
seconds, the usage in video software is to number each frame
continiously from the first up (tagged 0) to the rate (tagged rate -1),
Thus there is 'rate' frames between 1:12:34 and 1:12:35, and they are
1:12:34.0, 1:12:34.1, 1:12:34.2, and so on.
The strange thing is that on a xx fps movie, the next after 1:12:34.xx-1
is 1:12:35.0 (and not 1:12:34.xx)
Also, there is some fun with the NTSC setting (29,97 is real fun, best
to considere it at 30 anyway, just droping a frame sometime to keep the
sound in sync). Also pull-down (24 fps in 30 fps) is an interesting
perversion.
> I think it should be easy to
> get specified moment of movie by writing in sdl:
>
> #macro Time(Hours,Minutes,Seconds,S100)
> (((Hours*60+Minutes)*60+Seconds)*100+S100)
> #end
>
So far so good, but why limit the resolution to 1/100th of second.
#macro Time(Hours, Minutes, Seconds, Fraction)
(((Hours*60+Minutes)*60+Seconds+Fraction)
#end
With Fraction between 0 and 1.
> image_map{
> mpeg "movie.mpg"
> timeline Time(2,30,46,23)/Time(3,20,21,10)
> }
>
That's the part I do not like, having to know and code the total length
of the movie.
> Making timeline dependant on clock and using motion_blur (I hope it will be
> patched to 3.5) would made movie playing very smooth.
>
>
>>the beginning of the files might not be at timecode 0.
>>
>
> IIRC GIF format can have written position of image. Is it considered when gif
> is loaded as image_map?
>
Gif support has been removed from 3.5, so that's irrelevant!
But I believe that only the first picture only was decoded...
I do not know, you will have to get the code of 3.1
Was partial image and animation part of the 87a Gif format ? or did they
come later with the next Gif format format ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:3D5### [at] freefr Le Forgeron wrote:
> Gif support has been removed from 3.5, so that's irrelevant!
>
6.7.1.5.1 Specifying an Image Map
The syntax for an image_map is:
...
BITMAP_TYPE:
gif | ......
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 16 Aug 2002 14:34:21 +0200, Le Forgeron <jgr### [at] freefr> wrote:
> > IIRC GIF format can have written position of image. Is it considered when gif
> > is loaded as image_map?
>
> Gif support has been removed from 3.5, so that's irrelevant!
Are you sure ? Have you readed 6.7.1.5.1 ?
BITMAP_TYPE:
gif | tga | iff | ppm | pgm | png | jpeg | tiff | sys
> But I believe that only the first picture only was decoded...
I don't mean frame but position on screen.
BTW: there is also my another further patch plan similiar to this mpeg port.
The same feature with sys_anim type of image map where sys_anim means native
animation gate for platform. This could also open gate for avi, divx,
quicktime, real etc.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo wrote:
> in news:3D5### [at] freefr Le Forgeron wrote:
>
>
>>Gif support has been removed from 3.5, so that's irrelevant!
>>
>>
>
> 6.7.1.5.1 Specifying an Image Map
> The syntax for an image_map is:
> ...
> BITMAP_TYPE:
> gif | ......
Ok, my fault... it was removed from Megapov for legal reason, and I did
not know that the povteam was now outlaw enough to keep the gif code in.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ABX wrote:
> On Fri, 16 Aug 2002 14:34:21 +0200, Le Forgeron <jgr### [at] freefr> wrote:
>>But I believe that only the first picture only was decoded...
>>
>
> I don't mean frame but position on screen.
>
It does not change the problem. Gif is a blocky format.
You will have to read the code of pov for reading gif to know exactly.
I would assumed that there is a default colour (pixel/palette entry),
that the whole picture is always rectangular and that pixels that are
not recovered by an explicit block have that default values.
But that's just a guess, the answer lies in the source only.
> BTW: there is also my another further patch plan similiar to this mpeg port.
> The same feature with sys_anim type of image map where sys_anim means native
> animation gate for platform. This could also open gate for avi, divx,
> quicktime, real etc.
Where is the portability ?
Me think: first make the patch for Mpeg-1, and maybe Mpeg-2.
Then wait, or you might unburry some old propriatary format ?
(Anyone got an FLC or an FLI player ?)
And what is the sys format for windows ? BMP ? AVI ? AWF ? AVF ?
Codec: every month has a new one...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 16 Aug 2002 16:06:45 +0200, Le Forgeron <jgr### [at] freefr> wrote:
> > BTW: there is also my another further patch plan similiar to this mpeg port.
> > The same feature with sys_anim type of image map where sys_anim means native
> > animation gate for platform. This could also open gate for avi, divx,
> > quicktime, real etc.
>
> Where is the portability ?
Where is the portability of sys image format ?
> Me think: first make the patch for Mpeg-1, and maybe Mpeg-2.
That was my intention :-)
> Then wait, or you might unburry some old propriatary format ?
> (Anyone got an FLC or an FLI player ?)
I don't think there is a sense to implement those ancient formats.
> And what is the sys format for windows ? BMP ? AVI ? AWF ? AVF ?
Every if internal library can send it to platform codec and has an answer it
is recognized and can return content of frame.
> Codec: every month has a new one...
Well, my intention is not to break portability but to make live of animators
easier.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ABX wrote:
> On Fri, 16 Aug 2002 16:06:45 +0200, Le Forgeron <jgr### [at] freefr> wrote:
>
>>>BTW: there is also my another further patch plan similiar to this mpeg port.
>>>The same feature with sys_anim type of image map where sys_anim means native
>>>animation gate for platform. This could also open gate for avi, divx,
>>>quicktime, real etc.
>>>
>>Where is the portability ?
>>
>
> Where is the portability of sys image format ?
>
Nowhere, but I did not say that I like that fact.
It would be better to take profit of the portability and have a bmp
reader (Win sys) on Unix and Mac port, and reverse of course (thus being
able to use the same scene files whatever the system).
>
>>Me think: first make the patch for Mpeg-1, and maybe Mpeg-2.
>>
>
> That was my intention :-)
>
>
>>Then wait, or you might unburry some old propriatary format ?
>>(Anyone got an FLC or an FLI player ?)
>>
>
> I don't think there is a sense to implement those ancient formats.
>
<Drama on>
Ahhhhh... You're restricting my freedom....Ahhhhh....You're murdering
me... Ahhhhh.... I'm a victim of your decision, you owe me a fortune....
Where is my lawyer's email ?..... Ahhhhhh
<Drama off>
>
>>And what is the sys format for windows ? BMP ? AVI ? AWF ? AVF ?
>>
>
> Every if internal library can send it to platform codec and has an answer it
> is recognized and can return content of frame.
>
Do internal libraries have the same interface across platform ?
I do not think so.
I'm afraid you would be making a Windows loader with just "sys" name.
>
>>Codec: every month has a new one...
>>
>
> Well, my intention is not to break portability but to make live of animators
> easier.
When you start relying on system library, you somehow leave the path of
portability...
Problem with codec is that you never have the one needed to read the latest
email-movie...
The most efficient codec (compression point of view) is probably the one
which upload your uncompressed movie in a remote server and give you an
url (obfuscated, of course, we're making money here!) to have it back.
This way, you get to compress a 2Go files in a 2048 bytes file, and no
loss in picture quality!
Only problem: you need a permanent and huge feed with the internet, but
that's worth the price. (?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Le Forgeron" <jgr### [at] freefr> schrieb im Newsbeitrag
news:3D5### [at] freefr...
> Nowhere, but I did not say that I like that fact.
> It would be better to take profit of the portability and have a bmp
> reader (Win sys) on Unix and Mac port, and reverse of course (thus being
> able to use the same scene files whatever the system).
How did you conclude the Mac version will not read BMP images? Or tons of
other formats for that matter...?
Apart from this, are BMP images really used anywhere outside WinDOS? Last
time I checked the only BMP files I had on my Mac harddisk were those in the
POV-Ray for Windows source code folders. I can imagine many Mac and Unix
users having not more BMP images on their harddisks than I do...
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 16 Aug 2002 11:39:49 +0200, Le Forgeron <jgr### [at] freefr> wrote:
> Isn't it there a Linux/Unix Mpeg encoder that can be used to encode a
> set of images in a mpeg file (I used it once, I had to provide all the
> mpeg values and I had no idea of what they were for... ). There must be
> some decoding code too...
So again, where (if it is different than already listed
http://libmpeg2.sourceforge.net/) ?
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> [...]
>
> Apart from this, are BMP images really used anywhere outside WinDOS? Last
> time I checked the only BMP files I had on my Mac harddisk were those in the
> POV-Ray for Windows source code folders. I can imagine many Mac and Unix
> users having not more BMP images on their harddisks than I do...
Just for the record, OS/2 uses BMP files of some kind, but they are
incompatible to the Windows format. None the less there are still some
Windows paint programs that support reading and writing OS/2 BMP.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
