[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mjpeg-developer
Subject:    Re: [Mjpeg-developer] fast median estimation?
From:       Matto Marjanovic <maddog () mir ! com>
Date:       2005-07-19 13:51:38
Message-ID: 1191-Tue19Jul2005095138-0400-maddog () yoo-hoo ! mir ! com
[Download RAW message or body]


 >It's just about the fact that when you record any wanted signal s (may
 >this be a TV-signal or whatsever) you'll never record s but s' being:
 >
 >s' = s+n(s,t,...)
 >
 >with  s'         being the recorded/measured signal
 >with  s          being the original/true signal and
 >with  n(...)    being the noise-signal, which is dependend on the
 >                     signal itself, dependend on time, dependend on ...
 >
 >By the nature of this equation you either know s (but why should you
 >measure s' then?) or you can't reconstruct s. No way to do so. That page
 >tries to explain (not for the math-geek, not for the signal-theory
 >experts but none the less as accurate as possible) what principle
 >statistic methods exist to outguess a close value for s and it explains
 ...
 >
 >To clarify what I mean/understand being noise in a digitaly recorded
 >video-sequence:
 >
 >A video-sequence is a series of images where the seperated images should
 >only differ because of (a) translation/rotation, (b) changing objects
 >and (c) changing lightness/brightness. Any other change from one frame
 >to the other in such a sequence is noise and wastes bits the encoder
 >could use for encoding detail. So is cosmic background radiation,
 >amplifier-noise, thermal-noise in resistors and any other signal-source
 >which alters the image from one to the other...

What then is the model for n(...) for the noise you are trying to remove?

To discriminate between s() and n(), you need a model for both.  The way
 the problem has been posed above, s() is defined by an elaborate but still
 very broad set of features, and n() is left as, ?, uniform distribution?
The denoiser then becomes a very elaborate encoder --- it is actually trying
 to out-perform the MPEG encoder, projecting some input s' down onto a very
 complex manifold which defines the space of "real video signal".

Perhaps it could be productive to identify the major sources of noise,
 and attack each source independently (or at least model each one)?
 This might allow for a simpler model of s() in some cases --- which
 could make the whole process significantly faster.

-matt m.

My last message to you bounced (see bounce message below).  Perhaps your
 spam-filtering is being a bit too aggressive?  ("dialups"??  I pay an
 unreasonable amount of money for my static IP address!)

  This message was created automatically by mail delivery software (Exim).
  
  A message that you sent could not be delivered to one or more of its
  recipients. This is a permanent error. The following address(es) failed:

    stefan@lionfish.ping.de
      SMTP error from remote mailer after RCPT TO:<stefan@lionfish.ping.de>:
      host a.mx.ping.de [83.97.42.2]: 553 direct mail from dialups not accepted here


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mjpeg-developer mailing list
Mjpeg-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-developer
[prev in list] [next in list] [prev in thread] [next in thread]