DaalaMeeting20131008

From XiphWiki
Revision as of 07:58, 15 October 2013 by Jack (talk | contribs) (Created page with "<pre> # Meeting 2013-10-08 ## Agenda ## Attending jmspeex, unlord, derf jmspeex wants as many people as possible to review his PVQ code. derf can't promise to do it for several d...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
# Meeting 2013-10-08
## Agenda
## Attending
jmspeex, unlord, derf
jmspeex wants as many people as possible to review his PVQ code.
derf can't promise to do it for several days, possibly a week, but jmspeex thinks that's fine.
unlord promises to take a look.
derf suggests explaining it to Sean Silva, who seems to be interested and not an idiot.
unlord almost done modifying the codec to TF down everything to 4x4 for intra prediction, will have code to review shortly. TF'd 8x16 appears to be no worse, despite predicting from half the data.
Should we have a flag to switch this on and off?
derf: Will we ever run non-TF'd 16x32 predictors again?
This idea is mostly for testing.  Still useful to have rd-curves of full predictors (non-sparse, maybe non-TF) to compare to sparse alternatives.
jmspeex: Perhaps to speed up training things we should use a couple iterations of Gauss-Seidel instead of re-solving the system every time (cutting out a factor of O(N)).
derf: More important than that would be to use a robust least-squares solver to handle outliers. We could probably modify things to use Gauss-Seidel as part of that, since these things are usually iterative anyway.
unlord: We're currently running all our training unweighted, because it wasn't clear that the weights were the right way to get rid of outliers.
jmspeex: The other thing we should look at is L1.
derf: We'd need a sparse linear programming solver.
unlord promises to look into getting one.
derf will dig up the computer vision paper that describes how to convert L1 minimizations into LP.
unlord: Talked about Chroma from Luma, what exactly is involved there?
derf: Deciding when to use the AC prediction or not (have a symbol to clamp alpha to zero, figure out probabilities from sudden luma changes, etc.)
jmspeex: PVQ already has a flag that decides whether or not to use the predictor for AC.
jmspeex: Decision between "use prediction" and "no prediction or gain is zero" had an entropy around 1.2 bits for all 4 bands of Lena image with 8x8 blocks.
Consider adding a few lines of code in Chroma from Luma to turn off the alpha's (non DC component) based on a luma threshold
Gather statistics to know how to handle cases where CfL predicts poorly.  Need to measure:
1) How well does CfL predict the current block from current Luma
2) How well does current luma "match" neighboring luma
3) How well does intra prediction work on current chroma (from neighboring chroma).
  -In the case where there are 4x luma blocks for each chroma block, use the luma UL mode for prediction.