YV12 rezising -> darker image

sometimes it seems to me that my rezised movies are looking darker than the original dvds. my AVISynth2.5 script: ---------------------------------------------------------------- Source=mpeg2source("D:\_DVDs\Oceans11\dvd2avi.d2v") Source2 =Source.crop(88,76,544,422) #720,422 movie =Source2.trim(325,160800).Convolution3D(0,3,4,3,4,2.8,0) credits =Source2.trim(160801,167999).Convolution3D(1,8,8,8,8,8,0) movie+credits BiCubicResize(544,304) ----------------------------------------------------------------- i don't know much about the backround of YV12 colorspace. can it be, that rezising in YV12 results in a darker looking image? i read i this forum that encoding with divx5 the encodet movie is around 15% darker than the original, but they never wrote anything about colorspaces or why it's darker.

I have as good as no experience in encoding ... but, from a theoretical point of view performing resizing in gamma corrected space will result in what can best be described as contrast reduction. Try putting "levels(0, .5, 255, 0, 255)" in front and "levels(0, 2, 255, 0, 255)" after the resizing. Doing gamma correction on luminance only isnt quite right either, but it should be enough to let you see if this is the problem. I kinda doubt it, since Ive never seen anyone saying this is an issue ... but who knows.

There is no image changes across resizes. Use "coloryuv(analyze=true)" at the different places in the script to confirm this. (Look at the first Average value, which is luma). Ask about DivX5 in the appropriate forum. (It would however surprise me _very_ much if this was the case!)

The average value seems correct, but averages should in principle always be taken in linear colour space. If you take averages in gamma corrected colour space, the perceived average will be too dark. This is easy to show : Lets assume we are using a 4->1 box filter for resizing, and further that for 4 pixels the (gamma corrected) values from an image are [64, 64, 64, 0]. If you directly apply the box filter, the pixel in the resized image will have a value of 48 and the value we actually perceive on the screen is 48^gamma. If we actually look at the original pixels on screen though we see pixels with values of [64^gamma, 64^gamma, 64^gamma, 0]. So the value for the pixel in the resized image we should see on the screen should have a value of 3*64^gamma/4, which is substantially brighter than 48^gamma. The levels commands in my previous post wont work of course ... I belatedly realised avisynth does not have the internal precision to be able to work in linear colour space :( To do resizing in linear colour space you would have to adapt the resize filter itself. This was a big enough issue for ATI to use inverse-gamma correction before and renewed gamma correction after the averaging they use in their anti-aliasing for instance (same issue, slightly different application). For 3D cards of course the operation should be transparant, since you dont want users to have to adapt image controls merely for turning on anti-aliasing ... we can always just try to tweak the settings to remove the darkening effect if it is irritating, but it does exist.

A box filter is a form of resize, with 4->1 box filter I meant one which simply takes the average of 4 pixels. The original 4 pixels would have the values [64^gamma, 64^gamma, 64^gamma, 0] on the screen because of the monitor gamma, so the pixel in the resized image which represents those 4 original pixels after the box filter should have the value (64^gamma + 64^gamma + 64^gamma + 0)/4 on the screen. Which is the same as 3*64^gamma/4. You cant exactly remove the artifacts from performing resizing in gamma corrected space, you simply have to tweak gamma/contrast/brightness till it looks approximately right. If you dont want to do the tweaking convince someone to write a resize filter which works in linear colour space :) (It would have to apply inverse gamma correction before resize and reapply gamma correction afterwards, preferrably in RGB ... optionally only on luma.) BTW I dont know if this effect is sufficiently noticable to really be your problem, you might be doing something else wrong entirely :)

thanks for your explainations MfA