Re: crazy idea for encoding

[note: besides lurking on this list, I have absolutely 0 experience with
this stuff]

>   - Glass objects -- How do you handle transparency?
>   - Moving objects -- In order to get a 3d model you must assume 
> stationary scent and a known camera trajectory (or at least a scene 
> which remains stationary with respect to itself). Removing this 
> condition effectively increases your search space exponentially.
> 
> This is just a brain dump of things which should be considered if the 
> coded were to be able to deal with 'real-life' videos.

What about using 3D approximations for encoding only while still
maintaining the normal 2D image? That is, if the encoder is able to
"detect" 3D shapes in the image, it might might help to better represent
the changes that go on in the image.

Suppose there is some form av surface spinning slowly in the picture.
Normally (I assume) such a thing would be encoded by detecting texture
movement, lighting differences, scaling?, etc. (Again, I have 0
experience with this stuff, so if I'm already dead off track, please
correct me.)

Suppose the encoder was able to detect that there is an object spinning.
Now the encoder would not just observe the differences in the 2D image;
it would have an idea of what is "causing" the differences. Suppose the
encoder and decoder knows what form av visual effect a spinning surface
normally has (say, spinning a certain amount of degrees in a certain
direction results in the surface being "scaled" down a certain amount
and that given a certain light source there will be a specific form av
change in lightning).

Would it possibly require less bits to tell the decoder (i.e. encoder
that information in the file) "take the rectangle defined by a,b,c,d,
assume it's a surface spinning x degrees since the last frame -
approximate the visual effect and then apply normal 2D
MC/compression/etc on the differences between the approximated image and
the last frame" than it would take to represent the changes the
conventional way?

The encoder would probably have to include a decoder as well, so that it
can encode the necessary information to cover the left-over differences
between the actual frame and the frame after certain "2D but 3D-aware"
approximations.

The problem of detecting 3D shapes still exists. But in the case of
transparency and such, the encoder would either fail to detect the shape
(and encode normally), or detect a shape but do a lousy job - something
which could be detected during encoding (by comparing without
3D-awareness and comparing the amount of bits consumed, for example) and
thrown away.

Again, I have zero experience etc etc....

-- 
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <[email protected]>'
Key retrival: Send an E-Mail to [email protected]
E-Mail: [email protected] Web: http://www.scode.org



--- >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.