Weird chroma placement

[titlis]

I was testing ResampleHQ
and compare it with various Avisynth's built-in resizers, and I've found somewhat weird behaviour while testing Chroma Kernel.




This (http://imageshack.us/photo/my-images/46/victoriatd.jpg/) is the Original JPEG image,

and tested with 3 scripts, here they are


ImageReader("D:\Documents and Settings\user\My Documents\victoria.jpg")
Crop(0,3,0,0)
ResampleHQ(200,300,"YV12",chroma_kernel="spline36")
utoy()


ImageReader("D:\Documents and Settings\user\My Documents\victoria.jpg")
Crop(0,3,0,0)
ConvertToYV12(chromaresample="spline36")
Spline36Resize(200,300)
utoy()


ImageReader("D:\Documents and Settings\user\My Documents\victoria.jpg")
Crop(0,3,0,0)
Spline36Resize(200,300)
ConvertToYV12(chromaresample="spline36")
utoy()


And each one of them has different chroma placement.
where is the problem and what is the 'normal chroma placement'?

[Gavino]

each one of them has different chroma placement.
Do you mean that there is a positional chroma shift relative to luma or simply that the chroma values come out differently in each result?

Certainly, I would expect to see chroma differences between each case. ResampleHQ uses a gamma-aware method, whereas Avisynth is strictly linear. Even the two Avisynth methods will give slightly different results because the chroma resampling is arrived at in two stages by two different routes:

Case 1
RGB Original 600x900
To YV12 300x450
Resize to 100x150

Case 2
RGB Original 600x900
Resize to 200x300
To YV12 100x150

However, I would expect the chroma positioning for the two Avisynth methods to be the same.

A possible difference with ResampleHQ is that Avisynth resizers preserve the image centre position. I don't know if ResampleHQ does the same - perhaps it is designed to preserve some other point instead (eg top left corner). If so, the resultant images will have a relative shift between them (although this should affect both luma and chroma equally).

what is the 'normal chroma placement'?
See here (http://avisynth.org/mediawiki/Sampling#mpeg-1_versus_mpeg-2_sampling).

[titlis]

Thanks for the reply

I've just made a test and found luma positioning is identical for all 3 scripts.
( zoomed and compared... as far as my eyeball is intact, luma is identical )

but 3 of them has different chroma and I don't know the reason.
I don't think the difference is significant but It's not bad to try to be perfect.

[Gavino]

3 of them has different chroma and I don't know the reason.
I don't think the difference is significant but It's not bad to try to be perfect.
Are you saying that you see differences in chroma position between the three clips, or simply slight differences in color?
As I explained, I would expect (slight) color differences, but there should be no difference in position if the filters are working correctly. Regarding luma, it should be exactly the same between the two Avisynth cases (as it is unchanged by the Convert operation), but I would expect it to differ slightly in ResampleHQ because of the different treatment of gamma.

[titlis]

I mean differences in chroma position.
each one of them has slightly shifted chroma.
though It's hardly noticable

[SEt]

There is no one single standard chroma position. For example even Avisynth 2.5 and 2.6 defaults differ here.

[Gavino]

Avisynth 2.5 and 2.6 defaults differ here.
Which defaults are different?

[SEt]

2.5 used MPEG1 while 2.6 uses MPEG2 placement by default as I remember.

[Gavino]

2.5 also uses MPEG2 - see
http://avisynth.org/mediawiki/Sampling#mpeg-1_versus_mpeg-2_sampling

In fact, you can't really talk about a 'default' in 2.5, since it just assumes MPEG2 and there's no way to change it.

[SEt]

Try yourself - I clearly see 2.58 uses MPEG1. 'Defaults' is about 2.6 of course.

[titlis]

Then, which is 'widely adapted' standard right now? MPEG2? or MPEG1?

[Gavino]

Try yourself - I clearly see 2.58 uses MPEG1.
Where do you see this then?

[SEt]

Played with random build of 2.58 some more, results: YV12->RGB uses MPEG2, while RGB->YV12 uses MPEG1.

titlis, it's a mess now since not many care for correct chroma placement. Newer software is defaulted to MPEG2 I think.

[Gavino]

Played with random build of 2.58 some more, results: YV12->RGB uses MPEG2, while RGB->YV12 uses MPEG1.
The latter is due to a bug (or at any rate an accepted deficiency from a performance shortcut) in conversion from RGB to YUY2 - see here. As I said, the documentation states Avisynth uses MPEG2 and that is reflected in the conversions to and from YV12.

Having said that, there is also a problem with the horizontal resizers which behave (unintentionally, I believe) as if MPEG1 is assumed - see this post and the subsequent discussion there up to post #392. So yes, it is a bit of a mess.

Newer software is defaulted to MPEG2 I think.
That's right.

[titlis]

Okay I see

Then ConvertToYV12() Function use inaccurate interpolation for speed issue?
But, how can I explain ResampleHQ chroma shifting?
I think it's a bug too. ( or not since I'm not an expert :p )

[SEt]

In 2.6 ConvertToYV12 works correctly, don't fear the alpha state of 2.6 - it's still better than old bugs of 2.58. (And honestly, I can't consider 'MPEG2 with performance shortcut' as MPEG2 when it's actually MPEG1.)

[Gavino]

Then ConvertToYV12() Function use inaccurate interpolation for speed issue?
In Avisynth 2.58, ConvertToYV12() for RGB input goes via YUY2 as an intermediate step, so suffers from the problem I mentioned above. However, you are using v2.60, which goes instead via YV24, so that problem does not apply.

In your case, I think the differences between the two Avisynth examples are due to the horizontal resizing bug also mentioned above. I had forgotten about this (despite being involved in the diagnosis and discussion!) when I originally replied to your questions.
This only affects YV12, so doing the resize before the conversion gives correct chroma alignment, while doing it after produces a small horizontal chroma shift.
But, how can I explain ResampleHQ chroma shifting?
I think it's a bug too. ( or not since I'm not an expert :p )
I don't know about that.
Perhaps the author will reply, or you could report the problem in the ResampleHQ thread.

[Gavino]

I can't consider 'MPEG2 with performance shortcut' as MPEG2 when it's actually MPEG1.
I know it's academic, since in practice it amounts to the same thing, but my point was that (AFAIK) it wasn't done with the intention of producing MPEG1. Avisynth is still specified to use MPEG2 - it's just that some parts of the implementation produce what looks like MPEG1. :)

[titlis]

Thanks for all the reply

You guys are outstanding! :goodpost:

[titlis]

Oh some more question


In 2.6 ConvertToYV12 works correctly, don't fear the alpha state of 2.6 - it's still better than old bugs of 2.58. (And honestly, I can't consider 'MPEG2 with performance shortcut' as MPEG2 when it's actually MPEG1.)

According to this (http://avisynth.org/mediawiki/Sampling) page of wiki, Avisynth has This is technically wrong and results in a 0.5 pixel right shift of the chroma, but it was originally done for performance reasons. this problem,
and This implementation results in a chroma shift. AviSynth uses a different interpolation as the one suggested by the mpeg-2 specs (perhaps due to speed issues)
this problem.

Are those all fixed in V2.60?

[Gavino]

I believe the first one (horizontal shift in RGB->YUY2) is fixed in 2.60a3.

The second one (mixed vertical shift in interlaced YV12->YUY2) still exists unless you explicitly use at least one of the new parameters chromaResample or chromaInPlacement.

[titlis]

That makes my mind much clear.

Once again, Thanks! :)

[Gavino]

A small clarification just to get the details right.
Previously, I said:
In your case, I think the differences between the two Avisynth examples are due to the horizontal resizing bug also mentioned above. ... This only affects YV12, so doing the resize before the conversion gives correct chroma alignment, while doing it after produces a small horizontal chroma shift.
What I meant was, it doesn't affect RGB.
It does affect all horizontally subsampled YUV formats (YUY2, YV16 and YV411, as well as YV12, but not YV24).
For more details, see this post.

[titlis]

We can quantify the shift as follows.
For YV12 and YUY2, the chroma centre is 0.5 luma pixels to the left of the luma centre.
When resizing from width Win to Wout, output pixel spacing in terms of input is multiplied by Win/Wout.
Hence the net (rightwards) chroma shift is a distance of 0.5*(1-Win/Wout) input luma pixels.
For a 2x upsize, this equals 0.25, for a 2x downsize it's -0.5 (ie 0.5 to the left).
Does this mean that we can know and correct chroma shifting likeMergeChroma(Spline36Resize(0, 0, width(), height(), 0.5, 0, width(), hegith())
this?

[Gavino]

Yes, although you've got two extra zeroes in your Spline36Resize call (and the last 3 parameters can be defaulted too).

Your original script had a 3x downsize, so the shift is 0.5*(1-3) = -1.0.
So you could replace Spline36Resize(200,300) by:

Spline36Resize(200, 300).MergeChroma(Spline36Resize(200, 300, -1.0))

to remove the shift.

[titlis]

Crop(0,3,0,0)
ConvertToYV12(chromaresample="spline36")
Spline36Resize(200,300).MergeChroma(Spline36Resize(200, 300, -1.0))
utoy()
Crop(0,3,0,0)
Spline36Resize(200,300)
ConvertToYV12(chromaresample="spline36")
utoy()

Yes, although you've got two extra zeroes in your Spline36Resize call (and the last 3 parameters can be defaulted too).
yes My mistake :p I thought it was Crop

Now I have both identical chroma placement
Thanks to all your reply

[Gavino]

Now I have both identical chroma placement
That's good to know, as it removes any doubts, confirming that the horizontal resize was indeed the source of the problem.

[TheSkiller]

Just to make sure, does this in fact mean that any YV12/YUY2 (and others) based resize with horizontal resizing involded does produce a horizontal chroma shift in 2.58 as well as 2.6?! If yes I'm quite shocked. :eek:

[Gavino]

Yes it does (although there are no other YUV formats in 2.58).
Also affects previous versions too (perhaps all of them, I don't know).

It's surprising no-one realised it until recently, but it is quite hard to see for most real-world images, unless you have a very large resize factor (and then other artefacts come into play anyway).

[mandarinka]

Are there any plans to adress this resize bug? Or would it require too much work for a hard-to-tell glitch, given the available resources?