SSIM 0.24, an objective video quality metric

[Lefungus]

This filter has been created following the ideas of Zhou Wang (http://www.cns.nyu.edu/~zwang/).
It has been coded with the great help of Mfa, who worked on the core functions.

For a given reference video and a given compressed video, it is meant to compute a quality metric, based on perceived visual distortion. Unlike the well-known PSNR measure, it's not purely mathematical, and should correlate much better with human vision.
Some examples here (http://www.cns.nyu.edu/~zwang/files/research/quality_index/demo_lena.html)
A higher MSE (and so lower PSNR) should mean that the compressed clip is a worse image but MSE and PSNR are flawed in this respect as numerous tests have shown. However with SSIM, according to tests carried out on the VQEG dataset, a higher Q (SSIM value) has a much better relation to the visual quality of the compressed clip. Despite this, bear in mind the SSIM metric still isn't perfect.

This filter is designed to compute an SSIM value by two methods, the original one, and a "enhanced" one that weight these results by lumimasking. On the todo list is to include the motion weighting.

This filter has five parameters:
ssim(clip1,clip2,"results.csv","averageSSIM.txt",lumimask=true)
clip1 and clip2 are the reference clip and the compressed clip.
results.csv is the file where obtained SSIM values will be written (this can be easily read in excel or notepad for those unfamiliar with the comma separated variables format)
lumimasking switch between the two methods.

When the video is closed, the filter will write a file named "averageSSIM.txt" that will contain the global SSIM value.

An SSIM value is between 0 and 1, 1 meaning perfect quality.

To analyse locally the results, you could use the csv files, and manipulate data in any excel-clone. Examples:
codec A vs codec B (http://perso.wanadoo.fr/reservoir/dl/ssim.png)
codec A with lumi option (http://perso.wanadoo.fr/reservoir/dl/ssimlumi.png)

In the csv file, when lumimasking is activated, both SSIM values and its weigth is written.

Nota:
-If you use B frames under xvid, trim the first dummy frame of the xvid clip, and the last frame of the original clip
-For those who used ssim 0.1, this version is also faster !

SSIM 0.24 Dll (http://perso.wanadoo.fr/reservoir/dl/SSIM-0.24.rar)
SSIM 0.24 Sources (http://perso.wanadoo.fr/reservoir/dl/SSIMSrc-0.24.rar)
This filter is released under the condition of the gpl license.

[EDIT]
version updated to 0.21:
-flag for globalSSIM added
-some checks added

0.22:
-added "scaled" parameter

0.23:
-minor memory leak removed

0.24:
-various bugfixes

[Lefungus]

Some script examples:

a=mpeg2source("C:\Vobs\pacte.d2v").crop(14,92,692,416).lanczosresize(640,256)
b=AVISource("C:\Vobs\xvid.avi").trim(1,0)
return ssim(a,b,"results.csv","averageSSIM.txt",lumimask=true)
In this example, i compare the dvd source to the xvid compressed version. As bframes are used, i have to trim the first frame of the xvid version.

a=mpeg2source("C:\Vobs\pacte.d2v").crop(14,92,692,416).lanczosresize(640,256)
b=AVISource("C:\Vobs\divx.avi")
return ssim(a,b,"results.csv","averageSSIM.txt",lumimask=true)
There, i compare the same source to a divx compressed version. No need to cut any frames there.


In the two examples, i compare the dvd to mpeg-4 codecs. But the SSIM metric should works as better on any codec, video source.

Nota:
-Compared clips must have same width/height/length
-SSIM is computed in yv12 colorspace

[EDIT]
Updated scripts

[Selur]

seems to work fine,..

Thanks for this nice tool ;)

It's especially cool if you do somethign like this:

A = Avisource("d:\Original.avs")
B = Avisource("d:\encode1.avi")
c = Avisource("d:\encode2.avi")

StackVertical(ssim(A,B,"Encode1results.csv",lumimask=false),ssim(A,C,"Encode2results.csv",lumimask=false))
since it allows you to see which frame get's what rating on which clip ;)


Cu Selur

Ps.: would be cool to also have an alternative flag, to set the output for the average SSIM, so the script I used would produce two average SSIM values. ;)

[DDogg]

Lefungus, this is an answer to a prayer as a few of us have been trying to compare the effects of matrices and filter combos on low bitrate mpg produced by CCE 2.67 and other mpeg2 encoders. If you have time, I have a few questions, some of which are fairly basic, so be patient with me :).

1> Could you give a short overview of the Y, U, V, SSIM, WEIGHT figures shown during the comparison. This may be a waste of your time as I realize that data is available later for comparison via the results.csv and averageSSIM.txt. I guess I am asking how I can "get a feel" for what is happening during the comparison pass. I am afraid this question may seem ambiguous to you. If so, no worry :)

2> Your method of seeking clip2. For clip2 I am presently using a d2v generated by dvd2avi which works great. However I was thinking of trying Nic's mpegsource as it automatically creates the d2v and would eliminate that step, but if I remember correctly it has trouble with multiple seeks. Are you doing an end to end on clip2 or multiple seeks?

/ADD
3> I was interested in comparing different encoded sample clips. To test that I used clip1 = "clip1.d2v" and clip2= "Copy of clip1.d2v" and indeed got an Average SSIM= 1.0. So far so good.

Next test was clip1=knowngood.d2v clip2=known_inferior.d2v and again it showed a lower Average SSIM= Average SSIM= 0.666261. Still looking good.

Next, and here is either the problem or my confusion showing, I reversed the order of the test above to clip1=known_inferior.d2v clip2=knowngood.d2v and this time got an Average SSIM= 0.657958 which was about the same value as the reverse test above. I guess I expected the result to be an "out of range" or >=1, yet it was not.

What are your thoughts? Is this type of encoded clip comparison practical?

Because most of the information was specific to DVD2SVCD, I placed a post here in the DVD2SVCD. I hope you do not mind. http://forum.doom9.org/showthread.php?s=&threadid=61172

[Lefungus]

Originally posted by DDogg
I have a few questions, some of which are fairly basic, so be patient with me :).
Do i look so rude ? :D

1)
Y, U, V values are SSIM values for each plane for the current frame. Later they are weighted and averaged. Y is luminance, and U,V colors. Human vision is much more sensible to luminance so this plane has much more influence than the color planes.
SSIM is the current quality index, scaled from 0 to 1.
Weight is the coefficient that will be applied to the current SSIM value when the global SSIM value will be computed.

2)
To use this filter i suggest you load the script into vdub, play it from beginning to end without skipping frames or seeking specific frames. Nic mpegsource behaviour is unknown when you seek into the video, so if you do it this way, no problem should arise. I don't use any special trick, if you call frame 1, i'll ask frame 1 from clip 1 and frame 1 from clip 2.


@Selur: it'll be added in next version :)

[Lefungus]

Theorically ssim(a,b) = ssim(b,a)

In your case it looks like it isn't

About comparisons:
a is a video clip
b is a compressed version of a
c is another compressed version a

You could use ssim(a,b) and ssim(a,c) and compare these results but i don't think you could get any information from doing ssim(b,c).

[EDIT]

On all my tests, ssim was perfectly symmetrical, so i can't reproduce your result DDogg :/

[Prettz]

Originally posted by DDogg
Next, and here is either the problem or my confusion showing, I reversed the order of the test above to clip1=known_inferior.d2v clip2=knowngood.d2v and this time got an Average SSIM= 0.657958 which was about the same value as the reverse test above. I guess I expected the result to be an "out of range" or >=1, yet it was not.


It sounds like the filter is set up assuming that the first clip is the "original", so putting the inferior clip as the original and comparing a better-looking clip to it doesn't mean anything in that context, and to me it seems sensible that doing that could produce any kind of wacky result.

[DDogg]

and to me it seems sensible that doing that could produce any kind of wacky result. Yes, it does, however it got stranger after that. Actually, when I took great care and exactly replicated the test B-C and C-B the csv yield *identical* results to six decimal places, which I thought was odd as I expected a whacky result of some kind, but not identical, although I guess you could say that was symetrical in a way :). Anyway, we have been PMing all day and I sent up a set of files to help Lefungus work with mpeg2 as he mentioned most of his work had been with XVID and DIVX. I hope this tool ends up working with mpeg2 as it would be very useful.

[MfA]

SSIM simply doesnt care on which input the reference is because it is entirely symmetrical, just like MSE/PSNR.

[DDogg]

Well it is symmetrical if you don't screw up and get a framecount unbalance like I did :o

One thing for mpg2 users to be careful of is the the two samples must be the exact same frame count (obviously), however, when using a mpv of a verified 5001 framecount, I noticed when using dvd2avi to create the d2v used in mpeg2source("b.d2v") that the framecount became 4998. So it is best to use the trim statement of a slightly smaller value to actually insure the exact frame count and double check it in VDub using file/information. I used mpeg2source("b.d2v").trim(0,4499) to give me an exact 4500 frames.

I noticed lafungus has updated ssim to catch this framecount unbalance in the newer version he posted so maybe it will not slip past others like it did for me using the first version.

Sidenote:I was gently pointed to the heavy thread in the dvd2avi forum dealing with this very subject where DG is putting in an enormous amount of effort dealing with framecount errors between dvd2avi and mpeg2dec. I don't read that forum much so I was unaware. Thanks!

[Lefungus]

In version 0.22, the global score is scaled from 0 to 100 instead of 0 to 1. it's just a simple conversion: newValue = 100 * pow( oldValue, 8)
With this, different values between two clips may be more visible.

example on a small xvid sample:

high bitrate clip: 82
low bitrate clip: 66

If you prefer it non-scaled, just add "scaled=false" as parameter.
For the same sample, it'll give:

high bitrate: 0.975
low bitrate: 0.949

[DDogg]

With this, different values between two clips may be more visible. Very much so, with the new values it is a snap to quickly get an idea of the quality of the encode. Thanks very much for this new feature, it makes using SSIM much easier and straightforward.

[KpeX]

Great tool, Lefungus. I've also needed to adjust some framecounts to get the right frames when comparing D2V to AVI. I usually test the script first with a StackVertical and scan through it frame by frame in VDub to make sure the correct frames are corresponding.

[deXtoRious]

The tool is great, however it's approx. 5-6 times slower than PSNR or VQM. Is that just a lack of optimisation or is it inherent in the very nature of the algorithm?

[MfA]

Could probably be sped up 2 times with assembly, more with subsampling ... but I prefer it slow over subsampled. Removing the memory leak I introduced might also help a bit.

PSNR sucks period, and VQM is poor in weighing blocking artifacts.

[Lefungus]

Sh0dan has added conditionnal functions, so the ssim metric could be used in conditionnal scripts.

For example:
a=avisource("c:\blah.avi")
b=a.filter()
return conditionalfilter(a,b,a,"SSIM_AVG(a,b)","<","0.98",true)
will return b, if ssim(a,b)>0.98, or a if b is bad ssim-wise (meaning it may filter too much). 0.98 is an arbitrary value, and should be replaced by your own adequate value.

It may also be used in a 3-pass encoding scenario, when you filter more encoded frames, that have a too low ssim value.

a=avisource("c:\blah.avi")
b=a.filter()
c=avisource("c:\blah-2pass-encoded.avi")
return conditionalfilter(a,b,b,"SSIM_AVG(a,c)","<","0.94",true)

I have no idea if it'll give good results, but the concept is interesting :)

Get the dll here (http://perso.wanadoo.fr/reservoir/dl/SSIM.dll)

[sh0dan]

I had a few concepts in mind for "extreme" compression optimizitation:

Case 1:
Do an ordinary two-pass encode. Compare the output to the source. If SSIM difference is big, do additional filtering on these frames for a third/fourth pass.

Case 2:
Compare original frame to a blurred version. This should give a fairly good idea on the amount of high-frequency (spatial) detail level. This value could be used for setting threshold for a filter.



PS: There is also conditional functions for retrieving Y,U & V-plane only SSIM difference.

SSIM_Y(clip a, clip b)
SSIM_U(clip a, clip b)
SSIM_V(clip a, clip b)
SSIM_AVG(clip a, clip b) = 0.8 * SSIM_Y(a,b) + 0.1 * SSIM_U(a,b) + 0.1 * SSIM_V(a,b)

[Lefungus]

Actually, i've followed the ssim way for average, so it's :

ssim_avg=0.8*ssim_y + 0.1*ssim_u +0.1*ssim_v

as Y plane has much more visual impact than UV planes

[sh0dan]

Didn't I write that? :D

(ok - I edited the post above to avoid misunderstandings) ;)

[DDogg]

Wow...This sounds like a potential nugget of gold hidden away in this thread. I'm getting all excited. I think you are saying one could compare each frame back to the source and then apply filters to each frame based upon the quality index returned by ssim. Is this correct? I do have a difficult time understanding this stuff.

I wonder if one or both of you could flesh it out a little more and maybe post a more complete example of a test script so folks like me could do some testing. I can't quite get there by myself and could use the help.

In my case I would like to try it with CCE 1-pass vbr with two to three filter combos like none, deen, and heavy (maybe deen with light blurring?)

In re-reading the above I realize I may be confused as you both mention multipass as if this may be "pass based" conditional versus frame based. Any help you can give me towards understanding the above more fully and getting a working test script would be appreciated. I can do alright with this stuff once someone kickstarts me.

Btw, your "get the dll here" above is a new version or is it 0.23? Might be better to just point people to the top of the thread?

[sh0dan]

A "simple" script that chooses between three resizers.

mpeg2source("c:\temp\twinpeaks\pilot\pilot.d2v",idct=6)
crop(18,4,-10,-4)
pre_resize = last
lanczosresize(352,288)
# return last #use this for first encode

v_org=last
v_comp=avisource("uncompressed.avi").converttoyv12()

soft = bilinearresize(pre_resize, 352, 288).subtitle("soft")
medium = bicubicresize(pre_resize, 352, 288).subtitle("medium")
sharp = lanczosresize(pre_resize, 352, 288).subtitle("sharp")

medium = conditionalfilter(medium, sharp, medium, "sim_diff", ">", "0.97")
conditionalfilter(medium, soft, medium, "sim_diff", "<", "0.96", false)
frameevaluate("sim_diff = ssim_avg(v_org, v_comp)")

First I encoded the file to MPEG1, using the return statement at the top .I didn't have any MPEG2 encoder on this machine, so I had to use MPEG1 and decompress the MPEG 1 -> AVI. MPEG2 is much easier, and doesn't require colorspace conversions.

Then the filter chooses between three different resizers based on the quality measurement. The numbers I've entered seemed to fit my source, but they will most likely have to be adjusted.

[DDogg]

hmmm, thanks, sometime I just think you just like to mess with my head and make me feel completely dumb. I'll have you know I am only partially dumb! :)

Let's assume we have a progressive source DVD and we have created our original.d2v. I was thinking v_comp=Avisource("original.d2v+Crop&resizingfilters.avs") would be the comparison part very much like a standard ssim comparison. I can't reconcile that with the example you gave (much to my shame). I don't even have a clue what you are doing with v_org=last

In reviewing the above posts on this topic from you and LaFungus it seems you are speaking of two different methods. One uses a comparison source which is an uncompressed AVI that I assume would have only had resizing applied. The other with an example by lafungus uses the original source.

The second one using original source from the d2v is where I am trying to get. I think it is obvious this stuff is a little above my skill set, however if I can understand it I think I could help some other partially dumb folks to do so also. More help would be appreciated. :o

[sh0dan]

Originally posted by DDogg
Let's assume we have a progressive source DVD and we have created our original.d2v. I was thinking v_comp=Avisource("original.d2v+Crop&resizingfilters.avs") would be the comparison part very much like a standard ssim comparison. I can't reconcile that with the example you gave (much to my shame). I don't even have a clue what you are doing with v_org=last

"pilot.d2v" is the original source. "uncompressed.avi" is the compressed result that has been decompressed to a huffyuv. Exchange the avisource with your compressed d2v. As I wrote I did this for a workaround since I didn't have an MPEG2 encoder.

For creating the first compressed result uncomment the "return last" and encode the result. You might want to adjust the script if you are doing SVCD/DVDR. If you need deinterlacing/ivtc insert it before "pre_resize = last".

The resize filters are just as an example - you can put additional filters inthere.

"v_org = last" just assigns the current video (after the lanczosresize) to v_org, as this has to be used for the SSIM comparison later.

[mf]

Your Subtitle()s are impairing your SSIM result :D.

[sh0dan]

No - because neither of these three sources are used for the compare (v_org is compared to v_comp).

[ronnylov]

I have following idea:

1) Encode without filter.

2) Encode the same source with a filter

3) Use SSIM and compare 1) with original and then compare 2) with original on each frame

4) Make a final third encoding and select filter or not filter on each frame of the original depending on if ssim on 2) was better than ssim on 1) or not.

I think this could be useful when making VCD (or any other CBR encoding format) where the bitrate is fixed and cannot vary with the quality of the input. If it's applied on a VBR encoding then the bitrate distribution makes the final result more unpredictable I think.

Do you think this could be a good method to improve the quality and can it be done with ssim and avisynth? Could it also be done with more than two encodings with serveral levels of filtering, always choosing the best filter combination on each frame depending on which encoded clip that had best ssim value?

I got the idea after reading shodan's rezising selecting script. But his script does not check the results after encoding when another resizer is applied and I want to select the best one on each frame based on results after encoding. But I don't exactly know how to code it in avisynth.

It would require several encoding passes (at least 3, two to compare with the original and one final) and is a little bit time consuming but if quality is very important maybe this does not matter.

[slk001]

How about attaching a "README.TXT" with the proper usage/syntax to the .DLL download?

[w2e3r4]

I have 3 questions:

1. What is the reason for scaling the result in the new version?
newValue=pow(oldValue,8)

2. How do I use ssim filter without actually doing the encoding and saving the avi file in VurtualDub? Is there an option to discard the output?

3. What colorspace should I use for the comparison?

Thanks,

[Manao]

Originally posted by w2e3r4
1. What is the reason for scaling the result in the new version?
newValue=pow(oldValue,8)It's just to make the range of variation of the value larger. For example, if oldValue was varying between 0.94 and 0.96, newValue will vary between 0.61 and 0.72. It's just easier to read the value that way, because with the previous version, values were ranging roughly from 0.92 to 0.99.2. How do I use ssim filter without actually doing the encoding and saving the avi file in VurtualDub? Is there an option to discard the output?Open your script in VDub, and hit the 'play' button ( or space key ). When the processing of the clip is finished, close the clip ( ctrl - w )3. What colorspace should I use for the comparison?YV12

[HLW]

Lefungus, this seems to be a great tool! I am using it for my master thesis where I compare different codecs. But I need to document what is happening in the algoritm. Is it possible to get information of what weighing values you use in the algorithm? I`ve read the "Video Quality Assessment Based on Structural Distortion Measurment" by Zang, Lu and Bovik. Have you used the values suggested by them?

By the way, any plans of implement support for more colorspaces, for instance 4:2:2?

Best regards

Haakon

[MfA]

As they say ... the code is it's own documentation ;)

But it uses the .8 .1 .1 weighting for the planes, luminance based weighting is implemented as suggested in the article (note that the SSIM results are the weighted average of SSIM values for blocks/frames though, so dark frames might have a low SSIM value anyway ... you have to look at the frame weight to see that that is not considered important). Motion based weighting is not performed at all.

4:2:2 would be easy to add, why dont you do it? :) (Be carefull though, this metric is really not designed for interlaced content ... although it will do in a pinch, but you should use seperatefields before applying it.)

Marco

[HLW]

I`m afraid thats outside my knowledge:), but if anyone is capable of it and wants to do it, I would be happy!:D . However, I have another comment: I've tested SSIM with the same clip both as target and reference. And the strange thing is that I don't get SSIM value 100 as I would expect, but only something close (96-98, depending on the clip). Does anyone have comments on that?

[MfA]

A comment ... hmmm, I should test my code better? :(

It is a bug, Ill take a look.

[Manao]

if(lumimask)
{
if (luminance)
{
frameSummedWeights = 0;
for (y = 0; y < height / 2; y++)
for (x = 0; x < width / 2; x++)
*(weights + y * strideUV + x) = 0.0f;
}
}
else
frameSummedWeights = (height - 7) * (width - 7);
If lumimask = true, and you're treating the chroma, you're not initializing properly the weights.

[MfA]

That's part of it, I just forgot for a moment that there are only (height-7)*(width-7) SSIM values in a luminance plane. So the divide coordinates by 2 trick will not map 4 weights in the luminance plane to 1 weight in the chroma plane.

[MfA]

Okay there is a slightly updated version here :

http://home.student.utwente.nl/m.f.al/ssim/

Ill verify if it gives the same results as the old one without lumimasking tomorrow ... and proof read it again. If anyone else wants to take a look Ill be glad for any help :)

[TorgoGuy]

Originally posted by MfA
Okay there is a slightly updated version here :

http://home.student.utwente.nl/m.f.al/ssim/

Ill verify if it gives the same results as the old one without lumimasking tomorrow ... and proof read it again. If anyone else wants to take a look Ill be glad for any help :)
I have only tried this test version and not the 0.23 version, but I think I have a bug to report.

AVS File:
=========
LoadPlugin("m:\proj\_plugins\ssimtest.dll")
a=AviSource("lotr1.avs")
b=AVISource("def.avi")
c=AviSource("GMCVHQ4.avi")
StackVertical(ssim(a,c,"ls_GMCVHQ4.csv","ls_GMCVHQ4.txt",lumimask=true),ssim(b,c,"ld_GMCVHQ4.csv","ld_GMCVHQ4.txt",lumimask=true))
Problem:
========
In the .csv files most lines look normal (with SSIM values and weight), but there are many blocks where the lines are just:
0.000000,0.000000
0.000000,0.000000
0.000000,0.000000
0.000000,0.000000
(that could be normal--not sure). The bigger problem seems to be that there are also many lines that look like this:
-1.#IND00,0.000009
-1.#IND00,0.000173
-1.#IND00,0.000559
where the SSIM column is always the same and the weight column varies somewhat.

Also, looking in the average SSIM file, it looks like this:
SSIM: Structural Similarity Index Metric 0.23
Average SSIM= -1.#J

Am I doing something wrong?

[MfA]

No, more bugs ... not dealing correctly with frames with near 0 weight on my part.

One more try, lets see if it works this time :

http://home.student.utwente.nl/m.f.al/ssim/

[TorgoGuy]

Thanks for the update. I'm rerunning the problem files. So far it looks like that bug is gone. All of the "0.000000" and "-1.#IND00" lines have been fixed so far.

I have a question regarding how the average value is calculated when using lumimasking. You explained that without lumimasking it is simply 100 * Pow(AvgSSIM, 8). With lumimasking, in place of "AvgSSIM" in the equation above do you use: ((the sum of (FrameSSIM * FrameWeight))/(the sum of the weights))?

Thanks a lot. To my eyes this (SSIM) does seem to be a very good quality measurement. Excellent work!

[TorgoGuy]

Originally posted by TorgoGuy
Thanks for the update. I'm rerunning the problem files. So far it looks like that bug is gone. All of the "0.000000" and "-1.#IND00" lines have been fixed so far.
Just a note to tell you that the problem files have been completed and the new version worked perfectly.

[Gannjunior]

Hi Lefungus,
thanks for your very useful dll.;)
I always used it without any problem.
Now I'm preparing a comparison between codecs and i'm testing neo divx 5.2: but i can't obtain logical values when i set Multiple adaptive bframes (with single adaptive there's no problem).I obtain, in each bitrate condition, a value of 3.71 %...As first thing, i've checked the synchrony of video in Vdub between source and encoded file and it's ok.
Only a strange thing: when i start vdub 4 comparison i can observe SSIM luminance component has big fluctuations... any idea to solve the problem?
Ah, I've also checked a little part inside the encoded file using trim, to avoid any (possibles) problems at the begin or at the end of encoded file caused by "strange" disposition of GOP in presence of multi adaptive bf (only a supposition...).

TIA

Ciao!:)

[Dams]

U should use .trim(1,0) on the source, because first frame of AVI files with B-frames are not readable.

[Gannjunior]

@Dams
I know the question about the cut of first frame, underlined by the same Lefungus in the first page of 3d, but the problem is about Xvid and its bframes...Divx hasn't got this problem.However, as i told in my message above, first, i'm speaking about divx, and, in particular, about 5.20.Second, as i underlined in my previous message, I've done differents attempts to calculate SSIM in presence of multiple bframes: from the cut of first frame to take a trim inside the encoded avi (for example: the avi is 1700 frames; i've tried to calculate SSIM on trim(10,1690), but I get a SSIM value with any significance...).

Does anybody want to try to calculate SSIM in divx 5.2, in presence of multiple bf?
Lefuuu!!! where r u?!?:(

ciaoo!:)

[Manao]

Gannjunior : it has nothing to do with SSIM. I made a PSNR test with DivX 5.2 without any problem at all, using trim(1,0), so try that solution again, you'll see that it's working correctly.

[Dams]

Same as Manao! :cool:

[Gannjunior]

Ok friends, It would been enough to tell me (from the begin) that SSIM is not compatible with divx 5.2 's multiple bf, stop. Obviously I've seen PSNR is perfectly calculable with divx 5.2 Multi bf, but i'm sure you know PSNR's limits...SSIM is not perfect, but, without any doubts, it takes into account better the images's strucutal similarity than PSNR, so obtained values are better agree to visual perceptions than PSNR. And it's what I need to value a particular setting as multiple bf...

ciao :)

[Lefungus]

SSIM is quite "dumb", it just compare frames that avisynth output.
If your frame order is broken, it'll give corrupted results.
I advise using stackvertical and vdub to manually check if frames between the two videos are actually correctly synchronized. If they're not, you just need to play with trim until it's correct.

[Gannjunior]

Hi Lefungus,
as I told in the first message, synchrony's check is first thing i've done.I 've tested 2 differents sources, and the problem is always the same.I've checked frame after frame the sync, but it was ok.
I've also noticed a thing in my last little test: at the moment i'm working on 7th chapter of blade runner and i've done differents tests on the first 1701 frames.I've obtained a complete encoding of all 1701 frames on a Q=2 test with muliple bf on.But I've obtained a 1700 frames encoding doing a 2pass encoding at low bitrate with multiple bf on.In the first case (saturation) the synchrony is perfect and i've checked frame after frame with my eyes.In second case (2pass low bitrate) it's been enough to trim(1,0) to obtain syncronization.And I've checked the SSIM in both cases obtaining values (half more ore less) too much low, compared to the same ecncoding wiht single bf.
I'm sure if you do a little attempt you can confirm my problem.

ciao!

[MfA]

A ridiculously low SSIM value will mean a low PSNR too, they dont correspond but they do correlate. If you want to post some clips it would be helpfull.

[Manao]

gannjunior : post your encoding script, and your script in which you compute the SSIM please.