AvsPmod (Windows_x86) mod

[Shinkiro]

Wow, feature 'Use previous frame time' is really cool, that's a lot more convenient, thank you!

[takla]

@gispos
All version after 2.6.6.7 hang indefinitely on "waiting for avisynth clip, thread still running" with any prefetch values when I use MVtools2.

Disabling "Access Avisynth in threads" does not have any effect on that.

https://github.com/gispos/AvsPmod/co...83ff3a762a14bd causes this issue.

[gispos]

AvsPmod 2.7.0.4

*** The main reason for this release is information ***

Avisynth 3.71 final version has problems with prefetch and frame properties.
AvsPmod also reads the frame properties when creating a clip, so avisynth hangs. 
There are two ways to avoid this:
Video > Display > YUV -> RGB > 'Read matrix from source or script' must be disabled.
or
Use Avisynth version 3.72 test 1, the problem was fixed here.
This version is available on Doom9: https://forum.doom9.org/showthread.php?t=181351

* Error message handling improved

[FranceBB]

Originally Posted by gispos

Video > Display > YUV -> RGB > 'Read matrix from source or script' must be disabled.
or
Use Avisynth version 3.72 test 1

or
use propClearAll() in every script right after indexing, pretend you're using Avisynth 3.7.0 and live happily ever after, free from the whole frame properties nightmare, like me eheheheh

[ErazorTT]

Could it be that the current version (2.7.0.4) does not show the values of highbits planarRGB correctly in the status bar? For me it shows only 255 distinct levels.

[poisondeathray]

Originally Posted by ErazorTT

Could it be that the current version (2.7.0.4) does not show the values of highbits planarRGB correctly in the status bar? For me it shows only 255 distinct levels.

It's like that with 2.6.9.9, the first version where high bit depth color picker was introduced too

I checked that underlying conversion was ok in avs; exported FFV1 from ffmpeg from the avs script , checked FFV1 with vsedit, the correct values are there

[ErazorTT]

It appears to me that this happens with all planar formats. I guess the conversion used to get the rgb values is broken whenever the clip is planar.
Oh and it's also vice-versa: Whenever the clip is (non-planar) rgb, the yuv values are constrained to 8bits precision.

PS: In case its not clear: I'm talking about the %RGB and %YUV status bar modifiers that show the rgb or yuv triplets as decimal numbers, these are "rounding" at 8bits precision depending on which one is the result of a planar to packed or packed to planar conversion.

[theworm4002]

gispos,

A buddy of mine took the Ver.2.7.0.2 (with the library.zip file for x64) setup I had. For some reason when they use it the tabs do not show up (as shown below). They are able to use {Ctrl + Tab} works to change through the tabs, they noted that the file name in the title bar does not change to display the new tabs name. I was wondering if there is an option in the setting I missed that might hide the tabs.

Thanks for your time,
Worm.

[gispos]

Originally Posted by theworm4002

gispos,

A buddy of mine took the Ver.2.7.0.2 (with the library.zip file for x64) setup I had. For some reason when they use it the tabs do not show up (as shown below). They are able to use {Ctrl + Tab} works to change through the tabs, they noted that the file name in the title bar does not change to display the new tabs name. I was wondering if there is an option in the setting I missed that might hide the tabs.

Thanks for your time,
Worm.

I don't know what to do with it, why 'your 64bit library' with a different version?
You can't just mix parts together and expect it to work.
Take a new 64bit version, and if problems arise then you can report it here.

Originally Posted by ErazorTT

Could it be that the current version (2.7.0.4) does not show the values of highbits planarRGB correctly in the status bar? For me it shows only 255 distinct levels.

Give me an example, I don't get 8 bit values.
If there is an asterisk in front of it, it is only calculated, so it is not from avisynth.

[ErazorTT]

Originally Posted by gispos

Give me an example, I don't get 8 bit values.
If there is an asterisk in front of it, it is only calculated, so it is not from avisynth.

No, its not that it shows 8bit VALUES, when there is the asterix it does show 16bit values (or whatever bit depth is used) but these are ROUNDED to the 8bit bounderies.

1. So here in the screenshot I loaded a 16bits gray ramp. Moving the mouse from left to right it starts in full black at Y=4096 and RGB=0,0,0 which is fine:


2. When the mouse is moved further to the right the Y value increases continuously through all numbers until here where its Y=4199, however look at RGB these are still at 0,0,0:


3. Now moving just a little bit further to the right where Y=4214 the RGB value jumps to 257:


The RGB values should have continuously risen, just like the Y value. But they are remaining at 0 until they jump to 257. So while 16bits values are shown, these are rounded to the 255 existing values between 0 and 65535 which are all multiples of 257: 0, 257, 514, 771,...
So everything that is going to be shown there is going to be an multiple of 257.

[poisondeathray]

If it helps explain the issue ErazorTT is describing , here is a 1024x720 , 0-1023 Y' gradient . AVC 10bit 422 . Each x coordinate is the Y' value. So at xpos 200, YUV=200,512,512. Ok so far.

Converting to 10bit Planar RGB full range in/out, you'd expect the same as RGB values . eg @ xpos 300 should be RGB 300,300,300

So the avspmod picker right to left reads RGB 1023,1019, 1015 in bars, instead of individual 1023,1022,1021,1020 that you would expected. ie the converted values for the color picker have an 8bit step somewhere


LSmashVideoSource("x264_10bit422_gradient.mp4")
z_ConvertFormat(pixel_type="RGBP10", resample_filter="point", colorspace_op="709:709:709:f=>rgb:709:709:f")

I upload both, including the FFV1 export convert ("zconv_ffv1.mkv") , which looks ok in vsedit, so the actual values are ok, it's just the color picker in avspmod

https://www.mediafire.com/file/84315..._ffv1.rar/file

[gispos]

I have to pass. which is what I use to calculate.
Suggestions for change welcome.

            R,G,B = rgb.Get() # display rgb 24 bit
       

            depth = script.AVI.bits_per_component - 8
            # 10 to 16 bits
            if depth > 0 and depth <= 8:
                R = int((257.0/256) * (R << depth))
                G = int((257.0/256) * (G << depth))
                B = int((257.0/256) * (B << depth))
                hexcolor = '$%04x,%04x,%04x' % (R,G,B)
                Y = int(0.257*R + 0.504*G + 0.098*B + ((257.0/256) * (16 << depth))) 
                U = int(-0.148*R - 0.291*G + 0.439*B + ((257.0/256) * (128 << depth))) 
                V = int(0.439*R - 0.368*G - 0.071*B + ((257.0/256) * (128 << depth)))
            else: # 8bit, on 32bit is 8bit RGB from display used
                hexcolor = '$%02x%02x%02x' % (R,G,B)
                Y = int(0.257*R + 0.504*G + 0.098*B + 16)
                U = int(-0.148*R - 0.291*G + 0.439*B + 128)
                V = int(0.439*R - 0.368*G - 0.071*B + 128)

[ErazorTT]

Originally Posted by gispos

            R,G,B = rgb.Get() # display rgb 24 bit

As it appears this returns 8 bit values independently of the actual bit depth. That is the bottleneck.

[gispos]

Originally Posted by ErazorTT

As it appears this returns 8 bit values independently of the actual bit depth. That is the bottleneck.

But that's all I have.

[gispos]

Another suggestion. Simply do not show the calculated values anymore. And the world is right again.
I don't need any frame properties or pixel values.

[ErazorTT]

Originally Posted by gispos

But that's all I have.

And how do you get the non-asterix one correctly?
I mean apparently you are able to get the correct value when the image is an RGB image. Because then the rgb values have no asterix, and are correct... I don't understand how that can be.

PS: I also see this in your code:

avsRGB = script.AVI.GetPixelRGB(x, y)

PPS: This seems to get also high bits values, I am correct? So why don't you use this instead of using dc.GetPixel(x, y)? So why do you get the rgb values with these two different ways two times?

PPPS: Why don't you just calculate the asterix values like that:

            # Get color from AviSynth
            if not self.bit_depth and (self.snapShotIdx < 1): # disable avisynth if snapshot visible
                try:
                    avsYUV = script.AVI.GetPixelYUV(x, y)
                    if avsYUV != (-1,-1,-1):
                        Y,U,V = avsYUV
                        R,G,B = calcRGB(Y,U,V,depth)
                        cY = cH = ''
                        if script.AVI.bits_per_component == 8:
                            hexcolor = '$%02x%02x%02x' % (Y,U,V)
                        elif script.AVI.bits_per_component <= 16:
                            hexcolor = '$%04x,%04x,%04x' % (Y,U,V) # comma separated is more visible
                        else: # 32 bit
                            hexcolor = '%.5f,%.5f,%.5f' % (Y,U,V) # no reason for 32 bit float in hex

                    elif script.AVI.IsRGB32:
                        avsRGBA = script.AVI.GetPixelRGBA(x, y)
                        if avsRGBA != (-1,-1,-1,-1):
                            R,G,B,A = avsRGBA
                            Y,U,V = calcYUV(R,G,B,depth)
                            hexcolor = '$%02x%02x%02x%02x' % (R,G,B,A)
                            cR = cH = ''

                    else:
                        avsRGB = script.AVI.GetPixelRGB(x, y)
                        if avsRGB != (-1,-1,-1):
                            R,G,B = avsRGB
                            Y,U,V = calcYUV(R,G,B,depth)
                            if script.AVI.bits_per_component == 8:
                                hexcolor = '$%02x%02x%02x' % (R,G,B)
                                cH = ''
                            elif script.AVI.bits_per_component <= 16:
                                hexcolor = '$%04x,%04x,%04x' % (R,G,B)
                                cH = ''
                            cR = ''

[gispos]

@ErazorTT, if it is possible to calculate the RGB value from the YUV value?
As already written, it doesn't really interest me and that's why I didn't bother with it.

Where can I find examples of this?

[ErazorTT]

These are the conversions in full precision from wikipedia:

BT.601 RGB->YUV:


BT.601 YUV->RGB:


PS: What we call YUV is actually a misnomer, and we all should be saying YCbCr whenever we say YUV. But since that's quite a mouthfull nobody says that and everybody just calls it YUV. Thats why you see in these formulas Cb and Cr instead of U and V.

[ErazorTT]

But now I'll also need the BT.709 conversion... Perhaps its actually really better to just remove this calculation at all and only show the values returned by avisynth.
For yuv clips you show the yuv triplet and for rgb clips you show the rgb triplet.

[ErazorTT]

if I'm already posting here, perhaps I could also make an implementation request: Could you please add BT.2020 to the list of possible colorspaces for YUV->RGB?

I mean, could it be added here as a third option:


That would be really very much of interest for me.