Who wants to translate ASP's "hvs_best" matrix to AVC format?

[bond]

yeah propably a dumb thing to do and all the avc pros will jump on me, the poor newbie, for asking for somthing senseless like that for lots of reasons i guess

but still
hvs_best is a f*ing great matrix for asp imho and i would love if "its idea" of quantisation could get also be used with avc (or at least tested)

[Sagittaire]

In fact hvs-best is good for blocking for q2-q6 interval (less blocking but more ringing) but AVC use inloop deblock. For comparison MPEG4 ASP H263 PP4 is IMO visually by far better than MPEG4 ASP HVS PPX. I think that CM for AVC utilisation could be very different than for ASP ...

[Sharktooth]

It is. Infact the ASP HVS matrices are completely useless with AVC.
Also AVC and ASP have different lower coefficient limits...
you also have 8 different matrices (JM encoder - 6 for ateme)...
ateme encoder, as i said in the bug report thread has also a deblocking offset matrix...
it's a real pain since you have to combine all this matrices to produce the wanted result.
for example you may want to produce more blocking in 4x4 lower chroma frequencies and rise a bit the deblocking offsets to spare bits (with low visual impact) for more complex scene...
well, i can make hundreds of possible scenarios, and i fear CQMs and DOMs (deblocking offsets matrices) will require A LOT (maybe some months?) of work to find usefull combinations.

[bond]

sharktooth, you are simply too lazy i guess :p

about deblocking matrices, well they are only available in ateme which is not publically available, so they dont play a role imho

[akupenguin]

There is yet another possible set of matrices: deadzones control the bias for rounding quantized coefficients up vs down.

[Sharktooth]

can you be more specific?

[Sagittaire]

It is. Infact the ASP HVS matrices are completely useless with AVC.
Also AVC and ASP have different lower coefficient limits...
you also have 8 different matrices (JM encoder - 6 for ateme)...
ateme encoder, as i said in the bug report thread has also a deblocking offset matrix...
it's a real pain since you have to combine all this matrices to produce the wanted result.
for example you may want to produce more blocking in 4x4 lower chroma frequencies and rise a bit the deblocking offsets to spare bits (with low visual impact) for more complex scene...
well, i can make hundreds of possible scenarios, and i fear CQMs and DOMs (deblocking offsets matrices) will require A LOT (maybe some months?) of work to find usefull combinations.

exactly ...

8 matrix for CM (4 if you use the same for YUV)
3 matrix for adapt deblock quant (I, P and Bframe)

and I think that metric can't help for this very particular HVS setting ... :scared:

[Sharktooth]

exactly ...

8 matrix for CM (4 if you use the same for YUV)
3 matrix for adapt deblock quant (I, P and Bframe)

and I think that metric can't help for this very particular HVS setting ... :scared:
right... the JVT matrix provides more details than standard AVC quantization, but metric tests doesnt reflect a higher score... but lower...

[bond]

would it make sense to only use four metrices to make things simpler without reducing the possible quality too much?

8x8 inter, intra
4x4 inter, intra

[Sharktooth]

human eye has a different perception of luma and chroma.
"linking" them together in a quant matrix could do more harm than using flat matrices.

[bond]

dont flat metrices also simply use the same values for both? where is the difference?

[Sagittaire]

IMO the best protocol is in order:

- find our good 4*4 and 8*8 with our good global deblock strength
- inter and intra refinement
- luma and chroma refinement
- deblock strength matrix refinement

and the probleme is that all these matrix are not independent: IMO it's a very hard and very long work ... lol

[Sharktooth]

dont flat metrices also simply use the same values for both? where is the difference?
in flat matrices all coefficients are the same so they affect all frequencies in the same way.

[bond]

in flat matrices all coefficients are the same so they affect all frequencies in the same way.
so the same coefficients are used for chroma and luma 4x4, but why than that statement:
"linking" them together in a quant matrix could do more harm than using flat matrices.

[Sharktooth]

coz using flat should be pratty safe, while when coeffs are not flat, frequencies are quantized with your custom scale and since the human eye has different perception of luma and chroma using a scale that's good for luma may completely b0rk chroma and vice versa.

[bond]

well the three custom matrices developed by mpeg also use the same values for luma and chroma so it might not be a problem practically!?
http://forum.doom9.org/showthread.php?t=96159

[Sharktooth]

a problem? not properly, if you know what are you doing, you can still find a compromise that works for both (as in JVT) but that's suboptimal.

Maybe this article will be of interest... : http://hyperphysics.phy-astr.gsu.edu/hbase/vision/cie.html