Re: Analogue artifact estimation

On Sunday 01 September 2002 10:54, [email protected] wrote:
> Hi,
>
> I originally posted these ideas to the Theora developers list, but 
they suggested that this list might be more appropriate, (I thought 
that the Tarkin project had died off :-) ), so here goes:

Well, it depends on your definition of "dead" :-). We've had longer 
periods of inactivity before, and then someone mails something and 
it flares up again. Or not. :-).

> > Hi List,
> >
> > Just batting a few ideas around here, but would it be possible
> > to include in to the codec, estimation for common video
> > artifacts that occur in the analogue world?

That's interesting. If we can recognise them we could probably even 
compensate for them as well. Ofcourse, for certain artifacts the 
original information is simply missing so the best we can do is try 
and synthesise something.

> > For example, anything that's gone through a composite stage
> > will likely have dot-crawl and false colour - if we can
> > recognise this effect in the encoder, we can treat it as a
> > special case.
> >
> > Other artifacts that come to mind are:
> >
> > * 3-2 Pull down
> >
> > * 30/25 and 25/30 FPS conversion artifacts
> >
> > * Dropouts, (both noisy, a-la VHS, and solid bars, a-la BetaSP,
> > (which I believe halves the chroma resolution - can we possibly
> > take this in to account as well?) )
> >
> > * Stobe effect of a CRT filmed by a different scan-rate camera
> >
> > * Colour changes in multi-layered painted cel animation, (where
> > a character is, say, talking, and they repeatedly add and
> > remove a cel from the top layer, their face flashes bright and
> > dark :-) )
> >
> > Infact, existing video compression codecs do a *terrible* job
> > of encoding hand painted animation, especially anime, despite
> > claims by well known studios that it is not an issue.  Good
> > motion estimation to compensate for poor registration of
> > animation would be worth investigating.

Agreed, simple RLE does a lot better than MPEG on cartoons for 
example. However, I think cartoons are better off with a separate 
codec that's optimised for that. Probably something that can 
extract curves and surfaces and store them efficiently.

> > I think that the problem with all codecs to date is that they
> > are designed to compress perfect material originating directly
> > from a camera.  In my opinion, the above *analogue* artifacts
> > are what give the digital codecs a hard time.

It's definitely an interesting idea. I'm not sure how difficult it 
would be to reall integrate this into the codec, and whether it 
wouldn't be easier to try and filter out the artifacts before 
giving the stream to the codec. Do you know of any existing 
algorithms to filter out these artifacts?

Lourens
-- 
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key

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