quantizers.txt

小波变换算法

checa wavelet, 

small midzone:
	checa.256.raw :   65536 ->   13297 =  1.623 bpb =  4.928 to 1
	error: av= 0.69,max= 4,mse= 0.968,rmse= 0.98,psnr= 48.31

deadzone:
	  13263 =  1.619 bpb =  4.941 to 1
	 0.934,rmse= 0.97,psnr= 48.46

small midzone :
	536 ->    8446 =  1.031 bpb =  7.759 to 1
	 11,mse= 2.813,rmse= 1.68,psnr= 43.67

deadzone:
	eca.256.raw :   65536 ->    8274 =  1.010 bpb =  7.920 to 1
	ror: av= 1.19,max= 10,mse= 2.698,rmse= 1.64,psnr= 43.85

deadzone:	Q = 1
	=  2.781 bpb =  2.875 to 1
	rmse= 0.44,psnr= 55.26

small midzone : Q = 1
	712 =  3.260 bpb =  2.453 to 1
	73,rmse= 0.27,psnr= 59.50

--------------

deadzone: Q = 1
	lena.256.raw  :   65536 ->   32089 =  3.917 bpb =  2.042 to 1
	error: av= 0.21,max= 2,mse= 0.215,rmse= 0.46,psnr= 54.84
	forward:1.100,encode:0.160,decode:0.110,inverse:0.770
	deltas        :   65536 ->    7959 =  0.971 bpb =  8.234 to 1
	lossless      :   65536 ->   40048 =  4.888 bpb =  1.636 to 1

small midzone: Q = 1
	lena.256.raw  :   65536 ->   35269 =  4.305 bpb =  1.858 to 1
	error: av= 0.09,max= 1,mse= 0.089,rmse= 0.30,psnr= 58.66
	forward:1.090,encode:0.110,decode:0.170,inverse:0.710
	deltas        :   65536 ->    4278 =  0.522 bpb = 15.319 to 1
	lossless      :   65536 ->   39547 =  4.827 bpb =  1.657 to 1

deadzone : Q = 0.76
lena.256.raw  :   65536 ->   35873 =  4.379 bpb =  1.826 to 1
error: av= 0.09,max= 2,mse= 0.091,rmse= 0.30,psnr= 58.57

------------------------------

When people say "uniform optimizers" they
usually mean "deadzone quantizers".  First a
review :

if 'x' is a real number, we quantize to
a bucket-size 'Q' as :

quantize:

	q = x/Q 	(floor)

dequantize:

	if ( q == 0 ) y = 0
	else y = Q * (q + 0.5)

this is called a dead-zone quantizer because the
restoration step is to the middle of quantizer
ranges iff you imagine the center quantizer going
from (-Q) to (Q).  If we ignore the sign bit, then
this is indeed a uniform scalar quantizer, but if
we don't ignore the sign bit, then we really are
quantizing extra values to q == 0.

(on many platforms, you must take the abs of x to
make it positive then restore the sign after the
above manipulations; note that Intel CPUs always
round floating points towards zero, whether they
are positive or negative, so that :

	((int)(0.5) - (int)(-0.5)) == 0

which is wierd).

Now, everyone tells us dead-zone is good, but
that's just not quite right.  In the very-very
high quality regime (Q <= 1.0 !!) the deadzone
quantizer is far from optimal.  However, perhaps
that is irrelevant.  We can consider another
quantizer, an "equal size zero-zone" (ESZZ) quantizer:

quantizer:

	q = x/Q + 0.5	(floor)

dequantize:

	y = Q * q

This is just like a deadzone, but the center region
are of size Q/2 instead of Q.  Now, we first notice
that this is computationally superior.  We can implement
it on Intel with no branches, and with no removing the
sign and restoring it.  Also, tests show that in the
extremely high quality regime it is better.

Some examples : (on Lena 256x256 grey)

    ESZZ @ Q = 1.00 : 4.305 bpp, 58.66 psnr
deadzone @ Q = 0.76 : 4.379 bpp, 58.57 psnr

the ESZZ has less error and better compression.

similarly, running both at Q = 1.0 and then
lossless coding the error map, we get:

	ESZZ : 4.827 bpp
	dead : 4.888 bpp

Ok, so this is all very encouraging.
But let's try in a more realistic regime,
around 1.0 bpp :

now on "Checa" 256x256 grey

	ESZZ : 1.031 bpp , 43.67 psnr
	dead : 1.010 bpp , 43.85 psnr

the tables have turned?  The deadzone quantizer
gets better compression with less error.  (note
that at these high quantization values, the ESZZ
and deadzone quantizers are almost twice as far
apart, that is the bucket-size for zero is almost
the same size).

The question is : why?  There is a trade-off
somewhere, what drives it?  This also seems to
suggest that uniform quantizers are not so acceptable
as is usually suggested, that some nonlinear
scaling is optimal as you change regimes.

Any help?