Will there be quality loss for YV12-> RGB32 -> YV12 colorspace conversion?

[lansing]

if there is, will it be visible or just some mathematical rounding difference

[poisondeathray]

Yes, visibile quality loss

Whether or not you see it depends on many factors including the viewer and the type of content

Deterioration is more visible on things like graphics (like titles), anime , or content that has clear crisp color borders to begin with - there will be blurring

[sneaker_ger]

He's doing YV12-> RGB32 -> YV12, not RGB32 -> YV12 -> RGB32.

[poisondeathray]

He's doing YV12-> RGB32 -> YV12, not RGB32 -> YV12 -> RGB32.

Yes, there is still loss

Have you ever tried redoing a DVD menu or titles in an RGB program like photoshop, AE, video editors, ... etc? . It deteriorates noticably, edges becomes blurry, even before using lossy compression. It's due to color model (colorspace) conversion - the color information is upscaled then downscaled.

Other types of content, like fast moving live action, you typically won't notice unless you zoom in and go frame by frame

[sneaker_ger]

There may be rounding errors in the color conversions, but the chroma up- and downscaling can be lossless depending on the algorithm. If I use pointresize(), it's lossless. So it does not have to result in any blurriness.

[poisondeathray]

There may be rounding errors in the color conversions, but the chroma up- and downscaling can be lossless depending on the algorithm. If I use pointresize(), it's lossless. So it does not have to result in any blurriness.


Are you using ConvertToRGB(matrix="Rec601", interlaced=false, chromaresample="point") , (and back to YV12 using same thing) ?
or using some other chroma resampling method?

If you have time, here is a test video from a DVD menu for you . (The goal was to redo the text animating on, but the reason is not important). It's really an almost worst case scenario, because of thin red text.

Using "normal" ConvertToRGB.ConvertToYV12 routine (and then ConvertToRGB for the screenshot) . It's similar result in other programs which use slightly different chroma sampling methods


Comparisons:
Original YV12 (and RGB for screenshot)
http://i40.tinypic.com/1zofcjp.png

YV12=>RGB=>YV12 (and RGB for screenshot)
http://i40.tinypic.com/348ivbo.png

original .m2v
http://www.mediafire.com/?52xp6d7p5881fvo

[sneaker_ger]

He didn't mention AviSynth or any specific algorithm.

[poisondeathray]

He didn't mention AviSynth or any specific algorithm.

But you claimed it could be done without blurriness, so I'm interested in the how to do it (with any program)?

[sneaker_ger]

Untested:
ConvertToYV12(chromaresample="point")
ConvertToRGB32(chromaresample="point")

[poisondeathray]

Untested:
ConvertToYV12(chromaresample="point")
ConvertToRGB32(chromaresample="point")

Well I did test these before (and the other sampling methods), and for a YV12 source it should be:

ConvertToRGB32(chromaresample="point")
ConvertToYV12(chromaresample="point")

(and back to RGB , for consistency of the screenshots, I used same default ConvertToRGB() for the screenshot, which uses Bicubic in avisynth 2.6)

http://i41.tinypic.com/15dtlcz.png
Still some blurring - and introduces aliasing

[sneaker_ger]

I don't know where that error comes from. If you upscale using PointResize by factor 2 and downscale by factor 2 again, you get the same result. Either chromaresample="point" does not do what I think it does, or it has something to do with the MPEG-2-chroma-placement. Will try to make a test to reproduce the issue myself, but I stand by my original statement that this is algorithm dependent and it is possible to do it without additional blurriness, but not without color skewing (putting some edge cases aside).

[poisondeathray]

I don't know where that error comes from. If you upscale using PointResize by factor 2 and downscale by factor 2 again, you get the same result. Either chromaresample="point" does not do what I think it does, or it has something to do with the MPEG-2-chroma-placement. Will try to make a test to reproduce the issue myself, but I stand by my original statement that this is algorithm dependent and it is possible to do it without additional blurriness, but not without color skewing (putting some edge cases aside).

There was some discusion here about whether or not "PointResize" in avisynth was true nearest neighbor
http://forum.doom9.org/showthread.php?p=1569907

On a practical level, this loss occurs, even in other programs that use "nearest neighbor" - so how do it without bluriness or other detrimental effets like aliased edges in any program???

You can use the YV12 mpeg2 clip provided above in the mediafire link as a test example

[sneaker_ger]

You can use the YV12 mpeg2 clip provided above in the mediafire link as a test example

Yes, you are correct. I tested it with your sample and it looks horrible, indeed.

[natt]

yv12->yv24->yv12 can be lossless with pointresample of chroma, provided the algorithm is correct. avisynth's yv12->yv24 with chromaresample=point is rather incorrect.

Consider a set of 4 luma samples in 4:2:0. Place them on a coordinate plane with the top left one at (0, 0) and the bottom right one at (1, 1).

So MPEG1 chroma is (0.5, 0.5), and MPEG2 chroma is (0, 0.5).

Avisynth's yv24->yv12 chromaresample=point uses chromaloc (0,0). Due to the limitations of point resize, only luma cosited chroma is possible. This is ok.

Avisynth's yv12->yv24 chromaresample=point uses chromaloc (1.5, 1.5) for MPEG1, and chromaloc (0.5, 1.5) for MPEG2. This is wrong and makes no sense at all. MPEG1 can be exactly represented at (0.5, 0.5), and MPEG2 can be better represented with either (0.5, 0.5) or (-0.5, 0.5).

Using a correct MPEG1 yv12->yv24 would allow yv12->yv24->yv12 to be lossless.

[TheSkiller]

Thanks natt, I have wondered why RGB<->YV24 conversions were not lossless color wise using chromaresample=point - now I know why.

However, I'm not sure though and can't test it now but if memory serves me right there also was something fishy going on if doing an (interlaced) YV12<->YUY2/YV16 conversion using pointresize, meaning converting back and forth is not lossless as one would expect.

[poisondeathray]

Thanks natt, I have wondered why RGB<->YV24 conversions were not lossless color wise using chromaresample=point - now I know why.

However, I'm not sure though and can't test it now but if memory serves me right there also was something fishy going on if doing an (interlaced) YV12<->YUY2/YV16 conversion using pointresize, meaning converting back and forth is not lossless as one would expect.

But Natt was referring specifically to Y'CbCr conversions (YV12<=>YV24), not RGB<=>Y'CbCr conversions like the OP was referring to.

Y'CbCr <=> RGB conversions are lossy for other reasons beside chroma sampling. Y'CbCr and RGB are non overlapping color models. You can have out of range gamut even with Rec1361 wide gamut RGB transfer function. Also there are rounding errors - worse when the calculations are done in 8-bit. So even if you disregard chroma up/downscaling algorithms there are other reasons for loss

In practical terms, many programs use RGB/A internally, but very few use Y'CbCr 4:2:0 , and even fewer Y'CbCr 4:4:4. So it would benefit many people to find optimal way with minimal losses for Y'CbCr <=> RGB conversions. Right now you choose trade offs between chroma blurring vs aliasing and "blocky" color edges.

[Gavino]

yv12->yv24->yv12 can be lossless with pointresample of chroma, provided the algorithm is correct. avisynth's yv12->yv24 with chromaresample=point is rather incorrect.
Agreed it can be lossless with the appropriate algorithm, but it's debatable whether Avisynth's behaviour is incorrect (rather than simply not appropriate for this purpose).

It is consistent with the way PointResize works, which is to use, for each output pixel, the nearest source pixel looking above and to the left (hence not strictly 'nearest' neighbour, as it ignores nearer pixels below or to the right).
However, the effect is that YV12->YV24->YV12 using chromaresample="point" introduces a chroma shift.
But, as the original pixels are still preserved in YV24 (just in the 'wrong' place), this can be corrected by shifting them back before reconversion to YV12.

Thus,
ConvertToYV24(chromaresample="point")
MergeChroma(PointResize(width, height, 0, 1)) # mpeg2
# or MergeChroma(PointResize(width, height, 1, 1)) for mpeg1
ConvertToYV12(chromaresample="point")
is completely lossless.

See also posts #284-290 of this thread.

[lansing]

Well I did test these before
ConvertToRGB32(chromaresample="point")
ConvertToYV12(chromaresample="point")


So this way is the closest to a lossless conversion I can get from a YV12->RGB32->YV12 ?


I'm trying to use neat video with avisynth plugins. I tried to load it as a plugin in an avs, but it requires a converttoRGB32 before that.

[Gavino]

So this way is the closest to a lossless conversion I can get from a YV12->RGB32->YV12 ?
Since YV12<->RGB32 goes via YV24, this also gives rise to an effective chroma shift as I described above. To avoid this, do the conversion explicitly to YV24 and shift the chroma back before the conversion to RGB32.
ConvertToYV24(chromaresample="point")
MergeChroma(PointResize(width, height, 0, 1))
ConvertToRGB32()
... # filtering in RGB32
ConvertToYV12(chromaresample="point")
Then the only losses come from the YUV/RGB conversion (rounding, etc, as described by poisondeathray).

[lansing]

Since YV12<->RGB32 goes via YV24, this also gives rise to an effective chroma shift as I described above. To avoid this, do the conversion explicitly to YV24 and shift the chroma back before the conversion to RGB32.
ConvertToYV24(chromaresample="point")
MergeChroma(PointResize(width, height, 0, 1))
ConvertToRGB32()
... # filtering in RGB32
ConvertToYV12(chromaresample="point")
Then the only losses come from the YUV/RGB conversion (rounding, etc, as described by poisondeathray).

thanks for the help to all of you guys :cool:

And one more thing, if i ran neat video in virtualdub and output the result as lagarith lossless in YV12, before putting it into avs, will i get the same result as the avs conversion above?

[poisondeathray]

thanks for the help to all of you guys :cool:

And one more thing, if i ran neat video in virtualdub and output the result as lagarith lossless in YV12, before putting it into avs, will i get the same result as the avs conversion above?

No, it's slightly worse - I would do the conversion back in avisynth . Of course you can just as easily test it yourself. (There is even a sample video above with thin red text) . Whether or not the differences are enough to justify larger HDD storage demands for your goals is another discussion

I tested a bunch of combinations and different sources, and Gavino's suggestion seems the best overall in terms of least deterioration, blurring or aliasing for round tripping it (note there are situations when you may want "blocky" color edges e.g. some types of VFX work , and other times when you want smoother, chroma edges)

[lansing]

ok thanks for the explanation

[Soulvomit]

Is there a way of converting interlaced YV12 to RGB without the shift in chroma using chromaresample="point" and preserving the interlacing?

[Gavino]

Is there a way of converting interlaced YV12 to RGB without the shift in chroma using chromaresample="point" and preserving the interlacing?
The interlaced equivalent of my code in post#19 is:
ConvertToYV24(interlaced=true, chromaresample="point")
MergeChroma(PointResize(width, height, 0, 2))
ConvertToRGB32()
... # filtering in RGB32
ConvertToYV12(interlaced=true, chromaresample="point")

[Soulvomit]

Thanks for responding. I would like to point out though converting to YV24 isn't as lossless at it should be with AviSynth.

[Gavino]

I would like to point out though converting to YV24 isn't as lossless at it should be with AviSynth.
What do you mean by that?
Which case(s) are you talking about?
Certainly, conversion from RGB to YV24 (like any RGB-YUV conversion) is subject to rounding errors within 8-bit accuracy.

[Soulvomit]

Sorry, I should have specified. Yes, going from RGB to YV24 isn't as lossless with 'Synth as it is with VirtualDub.

[Gavino]

going from RGB to YV24 isn't as lossless with 'Synth as it is with VirtualDub.
Evidence?

Does VirtualDub even support YV24?

[Soulvomit]

Never mind. I tried RGB>YV24>RGB in 'Dub again and it isn't lossless. I could have sworn it was as I've done it before and was going by that.

[zee944]

I've a problem related to this. I've learned from this topic how to do YV12<-->RGB32 conversion without chroma shift, but in-between I have to do some cropping as well. When I use even numbers to crop, everything is fine:


ConvertToYV24(chromaresample="point")
MergeChroma(PointResize(width, height, 0, 1))
ConvertToRGB32()

Crop(10,104,-10,-100)

# ...filtering, etc...

ConvertToYV12(chromaresample="point")

# ...further filtering, etc...

AddBorders(10,104,10,100)


...but when I crop by odd values, things gets nasty:


ConvertToYV24(chromaresample="point")
MergeChroma(PointResize(width, height, 0, 1))
ConvertToRGB32()

Crop(10,105,-10,-99)

# ...filtering, etc...

ConvertToYV12(chromaresample="point")

# ...further filtering, etc...

ss=2
PointResize(width*ss, height*ss)
AddBorders(10*ss, 105*ss, 10*ss, 99*ss)
PointResize(width/ss, height/ss)


The cropping by odd numbers (and adding the borders back eventually with supersampling) leads to heavy chroma shift, very noticeably on the red parts. I suspect that the PointResize() is responsible for this, but I don't know how to avoid it. Can you help?

[IanB]

PointResize is also known as Nearest Neighbour.

There is no interpolation it chooses the value of the closest geographical pixel.

For YV12, if pixel 1 is red and pixel 3 is green, what colour will pixel 2 be? Let's assume Green, now crop off 1 pixel, pixel 2 becomes pixel 1, 4 becomes 3, etc. Oops we just shifted the chroma ....

[zee944]

PointResize is also known as Nearest Neighbour.

There is no interpolation it chooses the value of the closest geographical pixel.

Well I've tried replacing the last PointResize() with Lanczos4Resize(), which looked better but there was still chroma shift, so I abandoned it. It isn't the closest I can get, or is it?

[Asmodian]

It is the ConvertToYV12(chromaresample="point") that is the issue. Cropping by one half a color sample and using point resize is supposed to shift chroma, as IanB explained, no way around it.

This seems to not shift chroma and looks better with my test than the simple ConvertToYV12(chromaresample="lanczos"):
PointResize(last.width*2,last.height*2)
ConvertToYV12(chromaresample="point")
LanczosResize(last.width/2,last.height/2)


But I am at a loss to explain why, probably something to do with resizing the luma along with the chroma.

Better to crop in multiples of 2. ;)

I used this test script though ffdshow (YV12->NV12) and MadVR (0.85.1, nearest neighbor):
imagesource("red.png", pixel_type = "RGB32")
PointResize(30,30)
ConvertToYV12(chromaresample="point")
addborders(2,2,2,2)
ConvertToYV24(chromaresample="point")
MergeChroma(PointResize(width, height, 0, 1))
ConvertToRGB32()
Crop(0,1,0,-1)
PointResize(last.width*2,last.height*2)
ConvertToYV12(chromaresample="point")
LanczosResize(last.width/2,last.height/2)


An aside: For the same reasons you should not be using super sampling and point resize at the same time. Using point resize undoes the super sampling. I think your example would just add 106 to the top and 98 to the bottom.

[Gavino]

An aside: For the same reasons you should not be using super sampling and point resize at the same time. Using point resize undoes the super sampling. I think your example would just add 106 to the top and 98 to the bottom.
Not exactly.

The purpose of the supersampling is to end up adding borders with an odd number of pixels (here 105 and 99, matching the earlier Crop). This works for the luma, thus restoring the uncropped luma pixels to their original positions. However (and this is probably what you meant), it adds 53 chroma pixels to the top and 49 to the bottom, so chroma is shifted down by 1 luma pixel (2*53 - 105).

In addition, the earlier odd-numbered Crop has introduced a shift of its own, amounting to 1 luma pixel, so the final result has a shift of 2 luma pixels.

However, as this is an even number (and we have a YV12 clip), it can be easily corrected by adding a final
MergeChroma(PointResize(width, height, 0, 2))

Thus the following sequence is completely lossless (except of course for the pixels cropped off).
ConvertToYV24(chromaresample="point")
MergeChroma(PointResize(width, height, 0, 1))
#ConvertToRGB32() removed to make completely lossless

Crop(10,105,10,-99)

ConvertToYV12(chromaresample="point")

ss=2
PointResize(width*ss, height*ss)
AddBorders(10*ss, 105*ss, 10*ss, 99*ss)
PointResize(width/ss, height/ss)
MergeChroma(PointResize(width, height, 0, 2))

[Asmodian]

I thought it had to move the chroma without interpolation.

Oh, I see. You moved the chroma back after making the video mod2 again! Seems so obvious now. Thanks. :)

edit: it is somewhat embarrassing how well I feel I understand YV12, point resize, etc. and how bad I am at seeing the (in retrospect, at least) obvious consequences. :o

You are also right, I was only thinking about the chroma when looking at supersampled addboarders (but I didn't think I was). :o

[zee944]

Nice, this works, thanks Gavino.

However, it's quite frustrating that I have to remember how I cropped the image earlier (by even or by odd values), then figure out if even or odd borders I want to add now and act accordingly. Can the colorspace conversions and cropping/adding borders be separated with a well-thought out function? I mean, to do a color conversion anytime, adding/cropping anytime by any values without taking into account what and how happened before, yet keep the chroma intact all the time?

[Gavino]

Oh, I see. You moved the chroma back after making the video mod2 again! Seems so obvious now. Thanks. :)

edit: it is somewhat embarrassing how well I feel I understand YV12, point resize, etc. and how bad I am at seeing the (in retrospect, at least) obvious consequences. :o
If it's any consolation, I don't think it's very 'obvious'.
I had to sit down with pencil and paper and trace out where the individual chroma pixels went at each stage of the process, getting quite confused until I was finally sure I had worked it out correctly.

Can the colorspace conversions and cropping/adding borders be separated with a well-thought out function? I mean, to do a color conversion anytime, adding/cropping anytime by any values without taking into account what and how happened before, yet keep the chroma intact all the time?
I'm not sure if that's possible. I'll need to think about it for a while and my head still hurts after the earlier effort. :)

[Gavino]

Can the colorspace conversions and cropping/adding borders be separated with a well-thought out function? I mean, to do a color conversion anytime, adding/cropping anytime by any values without taking into account what and how happened before, yet keep the chroma intact all the time?
I might be able to come up with something that could help you, but before I spend more time thinking about it, are you really sure your images are so precise that you need to crop by 105 instead of 106 or 104?
It would certainly be simpler just to restrict your crops to even numbers.

[zee944]

I might be able to come up with something that could help you, but before I spend more time thinking about it, are you really sure your images are so precise that you need to crop by 105 instead of 106 or 104?

For anyone else, no - it's pretty poor material noone else would care about. As for me, if there would be no general solution I would still crop by 105 and use your chroma-merging trick somehow. Your posts have helped me tremendously in the past, and I'm sure I'll ask for help in the future, so don't spend time with this one, at least not yet. The by-pass (the chroma-merging trick) has already been covered, I'll try to use that. :)

[Gavino]

@zee944: Strange how the mind works - while thinking about something else, a relatively simple solution to your problem occurred to me...

You can use these customised wrapper functions for Crop and AddBorders which together produce the right results for both even and odd crop values.
function MyCrop(clip c, int left, int top, int right, int bottom) {
topc = top%2 == 0 ? top : top+1
bottomc = (bottom > 0 || top%2 == 0) ? bottom : bottom+1
c.Crop(left, top, right, bottom)
top%2 !=0 ? MergeChroma(c.Crop(left, topc, right, bottomc)) : last
}

function MyAddBorders(clip c, int left, int top, int right, int bottom) {
ss = top %2 == 0 ? 1 : 2

c
PointResize(width*ss, height*ss)
AddBorders(left*ss, top*ss, right*ss, bottom*ss)
PointResize(width/ss, height/ss)
}
In outline, your script would look like this:
ConvertToYV24(chromaresample="point")
MergeChroma(PointResize(width, height, 0, 1))

MyCrop(10,105,-10,-99) # must do in YV24, so BEFORE RGB conversion

ConvertToRGB32()

# ...filtering, etc...

ConvertToYV12(chromaresample="point")

# ...further filtering, etc...

MyAddBorders(10, 105, 10, 99)
The (vertical) crop values can then easily be changed from odd to even without changing the rest of the script.
It works by ensuring that the chroma is always cropped with an even value, even if the luma is cropped with an odd value.

[zee944]

Will try that, but meanwhile I have figured out an alternative way I'm rather excited about. Since I wanted a fool-proof method which can be used anywhere and anytime (sometimes I do adding/cropping in RGB32 space too), I thought that I could compare the luma and chroma edges after every "risky" operation, check the possible variations and choose the best match.

This is the raw idea. Using these customized functions for every operation worked alright so far (but I haven't tested fully yet):

function FixChroma(clip clp)
{
clp
GScriptClip("""
LumaEdges=GreyScale().mt_edge("sobel", U=2, V=2)
ChromaEdgesN6=MergeChroma(PointResize(width, height, 0,-6)).UToY.PointResize(width, height).mt_edge("sobel", U=2, V=2)
ChromaEdgesN4=MergeChroma(PointResize(width, height, 0,-4)).UToY.PointResize(width, height).mt_edge("sobel", U=2, V=2)
ChromaEdgesN2=MergeChroma(PointResize(width, height, 0,-2)).UToY.PointResize(width, height).mt_edge("sobel", U=2, V=2)
ChromaEdges00= UToY.PointResize(width, height).mt_edge("sobel", U=2, V=2)
ChromaEdges02=MergeChroma(PointResize(width, height, 0, 2)).UToY.PointResize(width, height).mt_edge("sobel", U=2, V=2)
ChromaEdges04=MergeChroma(PointResize(width, height, 0, 4)).UToY.PointResize(width, height).mt_edge("sobel", U=2, V=2)
ChromaEdges06=MergeChroma(PointResize(width, height, 0, 6)).UToY.PointResize(width, height).mt_edge("sobel", U=2, V=2)
subtitle("no shift")
AverageLuma(Overlay(LumaEdges, last.UToY.PointResize(last.width, last.height).mt_edge("sobel", U=2, V=2), mode="subtract"))
\> AverageLuma(Overlay(LumaEdges, ChromaEdges06, mode="subtract")) ? clp.MergeChroma(clp.PointResize(width, height, 0, 6)).subtitle("shift +6") : last
AverageLuma(Overlay(LumaEdges, last.UToY.PointResize(last.width, last.height).mt_edge("sobel", U=2, V=2), mode="subtract"))
\> AverageLuma(Overlay(LumaEdges, ChromaEdges04, mode="subtract")) ? clp.MergeChroma(clp.PointResize(width, height, 0, 4)).subtitle("shift +4") : last
AverageLuma(Overlay(LumaEdges, last.UToY.PointResize(last.width, last.height).mt_edge("sobel", U=2, V=2), mode="subtract"))
\> AverageLuma(Overlay(LumaEdges, ChromaEdges02, mode="subtract")) ? clp.MergeChroma(clp.PointResize(width, height, 0, 2)).subtitle("shift +2") : last
AverageLuma(Overlay(LumaEdges, last.UToY.PointResize(last.width, last.height).mt_edge("sobel", U=2, V=2), mode="subtract"))
\> AverageLuma(Overlay(LumaEdges, ChromaEdges00, mode="subtract")) ? clp.MergeChroma(clp.PointResize(width, height, 0, 0)).subtitle("no shift") : last
AverageLuma(Overlay(LumaEdges, last.UToY.PointResize(last.width, last.height).mt_edge("sobel", U=2, V=2), mode="subtract"))
\> AverageLuma(Overlay(LumaEdges, ChromaEdgesN2, mode="subtract")) ? clp.MergeChroma(clp.PointResize(width, height, 0, -2)).subtitle("shift -2") : last
AverageLuma(Overlay(LumaEdges, last.UToY.PointResize(last.width, last.height).mt_edge("sobel", U=2, V=2), mode="subtract"))
\> AverageLuma(Overlay(LumaEdges, ChromaEdgesN4, mode="subtract")) ? clp.MergeChroma(clp.PointResize(width, height, 0, -4)).subtitle("shift -4") : last
AverageLuma(Overlay(LumaEdges, last.UToY.PointResize(last.width, last.height).mt_edge("sobel", U=2, V=2), mode="subtract"))
\> AverageLuma(Overlay(LumaEdges, ChromaEdgesN6, mode="subtract")) ? clp.MergeChroma(clp.PointResize(width, height, 0, -6)).subtitle("shift -6") : last
""", args="clp", local=true)
}

function smartConvertToRGB32(clip c) {
c
ConvertToYV24(chromaresample="point")
MergeChroma(PointResize(width, height, 0, 1))
ConvertToRGB32()
}

function smartConvertToYV12(clip c) {
c
ConvertToYV12(chromaresample="point")
}

function smartAddBorders(clip clp, int l, int t, int r, int b) {
clp
ss=2
PointResize(width*ss, height*ss)
AddBorders(l*ss,t*ss,r*ss,b*ss)
PointResize(width/ss, height/ss)
IsYUV ? last : clp.AddBorders(l, t, r, b)
}

function smartCrop(clip clp, int l, int t, int r, int b) {
clp
ss=2
PointResize(width*ss, height*ss)
Crop(l*ss,t*ss,-1*abs(r)*ss,-1*abs(b)*ss)
PointResize(width/ss, height/ss)
IsYUV ? last.FixChroma : clp.Crop(l, t,-1*abs(r),-1*abs(b))
}

Still need a few advices:

1. Is "UToY.PointResize()" and "VToY.PointResize()" (later) right? Will the chroma subtituting pixels be at their right place, and not shifted by one or half pixel in any direction?

2. Should I merge the edge mask of U and V (not just U)? Sometimes when the image has dull colors, none of them has enough edges to work with, though.

3. Would it be enough to check only +2 (or zero) shift all the time? Can the correction be different than +2 after numerous conversions and border operations?

4. I happened to notice that my source (DVD 720x480) has a chroma shift to begin with. "MergeChroma(PointResize(width, height, 0, 2))" is too much, "MergeChroma(PointResize(width, height, 0, 1))" would be ideal if there would be such thing as 1 pixel shift in YV12. Is replacing PointResize() with Lanczos4Resize() an accepted solution for that?

[Kein]

yv12->yv24->yv12 can be lossless with pointresample of chroma, provided the algorithm is correct. avisynth's yv12->yv24 with chromaresample=point is rather incorrect.
Were there any changes on this field in avs' chromaresample since then?

Also, does anyone by any chance know what method Sony Vegas uses when converting imported media to RGB in its own editing space?


[...] leads to heavy chroma shift, very noticeably on the red parts.
I also have a bit similar problem with red shift (http://forum.doom9.org/showpost.php?p=1711974&postcount=514), but of different origin, any idea how to combat it (crop by even values)? I've been told that upscaling by 1.25 factor causes this and there is no way to avoid it. Colorspace conversion does not happen (all being kept in YvV2).

[colours]

Were there any changes on this field in avs' chromaresample since then?

Unfortunately Avisynth's PointResize semantics are plain wrong and will never be changed because it needs to keep backwards compatibility with all the scripts that utilise these wrong semantics (e.g. some old versions of Destripe).

[Warperus]

what method Sony Vegas uses when converting imported media to RGB in its own editing space?It's a bit a of mess actually if you are asking about color transformation
http://www.glennchan.info/articles/vegas/v8color/vegas-9-levels.htm

Also add automatic deinterlace, pull down removal, external quicktime, vfw filters etc.

As for resize, it's bilinear or bicubic in pan/crop and track motion.