Resize(height, width, crop) on YV12

[bxyhxyh]

Can I use LanczosResize(1280,720,2,3,-3,-2) on YV12

Or I have to ConvertToRGB() before this case?

[TheSkiller]

It works correctly in YV12, no problem.

[manono]

Can I use LanczosResize(1280,720,2,3,-3,-2) on YV12

Or I have to ConvertToRGB() before this case?
It'll work. But you'll screw up the chroma in the process. There's a reason for the crop rules:

http://avisynth.org/mediawiki/Crop

[bxyhxyh]

It'll work. But you'll screw up the chroma in the process. There's a reason for the crop rules:

http://avisynth.org/mediawiki/Crop

So which one is safer?

ConvertToRGB()
Crop(2,3,-3,-2)
LanczosResize(1280,720)
ConvertToYV12()


or first one?

[TheSkiller]

@ manono are you sure the crop rules, referring to crop(), apply to the internal cropping abilities of a resizer as well?
I maybe wrong, but I thought using the internal cropping these rules don't apply, i.e. chroma is fine. But the internal cropping has it's own quirk – it's not exactly suited to crop excess pixels like black bars.

For cropping off hard artifacts like VHS head noise or letterbox borders always use Crop. For extracting a portion of an image and to maintain accurate edge resampling use the resize cropping parameters.

[Gavino]

@ manono are you sure the crop rules, referring to crop(), apply to the internal cropping abilities of a resizer as well?
I maybe wrong, but I thought using the internal cropping these rules don't apply, i.e. chroma is fine.
You are right. The restrictions only apply when explicitly using the Crop() function. The resizers are able to do sub-pixel resampling so that the correct chroma alignment is maintained.

[manono]

I was going by an old post of sh0dan's after 'knowing' you couldn't do it even within the resizer itself:
"But what about the left and right crop values having to be the same as stated in number 2)? Is this due to the colorspace of YV12 as well?"

There is only chroma every second pixel - if you crop at odd numbers on either side, chroma will be shifted a pixel.
Therefore it is not possible to crop odd numbers without resampling chroma (which is done in the resizer).
http://forum.doom9.org/archive/index.php/t-51923.html

I guess things have changed since then. Or I misunderstood the implications of cropping while resizing. I apologize for contradicting you, TheSkiller.

[Gavino]

I was going by an old post of sh0dan's after 'knowing' you couldn't do it even within the resizer itself:
sh0dan's point was that if you want to crop at odd boundaries, you have to use the resizer (which does the necessary resampling).

[IanB]

A trick worth mentioning in regards to the hard cropping done by crop and the windowed cropping done by the resizers is to use the resizer to do the resampling and cropping but with mod N extra guard pixels that are subsequently hard cropped off. E.g :-...Source(...) # YV12
Spline16Resize(710+8, 558+8, 5-4, 9-4, 715+4, 567+4)
Crop(4, 4, -4, -4)The number of guard pixels should be greater than the number of the resizers taps.

For bonus points if the intent is to actually resize then the input cropping guard amounts needs to be scaled by the resize factor. Remember the resizer input cropping values are floats.