converttorgb() versus converttorgb(interlaced=true)

[Katie Boundary]

If converttorgb() is applied to an interlaced image, an interesting and very noticeable artifact appears. It looks similar to interlacing, except that the "scanlines" are two pixels thick instead of one.

If converttorgb(interlaced=true) is applied to a progressive image, in the other hand, you probably won't be able to spot the difference without a map and a microscope.

Therefore, for content that mixes interlaced with progressive frames, (interlaced=true) is the superior setting to use, and I believe it should be the default setting in future versions of AVIsynth.

[StainlessS]

Sorry Katie, but aint no way in hell anybody is gonna screw up one helluva lot of existing scripts just to do that.

Note, interlaced=true has an effect only on YV12↔YUY2 or YV12↔RGB conversions. More about that can be found here.
http://avisynth.nl/index.php/Convert

Also, most people would rather 'get away' from Interlaced stuff, not make it the default.

[Katie Boundary]

Sorry Katie, but aint no way in hell anybody is gonna screw up one helluva lot of existing scripts just to do that.

There's no way in hell it would "screw up" anything.

Also, most people would rather 'get away' from Interlaced stuff

Unfortunately, we cannot wave a magic wand and change history and make all TV from the mid-80s to the mid-2000s progressive. Interlaced nonsense is here to stay.

[hello_hello]

Here's a function that converts using interlaced=true without the need to change it for an Avisynth filter that's probably had the same default for 20 years.

function KatieRGB(clip Source) { ConvertToRGB(Source, Interlaced=true) }

There's a function on the Avisynth wiki for converting "mixed" content, although I can't say I've used it myself as the first filter I'd add to a script for an interlaced source would be a deinterlacer.

function KatieToRGB(clip Source, int "threshold", bool "debug")
{
debug = default(debug, false)
global threshold = default(threshold, 20)

Vid1 = ConvertToRGB(Source, interlaced=false)
Vid2 = ConvertToRGB(Source, interlaced=true)
ConditionalFilter(Source, Vid1, Vid2, "IsCombed(threshold)", "equals", "true", show=debug)
}

[cretindesalpes]

Interlacing is meant for broadcasting and storage. The proper way to process interlaced content is to deinterlace it first, process the progressive double-rate frames, and possibly interlace them again (if really required) at the very end of the processing.

[Sharc]

Interlacing is meant for broadcasting and storage. The proper way to process interlaced content is to deinterlace it first, process the progressive double-rate frames, and possibly interlace them again (if really required) at the very end of the processing.
This brings the quality (and artefacts) of the deinterlacer into the equation.
For temporal-spatial filters and if the interlaced format should be kept it may be preferable to
separatefields -> even/odd grouping -> filter the even and odd fields -> interleave -> weave.

[DTL]

This brings the quality (and artefacts) of the deiterlacer into the equation.
For temporal and temporal-spatial filters it may be preferable to
separatefields -> even/odd grouping -> filter the even and odd fields -> interleave -> weave.

It may also degrade quality if processing will operate with some 'vertical direction' . For example MDegrain(N) try to move blocks and interpolate in both V and H directions and possibly may add more distortions.
Also some 4:2:0 interlaced processing may used 'mixed' block types - some blocks are treated as interlaced and some as progressive (to have better vertical colour resolution that degrades to 1/4 instead of 1/2 for progressive 4:2:0). When separate to fields - the 'progressive' blocks lost Nyquist limiting as being point-downsized 1/2 without pre-filtering. And later processing may cause additional distortions.

It is better to try both processing ways - with converting to progressive full frame height and with processing separated fields as progressive and pick best output.

Changing default interlaced to 'true' will degrade vertical colour resolution if processing progressive scanned frames. And as Avisynth was designed by PC programmers and not old video (moving pictures) engineers - PC (usually static) bitmaps typically progressively scanned so default interlaced was false from the initial Avisynth design I think.

[Sharc]

It is better to try both processing ways - with converting to progressive full frame height and with processing separated fields as progressive and pick best output.
Agree :)

Edit:
Also see this old discussion here:
https://forum.doom9.org/showthread.php?t=86394

with the summary in posts #32 and 48
https://forum.doom9.org/showpost.php?p=595148&postcount=48

[DTL]

Also if set interlaced=true I think Avisynth uses static treatment of all input as separated (in time) fields. It is fail-safe for moving areas but degrades vertical colour resolution on static areas. So better solution is not to use simple built-in conversion functions at all and use motion-adaptive ways. Motion-adaptive processing to and from 4:2:0 may possibly solve the issue with setting interlaced param manually and will save colour resolution where possible better.
I post some example already (though used motion-detector is not perfect and may pass errors).
It is also make some effect if source is 4:2:2 or better or the downscaling work performed (like creating interlaced 4:2:0 SD rip from HDTV/UHDTV source).
I think in the industry may already exist X:X:X to 4:2:0 interlaced converting hardware with motion-adaptive processing of different areas of the frame.

[wonkey_monkey]

Use interlaced=true if it's interlaced. Don't if it's not. I'm not sure what's so hard about that that would warrant changing a 20-year-old default.

[Katie Boundary]

Interlacing is meant for broadcasting and storage. The proper way to process interlaced content is to deinterlace it first

Some approaches to deinterlacing require RGB colorspace, which is how I got into this mess.

[StainlessS]

which is how I got into this mess.
Here a spade for you to dig a little deeper, faster, :)

Function KB_ConvertToRGB(clip c,string "matrix", bool "interlaced", string "chromaInPlacement", string "chromaResample") {
/*
KB_ConvertToRGB(clip c,string "matrix"="Rec601", bool "interlaced"=True, string "chromaInPlacement"="MPEG2", string "chromaResample"="bicubic")
Same as ConvertToRGB() / ConvertToRGB32() but with interlaced default = True.
All other args passed to ConvertToRGB() where it will use builtin avisynth defaults if not provided.
Args not provided, will be UnDefined within this function, and just passed on to the builtin ConvertToRGB which will then use its usual defaults.
[EDIT: Above line excluding Interlaced, will be True if not provided, can provide as Interlaced=True/False as usual]
*/
return ConvertToRGB(c, matrix, Default(interlaced,True) , chromaInPlacement, chromaResample)
}


Change the name if you like [but not to ConvertToRGB, script function names override builtins, and so would be recursive and crash / disappear - without error msg].

EDIT: !!!, However, if you're really planning a visit to China, can change function title by removing "KB_", and change internal

return ConvertToRGB =====>>> return ConvertToRGB32

And you're all set for the great journey :) [no crash]

EDIT: I dont recommend this for anyone else but Katie, she's special.
[***NOTE*** use at your own risk, I wouldn't]

[hello_hello]

Some approaches to deinterlacing require RGB colorspace, which is how I got into this mess.

Well don't leave us hanging.... which approach to deinterlacing are you referring to?

[Katie Boundary]

blah blah blah

What exactly is the point of all that?

[StainlessS]

What exactly is the point of all that?

this

Therefore, for content that mixes interlaced with progressive frames, (interlaced=true) is the superior setting to use, and I believe it should be the default setting in future versions of AVIsynth.

You can make it the default for yourself, no other sane person would want this. [we did not really need the 'other' word there]