DaalaMeeting20140826

# Meeting 2014-08-26

Mumble:  mf4.xiph.org:64738

# Agenda

- news
- reviews
- intrapaint decoder?
- halfpel BMA

# Attending

- unlord, gmaxwell, tmatth, derf, jack, td-linux, smarter, xiphmont

# Reviews

tim will review jack and steinar's patches today

# intra paint decoder

- d: is this about intrapaint deringing?
- x: jm noticed as a postfilter it has pleasing effects. 
- d: there's two things. there's no inherent control in it for what under the quantization level means. the other thing is how do we apply this to actual video as opposed to still images and avoiding the refiltering problems.
- x: park joy wiggle trees! i think this falls under the category of instagram filter and not a lot more. i don't know how to use it for video. maybe jm will find a way to use it for video.
- t: just, since we don't have one, we are currently relying on the reconstructed frames for intrapaint metrics....so is it too early to write one or is now the time.
- x: does intra paint help with resampling? i'm looking for a 1d sampler that uses lifting.
- d: why lifting?
- x: because it's reversible.
- d: what's the thought here?
- x: if I have this I have an arbitrary directional transform that is fast. 
- d: what is the construction?
- x: it's a riff on square polar. we rotate the block in consecutive square rings and then apply lapping and the transform. 
- d: that doesn't work. how do you rotate and then apply lapping?
- x: the lapping is also reversible. you would apply lapping by pull out a block
that has 2x the pixel on an edge and then apply an equivalent lapping. you're
lapping on both sides would be reversible and equivalent but you wouldn't
necessarily... hard to visualize. i need to run it and verify that it is fully
reversible.
- d: I can not imagine a construction that matches any of the words you just
said and is reversible.
- x: It's not reversible until you do the overlap.
- d: Neither is a regular transform, but that's not the point.
- x: In any case it's a fast test to run when i have a reversable resampler.
- d: why do you need a resampler?
- x: To perform the rotation.
- d: I understand.
- x: If I'm not on multiples of 45 degrees then I need the resampler.
- d: Just do the 45 degree case and see if that works then.
- x: Great idea tim! Once I establish the idea is terrible, we won't need to find a resampler.
- d: You know my general opinion of directional adaptive transforms?
- x: It's not adaptive.
- d: The official term is orientation adaptive.
- j: what's your opinion?
- d: It's a terrible idea that can be solved with multiple block sizes.
- x: I'm trying to get the compaction into the row and column without.... what I'm also trying to do is eliminate the reflections at the edges of the transform. Edges that span the block are reflected by the lapping back over themselves.
- d: This is where I dont' udnerstand how you do that and get to be reversible.
- x: That's why I need to run the test.

# halfpel BMA

- s: I'm still trying to figure some things out before I implement.
- x: What is the halfpel stuff?
- s: Doing halfpel BMA stuff before the OBMC stuff. It's going well. Since I
already made it 1% smaller by fixing a bug I think I'll keep getting it
smaller.

# intrapaint decoder

- x: We need a decoder.
- j: I thought it didn't work?
- x: There was talk about using it more appropriately and as a post-filter.
- g: I think the post-filter use would have a pretty different decoder because
it doesn't have to deal with the edges.
- x: Are we still trying to use intrapaint for intraprediction?
- d: Not to my knowledge. The problem JM has is that even if you shut it off
- for most of the frame, there is nothing to fall back to.
- x: Ok, I'll try my crazy idea and may come out ahead.

...

- g: The optimization almost never picks the gradient mode.
- d: that's bad since it was supposed to be our fallback.
- x: JM did some test that said nothing was better
- d: There's no choice in the optimizer here. I think we're still oging to
- have this general problem regardless of intrapaint. How are we going to come
- up with an intrapredictor that captures DC but does not make DC more
- expensive to encode. The reason I say that is that I want to do the same
- thing for motion compensation.
- x: Separating DC out or having a do-nothing?
- d: Do-nothing. We talked about integrating intrapaint into motion search as
an alternate mode. Right now our motion search has no way to say that this
is too hard for motion vectors, so it spends a bunch of bits predicting
badly. The original idea is that you would take a block and instead of coding
the egdes of the block and extend them with intrapaint you'd use the MC
coded edges and extend them with intrapaint. The first step of that is doing
it just with gradient mode. That seemed straitforward until I came up with
constant color as an alternative reference frame. Instead of having a motion
vector I can just code a color. THe OMBC blending makes sure there are no
blocking artifacts and it works beautifully. But the shape of the basis
functions doesn't match the lapped basis functions because we don't have the
ramp constraint.
- g: Does it amtter that it doesn't match?
- d: This is the thing that JM thinks that makes intrapaint not work. Maybe
this works well enough that we can avoid the gradient problem.
- g: Can we change our windows to match?
- d: I tried to puzzle through that but it breaks block size stuff that keeps
continuity, and I ahven't figured out how to solve that problem. If the
shape of one of hte windows was a subset of the shape of the other windows,
it would work...
- g: How much worse were the ramp constraints?
- d: I no longer remember.
- u: I posted some of hte figures on the wiki.
- d: If only someone had written these things down.. Do you remember the URL for that?
- u: I think it was /TDLT but it may not be useful.
- d: Coding gain wise it looks like the difference was small but i'm not sure
  it was that small on actual images.
- u: This was just from AR95 stuff.
- d: Once Greg finishes the multiple reference frame stuff, I'm going to try
  dropping this in and see how it works. Even if this isn't perfectly
  inefficient, doing something better than what we do now will surely
  help. Then we can play around with the ramp constraint and see if that helps
  or hurts.
- u: I've been looking at .... I'll be comparing it to freq prediction we have
  without the DC (assuming Haar DC is good), and one is spatial by reaching
  outside of the lapping window. I'll post those curves when I have them.
- d: You saw the paper I sent you?
- u: Yeah.