Re: crazy idea for encoding

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 17 July 2002 06:55, Ph. Marek wrote:
<snip>
>
> Well, I'm with you in that it won't be easy.
>
> But suppose the following:
> - If the image changes radically between frames, it's either a
> new scene or some heavy action - which can't be encoded with my
> idea. - If the scene doesn't change much - I'll further assume a
> star trek movie :-] where the uss enterprise is shown in space -
> -- that is, if many pixels stay the same from one frame to the
> other, than we can go looking. I expect that that happens nowaday
> too with video encoding (looking for similarities between
> frames).

Yep, MPEG does block-level motion compensation, ie it divides the 
image into 8x8 blocks and then checks the next frame and tries to 
map these blocks onto it.

> This looking goes from the continuous pixels to their edge (via
> an edge filter or where the frames differ). In my example this
> will be the stars or the outline of the starship. In some part of
> the scene I expect that the scenery doesn't change much, ie., the
> stars move very slowly across the screen, and from that point
> (normally start or end of scene) these areas of change can be
> tracked as they move along. As long as there's continuous

Wow, wait a second. How do you tell one star from another? You could 
map each star in frame 1 onto the one that is closest position-wise 
in frame 2 but that would give you a lot of errors. Now you could 
try to find a vector that when added to a star in frame 1 always 
gives you a star in frame 2. That's nice for panning shots, but 
what if we go to warp? That's a zoom basically, and this strategy 
will fail.

Another idea is to do an edge detect and then trace edges and store 
information that basically encodes the shape. Maybe move along the 
edgi with fixed intervals and store the edge direction information 
into an array. We could then compare these arrays linearly and try 
and find similarly shaped objects in both frames. For complex 
spinning objects it will likely fail though.

> movement or acceleration this should be possible.
> So we can identify corresponding points in the frames. Using
> these (and the connections between them, which are identified by
> an edge filter [where color changes]) we can guess some
> "sprites". Initially these sprites are 2d (and some will stay so
> - eg. the star background). But if a sprite itself changes in
> that for example the middle goes to the right but the outline
> goes to the left, areas disappear to the right edge and new ones
> appear to the left side, then we can assume that this object is
> spinning while moving. Or the background: If the image shifts to
> the right, we can append the new bits from the left to the
> already existing image.

Hmm, that sounds familiar: 
http://www.xiph.org/archives/vorbis-dev/200102/0135.html (thread 
partially continues in tarkin-dev, which was just being created at 
the time of this thread).

> I don't propose to construct complete 3d implementations - that's
> too much overhead both encoding and decoding. [But it would be
> cool to once reconstruct the enterprise as a 3d object - some
> scenes would then just say "move object Y along path Z over
> background W", possible with a zooming factor - that would save
> bandwidth as this object needs to be described only once,
> although it may be a problem with streaming] [Would be cool to
> get "indefinite" resolution - in such a movie we could zoom in
> ...]

Or change the camera position (as long as the objects that come into 
view have been in view before, otherwise there would be no data on 
them)

Anyway, not as easy as it seems, IMHO.

Lourens
- -- 
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9NSVfvmNyqZHWDvURApetAKCh6R+CSTCUoMjVVHEkY3S0f5PR0wCfbsme
hhGmGrX1lB0V0RatSK1262w=
=Opm+
-----END PGP SIGNATURE-----


--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to '[email protected]'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.