DaalaMeeting20140520

# Meeting 2014-05-20

Mumble:  mf4.xiph.org:64738

# Agenda

- reviews
- work week & code party
  - https://daala.etherpad.mozilla.org/workweek-201406
  - https://daala.etherpad.mozilla.org/coding-party-201408
- DC encoding

# Attending

derf, gmaxwell, jack, jmspeex, unlord, xiphmont

# Reviews

- unlord: I'll commit Josh's patch once he gets me a revised one.
- derf: I'll look at JM's patches.

# Work Week & Code Party

 (discussion of logistics and call for agenda)
 
 # DC encoding
 
 - jm: my idea was to apply the Haar transform to the DC, starting with 32x32 superblock and coding the averages, and then going further down. but i'm kind of looking for ideas on how to improve that. so far it's already 1-2% better than what we're currently doing.
 - derf: depends on metric. it was more for the metrics we suck at.
 - jm: in general it's better for chroma. less diagonal bleeding.
 - d: that's because you doubled the quantizer effectively.
 - jm: i'm doing the energy normalization so there is still as much error. my haar transform is orthonormal
 - d: an orthonormal transform gives you twice as much resolution on the DC. that's why we have much less overall color shifts.
 - jm: or at least they are global color drifts.
 - d: this is the one thing wavelets are good at. they capture large scale correlations.
 - jm: should we go to larger scale?
 - d: depends on how much cache and lookahead you have. 64x64 is possible.
 - jm: i think we can live with 32 for now. i'm predicting with 32x anyway. if we actually want to encode dc up front, is there a way to do AC from DC?
 - d: i think the answer is yes
 - jm: you look at DC-only image and you recognize edges and there's a lot of stuff you can do about it.
 - d: usually you go the other way around.
 - jm: that's when you have lapping though
 - d: the original technique was without lapping, but i think you could make it work.
 - jm: there are more AC coeffs so it makes sense to predict AC from DC.
 - d: you're only going to be able to predict a few AC coeffs.
 - jm: nathan, can you post a link to the 3.5kb 265 image?
 - u: http://people.xiph.org/~unlord/fruits-x265-crf=51.png
 - jm: http://jmvalin.ca/video/fruits_low.png is fruits at 3.8k. both have just about as much info and details. the main difference is that 265 doesn't have jagged branches.
 - d: it has a blockier background and our chroma is still crazy.
 - jm: you could tune hte chroma. my main point is you could take the daala one and smooth out the branches with something automatic.
 - d: good luck
 - jm: it has a near constant background near hte edge, so you'd know which section of the block has the edge
 - d: how?
 - jm: imagine the simple case where you havea  45 degree diagonal line between perfect white and perfect black. a block on a diagonal will be able to know where hte edge is by the luma part of hte block. at least in theory you could reconstruct from left color, right color, and angle you could reconstruct the edge perfectly.
 - d: real world is not that simple. where does the angle come from?
 - jm: predict it from neighbors etc
 - d: that's more than just smoothing. we could call it intra-prediction
 - jm: you could see it as intraprediction with dc already known.
 - d: you're fond of telling me that DC is the only thing that is intra-predicted well.
 - jm: i'm just trying to find a way to get non-jagged edges like 265. i get the impression we capture more detail.
 - d: i'm not sure about that.
 - g: I wonder how much better this would look without broken chroma. also we switch to 4x4 blocks in some cases, which is probably not a good idea.
 - jm: if we don't use 4x4, it's even worse. look at http://jmvalin.ca/video/fruits_low2.png . actually that looks better. that means our 4x4 is still blocky.
 - g: it doesn't have hte rate to do anything useful with 4x4.
 - jm: normally 8x8 should look worse. there doesn't seem to be much overlap in the 4x4.
 - g: there isn't. there isn't much room for overlap
 - d: 2 pixels!
 - u; there's a lot of ringing around that right branch in the middle of the frame.
 - d: 265 copies the edges all over the fruit
 - u: in the first low, there is a white halo around the branch and low 2 doesn't have that.
 - d: we certainly don't.
 - u: is that ringing?
 - d: i don't think so. the block size should be too small. there was probably real detail there in the original that low2 just blurs out.
 - jm: here's low3: http://jmvalin.ca/video/fruits_low3.png 3.8k and slightly better chroma.
- d: you should look into what hevc is doing for its deringing filter. i think a lot of this stuff is a strong deringing filter applied to these things.
- jm: can we turn it off?
- d: I don't think so. it's part of the format.
- jm: nathan, can you look at it with the viz tool and see what it does without the deringing filter?
- u: let me try and find it. http://people.xiph.org/~unlord/fruits.x265
- jm: you think it's the deringing filter doing all this?
- d: perhaps not all of it.
- jm: we can see cases clearly where it's the intrapredictor. perfect angled edge. too perfect. master at 5k: http://jmvalin.ca/video/fruits_lowmaster.png

# Future work

- d: trying to get my quant matrix stuff into shape for review. the MV stuff was removing the restriction that neighbors can't differ by more than one size level.