GradCurve VapourSynth plugin port of virtualdub Gradation Curves plugin

[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:
https://s29.postimg.org/nid05e2nr/image.png

then when i run it:
https://s29.postimg.org/5i5bmaw2f/image.png

[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]

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.

[xekon]

After doing some more testing, I started noticing that artifacts were being introduced. On some frames it appears to be working perfectly, but on other frames it is clearly introducing artifacts:

https://s27.postimg.org/d0fluov5v/032t_vpy_100.png

Well that sure is interesting, the artifacts are only introduced on the linux version, the one I installed to windows does not do it. (on windows both debug & release dll work without artifacts)

https://s27.postimg.org/z9651u6df/dbzt_vpy_100_win.png

I just did an encode, to make sure it could be reproduced without VSedit, using the below script:

import vapoursynth as vs
core = vs.get_core()
src = core.d2v.Source(input=r'/media/sf_moon/enc/032t.d2v', rff=False)
src = core.resize.Bicubic(clip=src, format=vs.RGBS)
src = core.grad.Curve(src,'/media/sf_moon/enc/032t.amp',7,1)
src = core.resize.Bicubic(clip=src, matrix=1, format=vs.YUV420P16)
src.set_output()

vspipe --y4m 032t.vpy - | x264 --demuxer y4m - --output 032t.mkv

I still get the artifacts on linux with the encoded file, but not under windows. Does anybody know where or what I should look at to determine the reason for the artifacts?

could this be a vapoursynth bug? I cannot understand why it looks good in windows and makes artifacts in linux.

[jackoneill]

I just did an encode, to make sure it could be reproduced without VSedit, using the below script:

import vapoursynth as vs
core = vs.get_core()
src = core.d2v.Source(input=r'/media/sf_moon/enc/032t.d2v', rff=False)
src = core.resize.Bicubic(clip=src, format=vs.RGBS)
src = core.grad.Curve(src,'/media/sf_moon/enc/032t.amp',7,1)
src = core.resize.Bicubic(clip=src, matrix=1, format=vs.YUV420P16)
src.set_output()

vspipe --y4m 032t.vpy - | x264 --demuxer y4m - --output 032t.mkv

I still get the artifacts on linux with the encoded file, but not under windows. Does anybody know where or what I should look at to determine the reason for the artifacts?

could this be a vapoursynth bug? I cannot understand why it looks good in windows and makes artifacts in linux.

1. Try to remove -ffast-math from configure. It enables potentially unsafe optimisations for floating point math.
2. Try to remove all instances of the type "long" and use (u)int64_t if you want 64 bit integers. The size of long is apparently 32 bits in Windows and 64 bits in 64 bit Linux.

To see if it's a bug in VapourSynth, try your script with the grad.Curve filter commented out.

[xekon]

thank you for the reply Jackoneill, i will try -02, and thanks for telling me how to debug it in linux.

thanks for the reply Are_, very interesting you dont have the bug, that leads me to believe its a problem with the compiler i have on my linux machine, i will try GCC-5.4.0 if thats not what im currently using.

Thank you for the reply Jackoneill. I removed -ffast-math from configure and replace all instances of long with int64_t.
Also if I comment out the gradcurve filter then it does not introduce the artifacts.

After making the changes to the project, the windows one still works, and the linux one still has the artifacts.
could it be anything else in configure that is causing it?

I also tried removing -mfpmath=sse, but it had no effect either.

PS: Also its worth mentioning, the Artifacts, are always in the exact same spot, it is only affecting certain pixels, im gonna try and step through the program to see if anything obvious jumps out at me.
but since I am debugging on windows(where there are no artifacts) I am not so sure that anything will be obvious to me.

[jackoneill]

Thank you for the reply Jackoneill. I removed -ffast-math from configure and replace all instances of long with int64_t.
Also if I comment out the gradcurve filter then it does not introduce the artifacts.

After making the changes to the project, the windows one still works, and the linux one still has the artifacts.
could it be anything else in configure that is causing it?

I also tried removing -mfpmath=sse, but it had no effect either.

PS: Also its worth mentioning, the Artifacts, are always in the exact same spot, it is only affecting certain pixels, im gonna try and step through the program to see if anything obvious jumps out at me.
but since I am debugging on windows(where there are no artifacts) I am not so sure that anything will be obvious to me.

Maybe -O2 instead of -O3, but I doubt that helps.

You can debug it in Linux too. You need to add -ggdb3 to CXXFLAGS and make sure the library doesn't get stripped. Then you can invoke gdb:

gdb --args vspipe script.py /dev/null


To set a breakpoint at line 42 (answer yes):

(gdb) break file.cpp:42


To run the program:

(gdb) run


To step into functions:

(gdb) step


To go to the next line without stepping into functions:

(gdb) next


To print the value of variable "asdf":

(gdb) print asdf

[Are_]

I tied your test clip here but I could not reproduce your bug. GCC-5.4.0

[xekon]

Are_ was kind enough to share their compiled libgradcurve.so which for them did not show the bug, I tried their compiled libgradcurve.so and the bug was still present for me. We compared VSedit and VSpipe versions and theirs was newer, so I thought that maybe that was the issue.

I have reinstalled kubuntu as well as freshly installed vapoursynth and vsedit and all of their dependencies, I am now using the same version of VSedit and VSpipe as Are_ and I STILL have the bug I show in screenshots above.

Can different OSes cause the issue? I am using Kubuntu and they are not, I am considering using another linux distro just to test what could be causing this bug.

I think i may know the problem, the math used to determine the indexes in the color lookup tables may be returning different result on different OSes, (which is a problem in itself.) I am going to think about a better way to do that:

I am referring to these lines:
oldr = srcpR[x]*255;
oldg = srcpG[x]*255;
oldb = srcpB[x]*255;

is there a way I can convert srcpR[x]/srcpG[x]/srcpB[x] to their respective 0-255 values? other than taking that float value and multiplying it by 255?

I am going to find some worse scenes that show the bug more, and try debugging the way that jackoneill pointed out, but I am thinking those 3 line are the most likely culprit....

[jackoneill]

Are_ was kind enough to share their compiled libgradcurve.so which for them did not show the bug, I tried their compiled libgradcurve.so and the bug was still present for me. We compared VSedit and VSpipe versions and theirs was newer, so I thought that maybe that was the issue.

I have reinstalled kubuntu as well as freshly installed vapoursynth and vsedit and all of their dependencies, I am now using the same version of VSedit and VSpipe as Are_ and I STILL have the bug I show in screenshots above.

Can different OSes cause the issue? I am using Kubuntu and they are not, I am considering using another linux distro just to test what could be causing this bug.

I think i may know the problem, the math used to determine the indexes in the color lookup tables may be returning different result on different OSes, (which is a problem in itself.) I am going to think about a better way to do that:

I am referring to these lines:
oldr = srcpR[x]*255;
oldg = srcpG[x]*255;
oldb = srcpB[x]*255;

is there a way I can convert srcpR[x]/srcpG[x]/srcpB[x] to their respective 0-255 values? other than taking that float value and multiplying it by 255?

I am going to find some worse scenes that show the bug more, and try debugging the way that jackoneill pointed out, but I am thinking those 3 line are the most likely culprit....

Make your filter accept (only?) integer clips and give it the video straight from d2vsource, without the conversion to RGBS. Then you can directly use the pointers returned by getReadPtr (they are unsigned char*).

This is a really weird problem.

[xekon]

So far it only happens to very dark colored pixels, mostly on lines and edges, I am hesitant to change it to integer clips, when I may possibly be discovering an underlying bug someplace.
I am still scanning through footage looking for one that displays the bug predominantly, then I will upload another sample and try doing some debugging under linux.

hmm, not sure what I'm doing wrong. It seems to be not honoring the breakpoint. I configured with --enable-debug which is supposed to not strip and keep the debug symbols....


enc@enc-vbox:~/.installs/VapourSynthPlugins/GradCurve$ ./configure --enable-debug
CXXFLAGS/LDFLAGS checking...
checking for vapoursynth headers...

settings...
CXX = g++
LD = g++
STRIP = strip
CXXFLAGS = -O2 -std=c++11 -Wall -Wno-strict-aliasing -I. -I./include -g -msse2 -fPIC -ggdb3 -mfpmath=sse -I/usr/local/include/vapoursynth -I/usr/local/include
LDFLAGS = -shared -fPIC
LIBS =
LIBNAME = libgradcurve.so
install path = /usr/local/lib/vapoursynth
configure finished.

enc@enc-vbox:~/.installs/VapourSynthPlugins/GradCurve$ make
g++ -O2 -std=c++11 -Wall -Wno-strict-aliasing -I. -I./include -g -msse2 -fPIC -ggdb3 -mfpmath=sse -I/usr/local/include/vapoursynth -I/usr/local/include -c GradCurve/GradCurve.cpp -o GradCurve/GradCurve.o
GradCurve/GradCurve.cpp: In function ‘void ImportCurve(GradCurveData*)’:
GradCurve/GradCurve.cpp:374:35: warning: ignoring return value of ‘int fscanf(FILE*, const char*, ...)’, declared with attribute warn_unused_result [-Wunused-result]
fscanf(pFile, "%d", & stor[i]);
^
g++ -o libgradcurve.so -shared -fPIC GradCurve/GradCurve.o

enc@enc-vbox:~/.installs/VapourSynthPlugins/GradCurve$ sudo make install
install -d /usr/local/lib/vapoursynth
install -m 755 libgradcurve.so /usr/local/lib/vapoursynth

enc@enc-vbox:~/.installs/VapourSynthPlugins/GradCurve$ gdb --args vspipe /media/sf_moon/enc/003a/003a.vpy /dev/null
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from vspipe...(no debugging symbols found)...done.
(gdb) break GradCurve.cpp:604
No symbol table is loaded. Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (GradCurve.cpp:604) pending.
(gdb) run
Starting program: /usr/local/bin/vspipe /media/sf_moon/enc/003a/003a.vpy /dev/null
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffd20e1700 (LWP 2130)]
[New Thread 0x7fffcc428700 (LWP 2131)]
Output 9 frames in 0.09 seconds (103.69 fps)
[Thread 0x7fffcc428700 (LWP 2131) exited]
[Thread 0x7fffd20e1700 (LWP 2130) exited]
[Inferior 1 (process 2126) exited normally]
(gdb)


I never get the chance to use step, next, or print, because the breakpoints are not firing.

Did I miss something, is there a setting I should double check? or maybe I should compile differently? more manually?


I am thinking I should setup an IDE on kubuntu for compiling and debugging c++, maybe I will try eclipse, or possibly netbeans?

after a bit of reading it seems many of the IDEs available for linux, dont allow you to view a variables value breakpoint/watchpoint but gdb does, so I really should figure out what it is im doing wrong.

gonna atleast give Code::Blocks a try.

EDIT: code::blocks is not stopping at the breakpoints either, I removed the original GradCurve library to make sure it was not being used, and set my script to load the debug library that code::blocks generatd. I will keep plugging away at it, trying different thing, surely i'll figure it out eventually. So frustrating when try something intuitively and it does not work the way you expected it to.

[jackoneill]

hmm, not sure what I'm doing wrong. It seems to be not honoring the breakpoint. I configured with --enable-debug which is supposed to not strip and keep the debug symbols....


Now you know why this set of GNUmakefile and configure sucks. :) Even though lots of people adopted them. It does strip the library. It may work better if you add this under line 110 in configure:

STRIP=""

(Consider it a temporary workaround, not a proper solution.)

[xekon]

Thank you for the reply jackoneill, gonna give that a try today!

very interesting, I thought only linux was displaying this bug, however my windows machine does to, just to a much lesser degree, and less frequently, here is a scene that does it in both windows and linux

here is the sample: http://www.mediafire.com/file/5gsfbg3a7ubahnh/003b.7z

Linux Kubuntu 16.10_64:
https://s24.postimg.org/vqfhfaoit/003b_vpy_0.png

win7_64:
https://s29.postimg.org/udch64rsn/003b_win7_vpy_0.png

going to finish debugging this, and then probably change it to use integer clips instead :)

[xekon]

woa, if you go back and forth between the windows and linux ones.... the blacks are WAAAY darker on the linux one (atleast they are on my linux install)
I commented out my plugin, the linux one is still waaaay darker, so its not my plugin doing it, why is there a difference between the linux one and the windows one?

edit: the three lines that I thought were the problem, indeed were, I made the following change:

oldr = srcpR[x]*255;
if (oldr < 0) { oldr = 0; }
if (oldr > 255) { oldr = 255; }
oldg = srcpG[x]*255;
if (oldg < 0) { oldg = 0; }
if (oldg > 255) { oldg = 255; }
oldb = srcpB[x]*255;
if (oldb < 0) { oldb = 0; }
if (oldb > 255) { oldb = 255; }
that way they would not be out of range of the index, it works, but it seems messy, I think I should still modify this to only use integer clips, but feedback on this is welcome.

edit: updated the github to include this bugfix: https://github.com/jieiku/GradCurve

EDIT:
I added the greater than 255 checking for good measure, but that is not what was setting off the bug.

the bug was happening when a value was less than 0, therefore beyond the index, but the math is to take the source pointer(getReadPtr) and multiply it by 255.... the only way I could see it getting a value less than 0 is if one of those source pointers were returning a negative value? is that supposed to ever happen in vapoursynth?

[TheFluff]

Floating point chroma is typically in the range -0.5 to 0.5, but I don't know if you're accepting YUV input? You're not getting integer wraparound, are you?

Also, clamping a value x to a range is usually written in an ideomatic fashion using min and max, like so:
min(max(0, x), 255)

[jackoneill]

You can have float pixels with values outside the "legal" ranges in VapourSynth. However, I'm not sure the resizer is supposed to create such pixels in this case.

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.

PS. The range -0.5..0.5 applies to U and V channels. RGB channels all use the range 0.0..1.0.

[feisty2]

You can have float pixels with values outside the "legal" ranges in VapourSynth. However, I'm not sure the resizer is supposed to create such pixels in this case.

it's supposed to keep out of range pixels like that with floating point samples.
the only exception would be a floating point mask clip, which should be clamped to [0.0, 1.0]

[xekon]

Floating point chroma is typically in the range -0.5 to 0.5, but I don't know if you're accepting YUV input? You're not getting integer wraparound, are you?

Also, clamping a value x to a range is usually written in an ideomatic fashion using min and max, like so:
min(max(0, x), 255)

I am using RGBS input vis this line before going to my plugin, not sure how to check if its integer wraparound, i will need to read up on that, can't say i've ran into it before.
src = core.resize.Bicubic(clip=src, format=vs.RGBS)

jackoneill I didn't realize that about the d2vsource, I will get the appropriate version.

so did I find a bug? or is this normal behavior and I should just use integer input only for my plugin to solve this?

[jackoneill]

so it sounds like the out of range pixels will only be an issue using floating point?

Not quite. If you have a 9..15 bit clip, filters can produce pixels with values greater than the bit depth's maximum, up to 65535. I think this can be considered a bug, though, i.e. someone else's problem.

[feisty2]

I am using RGBS input vis this line before going to my plugin
src = core.resize.Bicubic(clip=src, format=vs.RGBS)

so it sounds like the out of range pixels will only be an issue using floating point? if so then I am probably best off just converting this plugin to only accept RGB integer input.

the out of range pixels will only NOT be an issue using floating point.

[xekon]

oh.... hmmm that's a conundrum.... so should I just clamp it like im doing for now and call it lovely?

as of my last update to github, the plugin appears to be working correctly to my eyes, thats not to say i'm not overlooking something.

I really want to make this filter function properly, would suck to encode a bunch of stuff only to discover that this plugin introduced a subtle problem into the video that I didn't realize lol.

[xekon]

oh, I got an idea, at the very least I could compare the output results of this plugin with the original gradation curves plugin... I think there are differences in colorspace conversions though, so I dont know if i'de be able to test for an exact match or not.

[shekh]

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

[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]

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.

https://s30.postimg.org/t1cdiwrgh/medium_not_needed.jpg

[xekon]

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.php?p=1795154#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:
https://s24.postimg.org/f7jpd4mmd/testing.jpg

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]

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]

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]

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.php?p=1795154#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/apireference.html#reserved-frame-properties
http://www.vapoursynth.com/doc/functions/setframeprop.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.

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]

NonononononononononoNOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!11111111111

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

[xekon]

NonononononononononoNOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!11111111111

LOL!

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]

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]

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]

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]

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]

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:

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?