SSIM calculation

[quake74]

I've tried to compress Serenity (x286, HQ-Slow, 825kbps) and have big problems with blocks in dark areas
http://img130.imageshack.us/img130/572/frame19366ny.png (http://imageshack.us)
http://img59.imageshack.us/img59/3791/frame19488gd.png (http://imageshack.us)

So I started wondering if SSIM would pick-up those diferences, but as you see it doesn't (the SSIM value is very high, and the quality is very low). So I tried the MSU blocking measure, and another failure since the two values are really close (13.89 vs 14.70 for the first image, and 14.10 vs 14.37 for the second one).
Moreover, the MSU calculation of SSIM is slightly different than the avisynth ssim 0.24 one. Here is a graph of the difference over a sample with 5000 frames

http://img155.imageshack.us/img155/8329/comparessim2pa.png (http://imageshack.us)

Does anyone know why they are different? Is there another metric which could pick up the (to my eyes, HUGE) differences? (On the side, I also accept suggestions on how to reduce that effect, and I already know about AQ and cust quant matrices, blockbuster, etc.)

[MfA]

Moreover, the MSU calculation of SSIM is slightly different than the avisynth ssim 0.24 one.

Dmitry tells me that they don't use lumimasking, so that will make a significant difference.

[Daodan]

Are you sure you are using SSIM corectly? Because there should be another value to the right of SSIM called weight, after you play your clip in VD and close it, it will write a file with average SSIM. Because that value reported on your pictures sais nothing, I have a movie compressed with q=20 (x264) and that value is also close to the original, but the average SSIM reported is 75. So what I'm trying to say is your SSIM calculation seems wrong.

[quake74]

Are you sure you are using SSIM corectly? Because there should be another value to the right of SSIM called weight, after you play your clip in VD and close it, it will write a file with average SSIM. Because that value reported on your pictures sais nothing, I have a movie compressed with q=20 (x264) and that value is also close to the original, but the average SSIM reported is 75. So what I'm trying to say is your SSIM calculation seems wrong.

The value you quote (75) is the one you obtain putting scale=true (or maybe the opposite) in the ssim call. I don't know how to calculate SSIM by hand, but I believe these are pretty much correct (since the difference btw two programs is so small, and they return a value of 1 during the first frames, which are all black and so all equal).

[Audionut]

"Brightness" on your monitor is not adjusted correctly.

I had to crank up the "gamma" on my monitor to be able to see the blocks.

[Archimedes]

AviSynth’s SSIM plugin calculate the SSIM value in the YUV color space. MSU Video Quality Measurement Tool calculate the SSIM value “only” for the luminance part (Y). As far as i have tested, the MSU VQM Tool’s SSIM values are equals to the MSSIM values (without weithing values). Video Quality Studio (VQS) calculate the SSIM values with weighting values. Fritz Framalyzer calculate the SSIM with (Q in Y) and without weighting values (MSSIM). Weighting values means, as darker regions usually do not attract fixations, therefore they become smaller weighting values.

[quake74]

AviSynth’s SSIM plugin calculate the SSIM value in the YUV color space. MSU Video Quality Measurement Tool calculate the SSIM value “only” for the luminance part (Y). As far as i have tested, the MSU VQM Tool’s SSIM values are equals to the MSSIM values (without weithing values). Video Quality Studio (VQS) calculate the SSIM values with weighting values. Fritz Framalyzer calculate the SSIM with (Q in Y) and without weighting values (MSSIM). Weighting values means, as darker regions usually do not attract fixations, therefore they become smaller weighting values.

Whoa :thanks: