ColorSpace conversions

[Bidoche]

I need help to fill in 3.0 ColorSpace conversions code.

I copied what I could from 2.X, but :

- YUY2 to RGB24/32 uses an external asm source (convert_a.asm) thus annoying everyone who wants to compile the dll.
I would like somebody to convert it as inline assembly. (Beyond my poor asm skill, I don't even understand where the code starts)

- Conversions involving YV12 calls functions from XviD, which does not deal with interlacing issues (chroma upsampling...) where we can (and should) do it.
So I think they should be rewrote.

If the speed penalty is judged not too big, it could be done passing by a 444 YUV colorspace (or 'YUY2 planar' (has it a name ?)).
I need opinions about that.


All source files to complete are in the avisynth3_0 branch on cvs, in folder videoframe/convert/.
And the only other source one need to understand is windowptr.h (defines a 20 lines struct packing plane info)

I can post here too, if some prefer.

[sh0dan]

YUY2->RGB: I haven't heard of any problems compiling them. Which are you experiencing?

XviD conversion: I have implemented them all, but found them to be very buggy and produce quite bad results. No chroma subsampling, strange colors. Making strange assumptions about alignment, etc. This is the reason I wrote them from scratch anyway. BTW, the C-code is seriously outdated and doesn't provide nearly as good quality.

Doing not-in-place conversions is not a good approach IMO. It is more than twice as slow without any real gains. YV12 <-> RGB uses not-in-place conversion, as there isn't enough registers to do it without serious speed penaties, therefore an intermediate YUY2 conversion is done.

[Bidoche]

YUY2->RGB: I haven't heard of any problems compiling them. Which are you experiencing? It was configurations problems, VC6 not finding the assembler...
I don't remember exactly, it doesn't happen anymore.
I am just saying it would be nice to have it as inline asm, since it's the only .asm dependancy we have.

XviD conversion: I have implemented them all, but found them to be very buggy and produce quite bad results. No chroma subsampling, strange colors. Making strange assumptions about alignment, etc. This is the reason I wrote them from scratch anyway. BTW, the C-code is seriously outdated and doesn't provide nearly as good quality.
So you already made them ? Cool :)
I guess I didn't find them because the version from which I branched 3.0 is too old now.
Can you point me to the sources containing them or copy them yourself to the appropriate 3.0 source ?


Doing not-in-place conversions is not a good approach IMO. It is more than twice as slow without any real gains. YV12 <-> RGB uses not-in-place conversion, as there isn't enough registers to do it without serious speed penaties, therefore an intermediate YUY2 conversion is done.
I was expecting that, unless you really have to, like as you said YV12 -> RGB.
I will update to remove direct YV12 -> RGB.

When/If I add an YUV 444 planar colorspace, conversion to RGB will create the same issue, but YUY2 won't do it (unless you accept the quality loss).
Do you feel a interleaved YUV format would be necessary ? (YUV24 or YUV32)

[sh0dan]

All current conversion filters are here (http://cvs.sourceforge.net/viewcvs.py/avisynth2/avisynth/src/convert/?sortby=date&only_with_tag=MAIN). Just ignore "convert_xvid" - it isn't used anymore.

You should REALLY update your filters. I also noticed that you had a pre 2.52 version of the resizer. It's a complete waste of time to port old filters.

A planar YUV 4:4:4 format would be great.

[Bidoche]

All current conversion filters are here. Just ignore "convert_xvid" - it isn't used anymore. Ok, I will import these ASAP.


A planar YUV 4:4:4 format would be great.You can consider it as good as done.
Any others ?

[sh0dan]

Edit: Deleted some of my silly ramblings! ;)

Regarding a general extended precision YUV format, I think a planar 16bpp YUV4:4:4 would be the best. For CPU-wise considerations it should only have 15 significant bits per pixels. (ie range is from 0 to 32767), to avoid many 32bit overflow issues. This will offer a qualitywise superiour format to RGB32 an many ways, and it would require 48bits per final pixel.
CPU-wise every second pixel would be 4-byte aligned, and every 4 pixel would be quadword aligned. Quite nice IMO.
A plane in 720x576 would unfornately require 810kb, which is quite a lot for most (CPU)caches to handle, but I guess that's the price to pay.

This _will_ be a good thing, but it would require a lot of work converting existing filters. An 8bpp YUV4:4:4 would be a lot easier to implement, as most YV12 will work without modification - but it doesn't really offer much of an edge compared to YUY2 and YV12.

[Bidoche]

I have already done a 8pp YUV4:4:4 format which I named YV444.
I can still change the name if somebody has a better one.

I can do the 16pp one too, whether filters will support it is not a concern at this point.


This _will_ be a good thing, but it would require a lot of work converting existing filters.No need to rush, we can do them one at a time, and if using my inner class idiom, it doesn't intrude on other color spaces path.

[morsa]

Nice to hear so good news about YUV 4:4:4.
Thank you guys.