Divx Quality Index

[pcsl999]

"Divx Encode Index" is a encoding quality reference. It is a ratio between pixels & bytes/frame. Large pixels need more bytes/frame to get good quality.

http://www.geocities.com/divxqi

[gldblade]

>Large pixels

???
I presume you're talking about resolution instead of pixel sizes.

[movmasty]

gldblade, im surprised!

dont you know that 45% of pixels in USA are overweighted(fat)?

[movmasty]

talking more seriously,
those guys at DivxQI make the same error of GKnot,
that is to divide bytes/pixels to achieve a quality index.

but....
the relation between screen size and bytes needed to encode is NOT linear.

make this test: compress a small mono-colour pic in jpg,
will take only few bytes,those needed to say to repeat the same colour for the number of pixels;
now compress a similar pic but 100 times larger.....
YOU WILL GET THE SAME SIZE!

size will grow proportionally to number of pixels only in the ideal case of each pixels very different from all others,thus not compressable.

real cases are somewhat half way,
in my tests i got a size 2.25 times larger when pixels were x4,this is something more than the square root.

then why if default cif res for VCD(352/288) is 1151kb/s
the 4 times higer res of dvd-mpg2(704/576) is 5000kb/s?
that is 4.34 times bigger, more than proportional.

because isnt just the screen size, quality gets higer settings too.

in fact some mpg encoder has the option to encode cif mpgs at 2146kb/s
i guess that this is equivalent to the dvd quality
and if you divide 5000/2146 you get 2.33,
that i thinkis the right ratio to multiply bytes when linear size doubles(and pixels go x4).

[pcsl999]

movmasty, you may wrong; JPEG is linear during screen size and bytes.

please check this sample
http://www.garnerhk.com/imgs/jpeg01.jpg
http://www.garnerhk.com/imgs/jpeg02.jpg

jpeg01.jpg => 451KB 2000x2000pixels
jpeg02.jpg => 28.6KB 500x500pixels

screen size & bytes rule:
(2000x2000)/(500x500) = 16
image size is 16 times larger
If jpeg02.jpg = 28.6KB,
jpeg01.jpg = 28.6 x 16 => 457.6KB

This simple rule show a very closest preview result before compression (451 <-> 457.6 +/-1.5%).

[movmasty]

my friend, your is a very funny post
when i say compress a larger image, i mean the SAME image bigger
NOT the same small image repeated n times!
in fact no one resizes an image adding some piece of it...

that i said applies to the same image at different resolutions,es. the same pic at 352x192 and at 704x384,
but if you have a pic at 704x384 showing the image at 352x192 PLUS other details at the sides, obviously compression will be proportional.
look....

to make jpeg03 ,i loaded your jpeg02,then i found the compression level that gave me the same size(40%)
then i resized the pic(with bicubic filter,no details loss then),
the size is 187kb =28.6x6.53.....

(btw, with bilinear resize size was 180kb)

[gldblade]

>in fact no one resizes an image adding some piece of it...

You can't make that statement. Maybe pcsl999 does. You never can tell. :)

@pcsl999

(Ignore the above statement)

Your test is somewhat valid IF you repeat entire portions of the frame to get the right resolutions. I don't think you do that for DVD rips, so your test doesn't apply to DVD rips (and most other applications).

"DivX Encode Index" can be used as an indicator, but nothing beyond that. As has been said, the relationship between filesize and resolution is not linear. I have a 40x40 image that is 30kb and a 400x400 image that is about 1kb. If the relationship between filesize and resolution was linear, than this could not be so. Yet this type of thing does occur (and quite often I might add). "DivX Encode Index" CAN be used as an indicator, but in many cases is very inaccurate, especially due to the complexity of DVD movies.

(How could I possibly have a 400x400 image that is 1kb? It's almost completely black.)

[movmasty]

but still you dont understand me....
i was not talking about big and small images,
but about the same image at different res.
then the relationship between filesize and resolution is not linear,
and if you are going to make a movie at half linear size,
divide bytes per 2.5, or near it.

[PeterTheMaster]

you might be talking of the file size exponent steady came up with ages ago.
i still use it in my excel sheets to calculate the final resolution after making 2 short tests at 2 different resolutions.

[Hanty]

I find it deceptive to put "Quality" in the title of the app that way. Quality is something the eye can only judge alone. There are no guarantees that the encodes that get high ratings with this program are actually god to look at, so take that "quality" part with a pinch of salt.