BlankClip

[Wilbert]

I got a question and request about BlankClip:

I looked at the code, and there are some things I don't understand (made them bold):

if (vi.IsYV12()) {
int color_yuv = RGB2YUV(color);
int Cval = (color_yuv>>16)&0xff;
Cval |= (Cval<<8)|(Cval<<16)|(Cval<<24);
for (int i=0; i<size; i+=4)
*(unsigned*)(p+i) = Cval;
...

Maybe someone can explain them.

else if (vi.IsYUY2()) {
int color_yuv = RGB2YUV(color);
unsigned d = (color_yuv>>16) * 0x010001 + ((color_yuv>>8)&255) * 0x0100 + (color_yuv&255) * 0x01000000;
for (int i=0; i<size; i+=4)
*(unsigned*)(p+i) = d;

shouldn't the bolded line be

unsigned d = (color_yuv>>16) * 0x01000100 + (color_yuv>>8) * 0x010000 + color_yuv * 0x01;

What I really want to ask is the following. When requesting frames with pixel_type=yuv, I prefer to define the color using yuv values (instead of rgb which are converted to yuv). It makes more sense, and it is easier to generate frames with a specific yuv color (between [0,255]). Can this be changed?

[IanB]

Wilbert,

Oooo it's good to have the forum back. :D

int Cval = (color_yuv>>16)&0xff;
Cval |= (Cval<<8)|(Cval<<16)|(Cval<<24);

It is just packing an int with 4 copies of Y and then filling the luma plane fast-ish. This is done only once in the constructor so MMX/SSE is not worth it, but some speed never hurts.

unsigned d = (color_yuv>>16) * 0x010001 + ((color_yuv>>8)&255) *
0x0100 + (color_yuv&255) * 0x01000000;

Is correct, remember Intel processors are wrong-endian :D The built int is vvYYuuYY which when jammed into memory (examined 1 byte at a time) is YY uu YY vv YY uu YY vv ....

What I really want to ask is the following. When requesting frames with pixel_type=yuv, I prefer to define the color using yuv values (instead of rgb which are converted to yuv). It makes more sense, and it is easier to generate frames with a specific yuv color (between [0,255]). Can this be changed?

Yes it could be changed, but are you sure this is really what you want. I prefer HSV style sliders when playing with palletes but I don't like HSV as raw numbers. I can usually deal RGB values for most colours on spec but I always reach for the calc when playing YUV values. What YUV colour is
$987654? Dunno! What RGB colour is $987654? Pale orange-ish

I would think a better enhancment would be an AVS include library with a stack of predefined colour values.

IanB

[Wilbert]

Yes it could be changed, but are you sure this is really what you want. I prefer HSV style sliders when playing with palletes but I don't like HSV as raw numbers. I can usually deal RGB values for most colours on spec but I always reach for the calc when playing YUV values. What YUV colour is $987654? Dunno! What RGB colour is $987654? Pale orange-ish

How about renaming color color_rgb and adding color_yuv? So that a user can choose how he defines the color.

The problem is that sometimes I need to make test clips (out of bound yuv, ie [0,255]), which is hardly possible (you need to use coloryuv("tv->pc"), and still you don't get what you want).

The built int is vvYYuuYY
Oh, you mean the yuv values from color_yuv = RGB2YUV(color). Ok, I understand it.

[sh0dan]

No renaming. (We must remain backwards compatible!), but color_yuv makes sense!

We could simply add predefined colors as variables, so the following could be used:

blankclip(color=color_red)

We could simply add a color.avsi file to the plugin directory, where we set the variables!?

[IanB]

@Wilbert,

Sorry, I missed your point about forcing overrange YUV values. Being able to do this easily is important.

I will hack in "color_yuv" now, you can start updating the docs. It will be the 12th argument (after "color"), it will only work for YUV colour spaces and it will be full range [0..255]

IanB

P.S. 23:21 AEST It is in CVS :D

[Wilbert]

Great thanks! I will make the color table ...

[IanB]

@Sh0dan, Wilbert,

I have had a night to think about what I bashed together and I am having second thoughts. A less hacky solution might have been to code YUV colour values into the existing "color" parameter say by adding $80000000. This may fit in better with the Colors.avsi approach. It also allows for implementing other colour space encodings like HSV say by adding $40000000 and allowing say 12bits for the Hue representation.

For example :-global Color_YUV_base = $80000000
global Color_YUV_Ymask= $00ff0000
global Color_YUV_Umask= $0000ff00
global Color_YUV_Vmask= $000000ff
#
global Color_HSV_base = $40000000
global Color_HSV_Hmask= $0fff0000
global Color_HSV_Smask= $0000ff00
global Color_HSV_Vmask= $000000ff

# YUV diagnostic values
global Color_yuv_infrablack = Color_YUV_base + $008080
global Color_yuv_ultrawhite = Color_YUV_base + $ff8080
...
# HSV templates
global Color_HSV_black = Color_HSV_base + $0000000
global Color_HSV_white = Color_HSV_base + $00000ff
global Color_HSV_semigreen = Color_HSV_base + $7ff7f7f
...
# RGB templates
global Color_black = $000000
global Color_white = $ffffff
global Color_semigreen = $3fAB3f
If you think this is a better way I will undo last nights changes and assault the RGB2YUV() primative instead, this will make the change uniform across Avisynth, like in fg/bgcolor of text, etc.

Also for RGB24, YUY2 and YV12 it's a no brainer they only have 24bits so encoding the top 8 bits is not an issue, but for RGB32 it might be nice to still spec the alpha mask value and this makes the language non-orthogonal (well a little more non-orthogonal than it already is).

Thorts?

IanB

[Wilbert]

I don't get your proposal completely.

If you want to make a yuv clip with y=16, u=128 and v=128, you just do

Color_YUV_black_ccir601 = $80108080

blankclip(pixel_type="YUY2", color=Color_YUV_black_ccir601)

Correct? But if you add hsv formats, you will have to convert to rgb or yuv?

[IanB]

@Wilbert,

Correct.

Last Night I hacked in a 12th parameter to blankclip, color_yuv, which feeds integer data directly into the Y, U and V values so you can generate diagnostic YUV clips with out of range values.

But after thinking on the matter I feel what I have done is clunky. I think I would have been better to leave the blankclip syntax untouched and catch special values of the existing "color" parameter to allow you to specify direct YUV values, as per your example.

I am not suggesting I implement HSV values but I was seeding the idea pool for future possibilities of encoding other colour space representations.

Which implementation do you think would be better?

IanB

[sh0dan]

Originally posted by Wilbert
If you want to make a yuv clip with y=16, u=128 and v=128, you just do

Color_YUV_black_ccir601 = $80108080

blankclip(pixel_type="YUY2", color=Color_YUV_black_ccir601)

Correct? But if you add hsv formats, you will have to convert to rgb or yuv?
If I understand you correct - no. ;)

You cannot redefine what color does. The "color" accepts RGB-values. It cannot detect when you suddenly pass it YUV values. Therefore you must do:

Color_YUV_black_ccir601 = $108080
blankclip(pixel_type="YUY2", color_yuv=Color_YUV_black_ccir601)


@IanB: Your implementation is correct! The syntax is, AFAICT, the same as always, with default operation working as always.

[Wilbert]

You cannot redefine what color does. The "color" accepts RGB-values. It cannot detect when you suddenly pass it YUV values.
You missed the point of his post "13th August 2004 03:53". I think he wants to check the number of digits (eg. 8 starting with 80 => yuv, 8 starting with 40 => hsv, 6 => rgb, etc.).

Both ways are fine with me :)

[stickboy]

Originally posted by IanB
I have had a night to think about what I bashed together and I am having second thoughts. A less hacky solution might have been to code YUV colour values into the existing "color" parameter say by adding $80000000.Hmm... I really dislike magic values. And only BlankClip would recognize this.

But I agree that it would fit better for colors.avsi.

Another possibility, if you want to go the extra mile, would be to modify the parser to allow qualifiers, e.g.:

$987654rgb
$987654yuv

like the L, U, F, etc. qualifiers for C integer literals. Internally the parser could transform them to use your scheme, and then no one needs to be exposed to the internal representation (and avisynth.dll should supply methods like IsColorRGB(), IsColorYUV(), etc. for plug-ins to use). I suppose this also would allow the representation to change without worrying about colors.avsi and avisynth.dll going out of sync.

But maybe this is overkill.