GradCurve VapourSynth plugin port of virtualdub Gradation Curves plugin

[xekon]

Thank you so much for taking a look jackoneill, you have a sharp eye, I am going to make the changes you pointed out, also for the integer/float formats, sounds like I will need to have it check if the frame contains a float or an integer before processing.

AH, Looking back, NOW I see the reason for the template type in HolyWu's functions, one handles float and one handles INT. At first glance I did not see why there were two copies of most functions. Thats how I can handle Float vs Int data.

EDIT: or it may be that I need to change the function to only support 32 bit float input, for now this is what I am going to do.

I believe I made all of the changes you pointed out Jackoneill. After making those changes VSedit no longer crashes. I am assuming it was crashing because of the last one you pointed out, using integer input but assuming frames always contain float pixels and writing past the end of the frame.

The output is not what was expected... its solid black, LOL! but atleast I am not crashing now, and all frames are returned in VSedit.
I think I need to setup some code breaks in the original Vdub filter, and see how the data is being processed, and then compare that to what is happening in this vapoursynth ported version.
I really wish there were more comments in the vdub filter, but i'm sure I can figure it out if I keep stabbing at it, I don't think I would have gotten this far this quickly without everybody's help, and I have learned a bit too!

EDIT: oh and I updated the github: https://github.com/jieiku/GradCurve

Originally Posted by shekh

Btw, concerning lab mode
AFAIK is was both slow and low quality, maybe just worth removing anyway.

ah, maybe I should, especially if nobody is going to be using it.

[TheFluff]

I dunno if you figured out how to debug VS (or Avisynth) plugins so just for the sake of clarity: basically all you need to do is build a debug version of your plugin and in your VS project you set the debug command to run a custom command line that launches some application (Virtualdub, VSEdit, whatever) that will end up loading your debug DLL. Then set a breakpoint on whatever you're interested in and press debug and off you go. I think you could also attach the debugger to the already running host application process before you load your script but I don't think I've ever done that.

The Avisynth wiki doesn't disappoint by the way; it recommends printf debugging first and then provides instructions for MSVC6 because of course it effin does. God, this ancient garbage...

[xekon]

Thank you TheFluff, i'm at work right now but as soon as I get home I am going to try and set up my plugin to launch VSedit, because this is exactly the point i'm at, needing to set breakpoints and check current values of variables.

because i've never built libraries before this is a bit new to me. most of the debugging i have done on other projects in the past has been direct output such as the printf example.

[feisty2]

Actually it's much simpler than that
Just use the buggy plugin as if it works
And sure vsedit will crash
And then the OS(at least under windows 10) will pop out a "vsedit has stopped working" window
And then you click "debug" or something like that
And then vs2015 will be invoked automatically and also, automatically locate to the exact statement in ur source code that caused the crash

[xekon]

feisty2 that's how I opened the debug the first time back when it was crashing, but now the plugin is no longer crashing, but its outputting incorrect frames (solid black) so I now need to set breakpoints like TheFluff was saying, or output diagnostic messages directly.

[TheFluff]

You can attach the VS debugger to any running process, there's no need to crash it. I think it's in the Debug menu somewhere and as I said, if you have a VS (or AVS) script that loads your debug DLL, you can just attach the debugger to the host application (VSEdit or whatever), set a breakpoint (or a few) in your DLL's code and when you load the script in the host application the debugger will halt on your breakpoint... I think. As I said I used to use the other way (setting the debug command to launch the host application with the intended debug script) but I'm pretty sure it's effectively the same thing.

[xekon]

Originally Posted by jackoneill

Virtualdub uses packed RGB32, which means that the red, green, blue, and alpha pixels are interleaved in a single array (R0 G0 B0 A0 R1 G1 B1 A1 R2 ...). This is why you have all those shifts and bitwise AND operations. In VapourSynth the red, green, and blue pixels are in individual arrays (R0 R1 R2..., G0 G1 G2 ..., B0 B1 B2 ...), so the equivalent VapourSynth code will be a bit simpler.

I got debugging working, YAY! (built the original Vdub gradation curves filter, to see how the data is supposed to look with the original vdub filter) I built the solution, set debugger to launch virtualdub, and then once virtualdub loaded I went to video add filter, and loaded the debug copy of the filter that I just built.

Now I just need to be able to understand the data, alot of these fields can be expanded, for some reason I expected it to look a lot simpler, showing an R G and B value somewhere between 0 and 255...

[Wilbert]

Why don't you start with one frame consisting of one color (say red=128, blue=green=0), and apply the curves filter which should do nothing? Makes it easier to debug if that already produces incorrect results.

[xekon]

Originally Posted by Wilbert

Why don't you start with one frame consisting of one color (say red=128, blue=green=0), and apply the curves filter which should do nothing? Makes it easier to debug if that already produces incorrect results.

Thanks that definitely did help.

BlankClip(color=$FF0000)

its obvious after reading this that I didnt have a clue how pixel data was stored: http://avisynth.nl/index.php/Colors

going to experiment a bit until I have it down good

edit: got a chance to look a bit today, my version is setting the values to medr/medb/medg to 0, they get their value from the gvalue/ovalue/rvalue arrays, so they probably dont have a value set at that location in the array, I didn't have a ton of time to look today, and I have a ton of work the next 2 days. Should be able to put some serious time into this again on Wednesday or thursday.
edit2: actually probably not until after the holidays.

edit3: [B]can vapoursynth variables srcpR[x] / dstpR[x] use integers instead of floats?

[videoh]

Did you verify that (int) medr (etc.) is not out of range? It's customary to clip values before using them as indices.

[xekon]

my screenshot is in fact because it was out of range, but i also need to check what are appropriate values for dstpR, dstpG, dstpB to accept, currently with the way I have things setup, I believe its going to be a float between 0 and 1...

also why does visual studio not always honor the code breaks I set? I am trying to determine why my new changes are not working, but I cannot check the values because the code breaks are just gone.

code breaks:


then when i run it:

[videoh]

Are you running in a debug configuration that turns off optimization?

Why do you need all those breakpoints anyway? Just set one at the start and single-step through it.

[xekon]

thanks for the reply

I do have it set to debug, but I don't think i had optimizations off, I opened project properties, went to c++ section then optimizations and set optimization to Disabled /Od

when you say single step, where would I access that? I see an option for "step into (F11)" however it skips over to the next defined break point.

I have also tried cleaning and rebuilding.

[jackoneill]

Yes, your filter can accept and/or output RGB with integer pixels, with bit depth between 8 and 32.

[videoh]

There should be a "step over" button too. But it's configurable; you may have to add it. That would surprise me though.

"Step into" is for entering a called function, you can't step into a simple assignment statement. No problem, though, if it can't step into then it steps over.

[xekon]

Yes there is also a "step over (F10)" button, but its also skipping past multiple lines, and only landing on the break points that visual studio chose to honor.

Also I updated the repository to my current version: https://github.com/jieiku/GradCurve

EDIT: not sure what I did, Last night I was working on this on my laptop, I loaded the project at my PC, I have the debugger set to load VSedit and it loads the following script:

import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin('G:/moon/enc/VapourSynth-GradCurve-master/GradCurve/x64/Debug/GradCurve.dll')
#src = core.d2v.Source(input=r'D:\enc\032t.d2v', rff=False)
src = core.std.BlankClip(color=[255,0,0])
src = core.resize.Bicubic(clip=src, format=vs.RGBS)
src = core.grad.Curve(src,'G:/moon/enc/032t.amp')
src.set_output()

but now when it loads VSedit, and I hit F5, I am not getting the Red video picture that I was getting last night, VSedit instead loads a black screen, like its not even looking at the script where I set blankclip red color.... like something in my environment has changed, now none of the breakpoints are hit in visual studio, like its still waiting for the dll to be loaded so it can attach.

[videoh]

Originally Posted by xekon

Yes there is also a "step over (F10)" button, but its also skipping past multiple lines, and only landing on the break points that visual studio chose to honor.

Sure, Visual Studio is broken and you're the only one that figured that out. Don't worry, though, you'll carry on as if nothing happened.

[xekon]

lol, ok im not sure if your cracking a joke or being sarcastic, have you ever seen anything like this happen before? or are you saying that you develop in something other than visual studio usually?

edit: also I am fully aware that I dont have anywhere near as much experience with visual studio, thats why I posted my findings and am asking for help.

edit2: I recopied my project files from the laptop, and now VSedit shows the red screen again and the debugging is working like it was, but not stopping at all breakpoints and not going line by line when I use the step over.

edit3: AH HAH! ok I got it working! and it is honoring all breakpoints. the problem was that my VSedit script last night was pointing to the Release Folder of the dll.

earlier last night you said make sure im working in Debug mode, so I switched the project to debug mode and turned off optimizations.
but then in the VSedit script it was still loading the Release folder dll of this grad curve plugin.

Sorry so much for the frustration.

PS: on a side note I do not know why VSedit was loading a black frame instead of a red frame, but recopying the visual studio project files from the laptop fixed that.

Thanks so much both of you.

[videoh]

Sweet! It's pretty common to forget to invoke the debug DLL, don't worry about it. Happens to me all the time. But now when you see it skipping like that, straight away you think, aha, I have to edit the script to pick up the debug DLL.

Good luck with your project. I'll try to help if I can. Keep us informed.

[xekon]

OK! This plugin is now working, I have tested it with .amp & .acv curve files.
here is an example of what I used it to do: http://screenshotcomparison.com/comparison/197863

I updated the github as well: https://github.com/jieiku/GradCurve

I need to do further testing, and I believe I have some hard hard coded values that need to be setup as parameters, but I am very happy to have it this far.

edit: working on cleanup, adding parameters, checking different modes for functionality.