View Full Version : Remaining colorspace conversion bugs?

Richard Berg
20th February 2003, 04:50
Can anyone confirm or deny these results? Using the latest AVS 2.5 and VDubMod.

YV12 -> YUY2 = ok
YV12 -> RGB32 = ok
YV12 -> RGB24 = distorted

YUY2 -> YV12 = distorted
YUY2 -> RGB32 = ok
YUY2 -> RGB24 = distorted

RGB24 -> YV12 = crash
RGB24 -> YUY2 = ok
RGB24 -> RGB32 = ok

RGB32 -> YV12 = crash
RGB32 -> YUY2 = ok
RGB32 -> RGB24 = ok

20th February 2003, 09:16
Strange - it shouldn't be that bad at all. Could you try with the official beta. (changing FRAME_ALIGN from 16 to 32 could in theory cause this).

I tested all YV12 conversions, and they produced valid results.
YV12 -> YUY2 and YUY2 -> YV12 has problems when used right after a crop, because it is not possible to set source and destination pitch separately. RGB conversions should not have any problems - could you post the offending scripts for each conversion?

Edit: Confirmed - seems like we have some more work to do when changing frame alignment. These XviD conversion routines are not just leading to happiness. ;)

Richard Berg
20th February 2003, 15:50
Backing down to the latest official VDubMod release (1.4.13) and using the latest CVS code, some of the YV12 problems seem to be gone. RGB24 still has issues; these conversions are distorted:

YV12 -> RGB24
YUY2 -> RGB24
RGB24 -> YV12 (crash)

As before -- forgot to mention -- going through RGB32 first works ok.

FWIW, I started testing this because my JPEG writer currently requires RGB24 input. (It may be possible to support YUY2, but it's a lot harder).

20th February 2003, 16:01
I meant the AviSynth 2.5.0 beta - or the latest committed AviSynth CVS code (I reverted the frame-align thing).

RGB24 -> YV12 may be dependant on the resolution - it does some fairly strange tricks, when width is not mod 8 - it is possible that there is a bug there somewhere.

Could it input/output to RGB32? It is a much nicer colorspace ;)

(more than one time in the 2.5 dev. period I wished RGB24 was never put into AviSynth) ;)

Richard Berg
20th February 2003, 16:07
I found the bug in the C version of the YUY -> RGB24 routine and fixed it. Off to try my hand at the MMX version...

Edit: ick, it's the one in MASM. I'm usually ok with inline assembly but will defer to the experts if anyone wants to debug this one.

Edit #2 (didn't see sh0dan's post): RGB32 isn't really possible, at least with this jpeg library. (I will definitely work on getting YUY2.) PNG works in RGB32, thankfully.

20th February 2003, 17:43
Yes - it seems like it could be worth the efford investigating "J_COLOR_SPACE" - especially JCS_YCbCr looks interesting - even though it seems like we'd have to have an YUV 4:4:4 interleaved conversion.

It seems it is possible to supply YV12 (YCbBr) directly to LibJpeg - have you read the section called "Raw (downsampled) image data" in libjepeg.doc - very interesting!

It seems to be very useful for compression - decompression seems to be able to deliver in several formats - but since CMYK and "unknown formats" aren't that interesting - it could be very useful. Perhaps it could attempt "YCbCr", and then fallback to RGB24.

IMO a paramter for adjusting "J_DCT_METHOD" would also be very nice. Allowing users to select the fast DCT method could help speed!

Richard Berg
20th February 2003, 18:41
It's been awhile since I've read that section...looking over it, I think you're correct that YV12 can be supported as well as (or perhaps even easier than) YUY2.

First things first, though. Both PNG and JPEG still generate strange crashes :angry:

24th February 2003, 22:54
I have rewritten YV12 -> YUY2, and put in an interlaced mode as an option.
It should also solve the Crop problems the XviD converter has. It also very nicely interpolates chroma, which the XviD converters didn't.

Next up is YUY2 -> YV12, both progressive and interlaced. the XviD code seems nice, but it still has a problem when input and output pitches are not the same. Also there is a quite obvious isse optimization.

YUY2 -> RGB32 mmx code has been moved to a separate file.