GradCurve VapourSynth plugin port of virtualdub Gradation Curves plugin

[xekon]

ok, so I already started converting this plugin to work with integer input, so I may as well continue and see how it turns out:

so instead of 32bit floating point input:
src = core.resize.Bicubic(clip=src, format=vs.RGBS)

I would be using 8bit integer input:
src = core.resize.Bicubic(clip=src, format=vs.RGB24)

edit: I think I finally found some relevant documentation, will post back after testing.

[xekon]

Originally Posted by shekh

The original gradation curves was 8-bit and you still have 8-bit lookup tables. You should just stay at 8-bit input.

OK, so I am just about done converting this to use 8bit integer clips, however I have noticed something while working on this that I hope somebody with better trained eyes or understanding can tell me, in the bellow picture why go from the original, to the medium, to the new..... the values don't seem to change from medium to new... so why not just go straight from original to new.

The only thing that makes sense to me is that maybe in other modes the medium step is necessary, and that in the RGB + /R/G/B mode its unnecessary but the code just got recycled this way since it was necessary elsewhere in the program. I am wondering under what circumstances the middle step is necessary.

screenshot below is the original gradation curves filter for virtual dub, not a vapoursynth filter, I loaded it for debugging/understanding.

[xekon]

Originally Posted by jackoneill

The difference between the black levels is due to d2vsource. The latest Windows DLLs have a bug that was fixed in git. They incorrectly mark the video as full range, and so the resizer treats it as such.

thank you jackoneill, is this the one with the fix: https://github.com/dwbuiten/d2vsource/releases/tag/v1.0
it is the one I am now currently using for my windows vapoursynth R35 / vsedit R14

I am thinking I need a later version than the one already built on github, so I need to build from scratch... i'm trying to do that over here: https://forum.doom9.org/showthread.p...54#post1795154

I am trying to get the output to match between VSedit and Virtualdub/avisynth, it would make testing my plugin sooo much easier to be able to directly compare debug values between the two.

in this picture the black levels are different:


here is the avisynth script I load in vdub:

LoadPlugin("G:\AviSynth\plugins\DGDecode.dll")
MPEG2Source("G:\moon\enc\GradCurve\032t.d2v", iPP=false)
KillAudio()
ConvertToRGB24()

here is the vapoursynth script(windows):

import vapoursynth as vs
core = vs.get_core()
src = core.d2v.Source(input=r'G:/moon/enc/GradCurve/032t.d2v', rff=False)
src = core.resize.Bicubic(clip=src, format=vs.RGB24)
src.set_output()

[shekh]

Originally Posted by xekon

OK, so I am just about done converting this to use 8bit integer clips, however I have noticed something while working on this that I hope somebody with better trained eyes or understanding can tell me, in the bellow picture why go from the original, to the medium, to the new..... the values don't seem to change from medium to new... so why not just go straight from original to new.

mfd->gvalue etc are of type int and contain values mixed for multiple channels. Sort of optimized version.
To understand this you have to compare how lookup tables are filled vs how they are used. For you: impossible.
IMO all it makes sense to do with this is to feed input and grab output, and just leave what is inbetween intact.

[xekon]

Thanks for the reply, I understand that the mfd->gvalue etc are type int with mixed values for multiple channels.
I already had to modify part of the code because vaporsynth getReadPtr does not return RGB combined.
I have to disagree that it's impossible for me to understand how the lookup tables are filled vs how they are used.
While I will agree that I am diving into the deep end working on new things, i'm quickly learning a lot, and i'm starting to feel like i'm getting past a lot of the initial learning curve.
With enough debugging and testing I could figure out the reason they have the extra step that appears to have no effect on the output of the frame.
but for now, I am doing exactly that, just porting the filter and feeding input and grabbing output.
if I ever want to do more with it, like supporting greater bit depth then I will obviously need to delve deeper.

I have finished converting this to use integer input instead, and updated the github: https://github.com/xekon/GradCurve

[shekh]

Good luck in learning.
Since the filter runs per pixel anyway, the quick and dirty way to port it:
Inside a loop repack a pixel from VS format to VD format, load it into old_pixel
run the formula whatever is written, no changes
repack _new_pixel from VD format to VS format and store it

[Myrsloik]

Originally Posted by shekh

Good luck in learning.
Since the filter runs per pixel anyway, the quick and dirty way to port it:
Inside a loop repack a pixel from VS format to VD format, load it into old_pixel
run the formula whatever is written, no changes
repack _new_pixel from VD format to VS format and store it

NonononononononononoNOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!11111111111

[jackoneill]

Originally Posted by xekon

thank you jackoneill, is this the one with the fix: https://github.com/dwbuiten/d2vsource/releases/tag/v1.0
it is the one I am now currently using for my windows vapoursynth R35 / vsedit R14

I am thinking I need a later version than the one already built on github, so I need to build from scratch... i'm trying to do that over here: https://forum.doom9.org/showthread.p...54#post1795154

d2vsource 1.0 is the one with the bug. There is no release with the fix yet. However, you don't need to compile d2vsource. There is a simple workaround:

src = core.d2v.Source(input=r'G:/moon/enc/GradCurve/032t.d2v', rff=False)
src = core.std.SetFrameProp(src, prop="_ColorRange", intval=1) #    Mark video as limited range.
src = core.resize.Bicubic(clip=src, format=vs.RGB24)

http://www.vapoursynth.com/doc/apire...ame-properties
http://www.vapoursynth.com/doc/funct...frameprop.html

OK, so I am just about done converting this to use 8bit integer clips, however I have noticed something while working on this that I hope somebody with better trained eyes or understanding can tell me, in the bellow picture why go from the original, to the medium, to the new..... the values don't seem to change from medium to new... so why not just go straight from original to new.

The only thing that makes sense to me is that maybe in other modes the medium step is necessary, and that in the RGB + /R/G/B mode its unnecessary but the code just got recycled this way since it was necessary elsewhere in the program. I am wondering under what circumstances the middle step is necessary.

Obviously the middle step was necessary at some point. Maybe it still is, maybe not.

In order to figure out when (if) you can skip the second lookup step, you need to look at the code where rvalue[0], gvalue[0], and ovalue[0] are initialised. You need to see under what circumstances Xvalue[0][i] equals i. Good luck with that, because that code is way more spaghetti than I feel like consuming.

By the way, since you're no longer working with packed RGB, you can get rid of the shifts + bitwise AND operations, when initialising the lookup tables and when using their contents.

You also don't need to cast the pointers returned by getReadPtr/getWritePtr. They return (const) uint8_t*. uint8_t is another name for unsigned char.

Originally Posted by shekh

Good luck in learning.
Since the filter runs per pixel anyway, the quick and dirty way to port it:
Inside a loop repack a pixel from VS format to VD format, load it into old_pixel
run the formula whatever is written, no changes
repack _new_pixel from VD format to VS format and store it

lol. But the original code unpacks the pixels because each channel has its own lookup table.

[shekh]

Originally Posted by Myrsloik

NonononononononononoNOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!11111111111

Tell the truth, you would spend how much time for this whole porting project, 15min maybe?

[xekon]

Originally Posted by Myrsloik

NonononononononononoNOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!11111111111

LOL!

Originally Posted by shekh

Tell the truth, you would spend how much time for this whole porting project, 15min maybe?

if your already actively developing for similar projects then you will spend very little time, 15 minutes actually sounds about right for this project if you already have your development environment setup, and are familiar with the libraries your working with.

At the end of the day I really really really really wanted this vdub plugin for vapoursynth, and nobody else had ported it yet, and unless I stepped up to do it I just don't know if something like this would ever be available.

[jackoneill]

Originally Posted by xekon

At the end of the day I really really really really wanted this vdub plugin for vapoursynth, and nobody else had ported it yet, and unless I stepped up to do it I just don't know if something like this would ever be available.

You can always pay someone to do it.

[xekon]

That is very true, and depending on the cost, and how often you might find yourself coding, that might be the best solution. but in life I have done just about everything for myself.
I fix my own cars, that includes tearing down and rebuilding engines and transmissions. I built the cabin that my family lives in by hand.
When I am trying to solve a problem I almost never think to solve it with money, but I have no problem asking for help when I need it.
Also I really did enjoy spending my free time working on this! I have always enjoyed coding, and learning new ways to code.

and again, thank you to everyone that has replied to my questions, it has been very helpful

[xekon]

Originally Posted by jackoneill

By the way, since you're no longer working with packed RGB, you can get rid of the shifts + bitwise AND operations, when initialising the lookup tables and when using their contents.

You also don't need to cast the pointers returned by getReadPtr/getWritePtr. They return (const) uint8_t*. uint8_t is another name for unsigned char.

Thank you I have made those changes in addition to adding the rest of the functionality of the original gradation curves, all modes and file types should be working.

[Myrsloik]

Originally Posted by shekh

Tell the truth, you would spend how much time for this whole porting project, 15min maybe?

Fortunately xekon was clever enough to produce exactly the kind of answer I was going to write too. If people want to try themselves and learn it's good. I will however always point out how to not do things, see it as constructive criticism. Packing and then immediately unpacking RGB pixels is so pointless I can't let it pass.

And about porting time? 15 min for your slop-port method indeed. Honestly I'd probably just read the manual and rewrite it from scratch, for smaller projects like these it tends to be faster than trying to figure out how the code is structured.

[shekh]

Originally Posted by Myrsloik

Fortunately xekon was clever enough to produce exactly the kind of answer I was going to write too. If people want to try themselves and learn it's good. I will however always point out how to not do things, see it as constructive criticism. Packing and then immediately unpacking RGB pixels is so pointless I can't let it pass.

I thought going dumb method would help (at least for learning).

[xekon]

What helped the most for learning was having things pointed out that should be done, but not being given the code to do it, Jackoneill did that a few times for me. Your post about the lookup tables being 8-bit and that I should use 8-bit input was very helpful

[jackoneill]

Originally Posted by xekon

What helped the most for learning was having things pointed out that should be done, but not being given the code to do it, Jackoneill did that a few times for me. Your post about the lookup tables being 8-bit and that I should use 8-bit input was very helpful

That was shekh, though.

[xekon]

lol, yes. I was replying that the type of posts I've found helpful for learning, many of them from you, involved pointing things out that need to be corrected without actually giving the code to make the correction, shekh said:

Originally Posted by shekh

I thought going dumb method would help (at least for learning).

and so I was trying to points out one of his posts that I found very helpful.

[lansing]

Good to have this filter for vapoursynth, tested on amp and acv curve file and both work fine.

Though your description of the filter is wrong, this is a curve reader, it doesn't create or edit curve like what it was descripted.

And I'm reporting a bug, if I declared a wrong type in the argument for the input curve file, the editor will crash. The 2 crashs I found are

cur_path = r'test.amp'
clip = core.grad.Curve(clip, cur_path, ftype=2, pmode=1) 

cur_path = r'test.acv'
clip = core.grad.Curve(clip, cur_path, ftype=6, pmode=1)

[shader]

I'm really very interested for this filter!

But almost every of my scripts uses float.
Do you think it's very difficult to make a float version of my own?
Which tools do I need to compile that on Win10 64bit for that OS?