SeparatePlanes?

[Kika]

Hm, maybe i haven't found the function and maybe, there's no such function. I'm looking for a way to separate the Color planes to their "real" Format. Something like that:

Y=SeparatePlanes(Y)
Cb=SeparatePlanes(Cb)
Cr=SeparatePlanes(Cr)

And, guess that's very usefull if such a function exists:

MergePlanes(Y,Cb,Cr, Mode=RGB24) (or each Colorspace you want)

Is there any way to do that?

[Manao]

What do you want that possibility for ?

Because doing so, you won't be able to use any filter at all, since they are written for specific colorspaces.

If you want to be able to use filters, do something like that :Y = source.greyscale()
U = source.UtoY()
V = source.VtoY()It will give you three clips whose luma planes are respectively the Y, U and V planes of the source. After filtering, to merge, do : chroma = YtoUV(Ufiltered,Vfiltered)
result = mergeluma(chroma,Yfiltered)

[mf]

Manao manao manao :D. You only need YToUV(u, v, y) ! :)

[Manao]

I didn't read completly the documentation. I stopped at "Use MergeLuma, if you want to add luma values" :D

[Kika]

What do you want that possibility for ?

It's for using different Filters for each Color plane. I'm doing some Captures from more than 20 years old Video2000-Tapes. With the normal kind of filtering, i don't get the quality i want.
Working with MergeChroma after filtering Chroma and Luma for each own is doing only half the job. But i have to do some new research, i never used YToUV before (shame on me :cool: ), maybe it is what i'm looking for.

[scharfis_brain]

but I think, that some kind of separateplane and mergeplane could be very useful (and fast), if a 8 (or more) bit colorspace (or should I say greyscalespace) could be introduced to AVISynth.
THis would help gaining speed on masking to, I assume.

I think, a 1 bit colorspace could be useful, too.

[Manao]

Imho, there is no need for such colorspaces. It would still need the filters to be rewritten to cope with these colorspaces.

The workaround introduced by Kurosu inside the masktools ( switches for each planes ) is better in this regard.

[kassandro]

A filter like SeparatePlanes or ConvertToPlanar would be helpful also for faster processing, because SSE optimization can usually only be done for planar color spaces. Thus for any interleaved color space there should be a planar version with lossless conversion routines. In fact, in my filters I use such conversion routines internally, but it would be more efficient to make such a conversion at the beginning and the end of a script. A builtin ConvertToPlanar and ConvertToInterleaved would be desirable.

[Kika]

@manao

I don't think there is a need for rewriting the filters. It's not a big deal to convert a separated Plane without any Quality-loss to a fromat, the current filters are able to work with.
Like scharfis_brain stated: there are many ideas for using such a function.

[stickboy]

I'd like to see a greyscale colorspace too. It'd be nice for masks.

Also, even though existing filters wouldn't be able to support it directly (but as mentioned, this isn't really a huge problem), I imagine that it should be fairly painless for filter authors to add greyscale support.

[Manao]

kika : if you have to come back to a specific colorspace before using a filter, it's better to stay in this colorspace for all the filtering.

stickboy : with the masktools, with U=2 and V=2, you already have that. In that case, the filter doesn't process at all the U and V planes. It can be done for filters working on mask.

Yes, it would be painless to add that support ( for YV12 filters ), in fact it would require the same amount of work to support such colorspaces and to add the possibility to use switches like in the masktools. For YUY2 and RGB, you would need to rewrite the core of your filter ( because colorspaces are interlaced ).

But, there are not so many filters that are still supported by their developpers, and some great filters ( Dust for one ) would not be converted. With switches for supported filters, it would be possible to use them without having to make a conversion.

kassandro : yes, a ConvertToPlanar would be great for YUY2 and RGB colorspaces. There is still the problem that filters would need to be rewritten in order use fully such planar colorspaces, but the speed gain from optimizations would worth it.

[stickboy]

Originally posted by Manao
stickboy : with the masktools, with U=2 and V=2, you already have that. In that case, the filter doesn't process at all the U and V planes. It can be done for filters working on mask.But that only works with MaskTools' supplied functions, not with general filters. There currently is no standard way, and for the long term I think a greyscale colorspace is preferable to standardizing on MaskTools' behavior.
For YUY2 and RGB, you would need to rewrite the core of your filter ( because colorspaces are interlaced ).(Interleaved, not interlaced.)

It would be troublesome for RGB, true. (Luckily there aren't a lot of RGB-only filters.) For YUY2, though, it usually should involve incrementing a pointer by 1 byte instead of by 2 in loop iterations, right?

[Manao]

For YUY2, though, it usually should involve incrementing a pointer by 1 byte instead of by 2 in loop iterations, right ?It depends of the implementation of the filter, but yes, it would be true for most of the filters.
But that only works with MaskTools' supplied functions, not with general filters.Yes, but that way, filters that would not have been converted to cope with maskplanes would still be usable ( for example, we can use blur on a mask produced by the masktools without having to rewrite it ). But I agree, 'standardizing' masktools' behavior to other filters is not a clean solution.

[scharfis_brain]

and also keep in mind, that a greyscale colorspace saves memory (thus saving time for transferring that data) because only the luma is used instead of 100% overhead (YUY2) or 50% overhead (YV12)

[Richard Berg]

There currently is no standard way, and for the long term I think a greyscale colorspace is preferable to standardizing on MaskTools' behavior.

If I'm understanding you correctly, the only disadvantage to using YV12 as a mask- or greyscale-colorspace is performance, right? It certainly has a planar greyscale image. The semantics of the other two planes might do something useful with creative scripting, or nothing at all; you don't lose anything but 50% more pixels.

[stickboy]

Right... basically a greyscale colorspace just would be an explicit means to prevent filters from spending the time processing the unused UV planes. The memory savings isn't significant enough to be too important to me; maybe a greyscale colorspace could be implemented under-the-hood as an alias to YV12, just with hints (to filters that care) to ignore the UV data.

[kassandro]

Originally posted by stickboy
The memory savings isn't significant enough to be too important to me;
The memory savings may be important for large scripts, because for such scripts the Avisynth cache is quickly exhausted, which then forces Avisynth to process identical frames more than once. Thus if you can save 33% (yv12) or 50% (yuy2) cache memory, it may have a significant impact on performance. A greyscale flag for planar color spaces is probably the way to go. Then all such greyscale frames share one u-plane and one v-plane with all pixels set to 128. In this way you do not have to rewrite filters but have the full benefit of greyscale processing for filters, which support it.