Re: (statistics)how to make date more like Laplacian distribution?

Dear Marco,

> Entirely depends on just how badly you truncate stuff in the DCT/iDCT. I
> have no way of telling, but it was you who brought up that round off
errors
> in your transform were significant in another thread.

Yeah, the error for integer hardware implementation comes from 1) round-off
floating-point transform basis matrix to integer matrix; 2) after
quantization, there is a round operation... I guess this one is the big
lossy step...

I looked into BinDCT... and I was amazed that they did not use
quantization/round-off as appeared in JPEG standard to do this big lossy
step... instead, they use EZW like progressive transmission coefficient
method to do the packadization of the coefficients...  silimar to
JPEG2000... then the result is better than JPEG coding. I have no way of
telling if it is good or not... it is difficult to judge a research if the
comparison basis is shifted... But I think that packadization
step(equivalent to quantization and scaning in JPEG) is of high
complexity... right?


> If you look at the paper "Blocking Artifact Detection and Reduction in
> Compressed Data" on page 880, at the left bottom they give a formula to
> determine the offset down from the center of the quantization range. The
> formula only needs the quantization step and the per coefficient variance.
> The variance is estimated by the variance of the center reconstructed
> quantized coefficients (that is all the information the decoder has).
>
> Concretely, say for coefficient (3,3) ... you take all the (3,3)
coefficient
> magnitudes dequantized in the standard way and compute their variance, you
> feed that together with Q into formula 10. Then you subtract the result
from
> all the (3,3) coefficient magnitudes.
>
> Alternative you can use the interpixel variance from the paper they
mention,
> [40], which has the advantage that the offsets dont have to be uniform
over
> the entire image (you could compute the variance for a single block and
> determine the per coefficient variances from that to compute the offsets)
> and it doesnt suffer from poor fitting due to low numbers of samples (for
> high frequencies there will be very few quantized coefficients >0).

Marco, have you tried the "coefficient correction" method in that paper to
make received coefficient statistically better? I tried ... but failed to
get any "better" result... in fact, the PSNR is even worse...

Here is my code: first a function to compute the bias for each 8x8 block. Q
is the quantization table... x is the received coefficients(not dequantizaed
yet...)  output y is also in un-dequantized coefficient domain... both x, y,
Q are 8x8 in size.... I use the equations in that paper...

function y=mybias(x, Q)
sigma=abs(x.*Q);
a=sqrt(2)./sigma;
y=(Q/2.*coth(a.*Q/2)-1./a)./Q;

Then the main program, Bias is the bias for the whole image, R1p is the
rounded quantized coefficient(the received coefficients), R is the original
image. R2p is the reconstructed image, ScaleKeepP=0.6079... to make 0.8bpp
compression... the image Lena has size MxN=512x512...

    R1p=blkproc(R, [8, 8], 'round(dct2(x)./P1)', (QTable*ScaleKeepP));
    Bias=blkproc(R1p, [8, 8], 'mybias(x, P1)', (QTable*ScaleKeepP));
    R1p_abs=abs(R1p);
    R1p_temp=max(R1p_abs-Bias, 0);
    R2p_temp=blkproc(R1p_temp.*sign(R1p), [8, 8],
'idct2(x.*P1)',(QTable*ScaleKeepP));
    R2p=blkproc(R1p, [8, 8], 'idct2(x.*P1)',(QTable*ScaleKeepP));
    10*log10(255*255*M*N/sum(sum((R-R2p_temp).^2)))
    10*log10(255*255*M*N/sum(sum((R-R2p).^2)))


It turns out R2p yields PSNR 38.1061dB  but R2p_temp yields 37.8301dB...

It is interesting to me that why it does not work as claimed...

Can you help me out of the swamp?

Thanks a lot,

-Walala