GradCurve VapourSynth plugin port of virtualdub Gradation Curves plugin

[xekon]

GradCurve filter can be used to edit the gradation curves similar to the curves function of painting programs. It is a powerful tool that allows you to do some basic correction like brightness, contrast and gamma as well as a wide range of advanced color correcting and manipulations.

GradCurve is a VapourSynth c++ plugin converted from the VirtualDub c++ plugin Gradation Curves(http://forum.doom9.org/showthread.php?t=133191)

There is a working test version of GradCurve on github: https://github.com/jieiku/GradCurve

windows dll: https://github.com/jieiku/GradCurve/.../GradCurve.dll

project files that can be used for testing: http://www.mediafire.com/file/9nc2et...j/gradcurve.7z

Disclaimer: I have only tested amp/acv files with pmode=1 (RGB + R/G/B), so if you come across a bug please let me know.

Thanks so very much to everyone that has helped me throughout this thread, I really apprciate it.

Also, I welcome any improvements/changes, so please share

[Mystery Keeper]

Why did you convert C++ code to Python? You could just make a C++ VapourSynth plugin.

[xekon]

oh I did not realize that. is there any advantage to one or the other? As far as vapoursynth is concerned.

[jackoneill]

If you do this in Python, it will be too slow to be usable.

Just check out basically anything in here.

[xekon]

im slowly getting a feel for how things are connected. i found an example in the vapoursynth source invert_example
and im following through the c++ code of gradation and found what I believe is the main processing loop when processing in the mode I am currently using which is mode 1 (RGB + R/G/B)

for (h = 0; h < height; h++)
{
	for (w = 0; w < width; w++)
	{
		old_pixel = *src++;
		med_pixel = mfd->rvalue[1][(old_pixel & 0xFF0000)>>16] + mfd->gvalue[1][(old_pixel & 0x00FF00)>>8] + mfd->ovalue[3][(old_pixel & 0x0000FF)];
		new_pixel = mfd->rvalue[0][(med_pixel & 0xFF0000)>>16] + mfd->gvalue[0][(med_pixel & 0x00FF00)>>8] + mfd->ovalue[0][(med_pixel & 0x0000FF)];
		*dst++ = new_pixel;
	}
	src = (Pixel32 *)((char *)src + fa->src.modulo);
	dst = (Pixel32 *)((char *)dst + fa->dst.modulo);
}

I believe once I have this block using the appropriate vapoursynth API functions that I should be able to get it working, the naming of these variables suggests that it processes the frames by looping through all pixels of each frame, does that mean I would need to use get_read_array() ? the vapoursynth documentation says that returns the frames data. any help with this code block is appreciated.

I have some basic coding experience in java, c++, c#, and now python. But nothing I have ever coded involved image or video manipulation. Mostly web apps that work with databases. I feel like the learning curve is a little steep, but im slowly getting a grasp on this.

[feisty2]

Tell me how is *src++ any better than src[w]?
Sometimes I just fail to understand why would anyone write such unreadable stuff along with whole bunch of pointless, again, unreadable bit wise operations..
C++ is not assembly

[jackoneill]

Originally Posted by xekon

I believe once I have this block using the appropriate vapoursynth API functions that I should be able to get it working, the naming of these variables suggests that it processes the frames by looping through all pixels of each frame, does that mean I would need to use get_read_array() ? the vapoursynth documentation says that returns the frames data. any help with this code block is appreciated.

I have some basic coding experience in java, c++, c#, and now python. But nothing I have ever coded involved image or video manipulation. Mostly web apps that work with databases. I feel like the learning curve is a little steep, but im slowly getting a grasp on this.

get_read_array is a Python function. Aren't you doing this in C(++)? But yeah, if you want to do it in Python you'll want to use get_read_array and get_write_array to access the pixels.

If you're going to use C++, this is the page you need: http://www.vapoursynth.com/doc/api/vapoursynth.h.html
Read about the functions you see in the invert example.

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.

[xekon]

Thank you very much for the replies guys, I was looking at the wrong API page, thanks again Jackoneill.

[StainlessS]

Originally Posted by feisty2

Tell me how is *src++ any better than src[w]?
Sometimes I just fail to understand why would anyone write such unreadable stuff along with whole bunch of pointless, again, unreadable bit wise operations..
C++ is not assembly

I suggest that if you dont understand it, you dont use that style,
and old_pixel=*src++ is more like old_pixel=src[0]; src=src+1;
C is part of CPP, if you dont understand C, then you dont understand CPP.

C is a beautifully succinct language, dont knock it.

[feisty2]

Originally Posted by StainlessS

I suggest that if you dont understand it, you dont use that style,
and old_pixel=*src++ is more like old_pixel=src[0]; src=src+1;
C is part of CPP, if you dont understand C, then you dont understand CPP.

C is a beautifully succinct language, dont knock it.

old_pixel = src[w] // also legitimate C code, and much more readable, and faster than *src++ cuz u got one less "add src, sizeof(pixel type)" operation

Right, we should definitely talk more about succinctness.

[StainlessS]

For some processors x=*p++; is [EDIT: compiles to] a single m/c instruction, (perhaps Intel/AMD not amongst them).

Of course it also depends upon the whole context of the code where the code fragment lives as to whether it would be
better used or avoided.

EDIT: eg perfectly acceptable here:- [especially where short strings.]

    while(*d++=*s++);   // strcpy()

    OR

    for(;*d++=*s++;);   // strcpy()

Originally Posted by feisty2

Tell me how is *src++ any better than src[w]?
Sometimes I just fail to understand why would anyone write such unreadable stuff along with whole bunch of pointless, again, unreadable bit wise operations..
C++ is not assembly

To be pedantic, that's not a bitwise operation, it's pointer arithmetic. &, ~, ^, |, << and >> are bitwise operations.

Also, the code is extremely simplistic so what is so hard about reading it?

[shekh]

x=*p++

This is simple example of (bad) practice to squeeze multiple independent statements into single one. A matter of taste (I hate it).
And while we are here what is better: tabs or spaces?

[feisty2]

Originally Posted by captaiŋadamo

To be pedantic, that's not a bitwise operation, it's pointer arithmetic. &, ~, ^, |, << and >> are bitwise operations.

Also, the code is extremely simplistic so what is so hard about reading it?

Using the pointer as an array is much saner and easier for programmers to read than doing it with the raw pointer arithmetic style.

"Along with bunch of bit wise operations", I was referring to crap like "&0xff0000, >>16",,,

How is it bad practice? It's a bog-standard idiom that's been used for decades.

The funny thing is that people who complain about these idioms and then try to be smarter by rewriting them tend to introduce bugs in code that never existed before. "All code is crap except what I write."

Originally Posted by feisty2

Using the pointer as an array is much saner and easier for programmers to read than doing it with the raw pointer arithmetic style.

"Along with bunch of bit wise operations", I was referring to crap like "&0xff0000, >>16",,,

A programmer who can't read the code is likely incompetent. I don't know a single programmer that I've ever worked with that would be tripped up by that line of code.

[feisty2]

I certainly CAN read that kind of code, but that was way too assembly style and kinda makes me feel gross whenever reading such crap

[shekh]

Originally Posted by captaiŋadamo

How is it bad practice? It's a bog-standard idiom that's been used for decades.

IMO it is "bad" because:

cons:
it is more difficult to read and understand order of operations in complex expression than sequence of simple expressions
pros:
nothing

[jackoneill]

And none of this is relevant to the topic at hand...

[xekon]

Ok, I finally got everything to compile, most of the errors were linking errors, it had been a couple years since I did any coding.
Also I did not realize that Visual Studio community 2015 by default did not install with a C++ compiler, you have to do advanced options install and check the boxes for that.
Thanks to HolyWu too! I found his C++ plugin/filter ports to be well structured and easy to follow (AddGrain, Deblock, DePan, W3FDIF). It provided with me with a good starting point for a Vapoursynth C++ filter

So there are no compiler errors, but VSedit crashes without any error messages when I try to use the filter.

how can I get VSedit to report the reason it crashed? to get more details, it has something to do with this filter, but i have no idea what without some kind of feedback.

I uploaded what I have so far: https://github.com/jieiku/GradCurve

here are some project files that can be used for testing it: http://www.mediafire.com/file/9nc2et...j/gradcurve.7z

import vapoursynth as vs
core = vs.get_core()
ret = core.d2v.Source(input=r'/media/sf_enc/032t.d2v', rff=False)#Frame 6167
ret = core.resize.Bicubic(clip=ret, format=vs.RGB24, matrix_in_s="709")
ret = core.grad.Curve(ret,var='/media/sf_enc/032t.acv')
ret.set_output()

cd $HOME/.installs/VapourSynthPlugins
git clone https://github.com/jieiku/GradCurve
cd $HOME/.installs/VapourSynthPlugins/GradCurve
./configure
make
sudo make install