Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > VapourSynth

Reply
 
Thread Tools Search this Thread Display Modes
Old 29th January 2017, 15:29   #81  |  Link
xekon
Registered User
 
Join Date: Jul 2011
Posts: 224
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.

Last edited by xekon; 29th January 2017 at 16:33.
xekon is offline   Reply With Quote
Old 30th January 2017, 01:54   #82  |  Link
xekon
Registered User
 
Join Date: Jul 2011
Posts: 224
Quote:
Originally Posted by shekh View Post
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.


Last edited by xekon; 30th January 2017 at 02:02.
xekon is offline   Reply With Quote
Old 30th January 2017, 07:11   #83  |  Link
xekon
Registered User
 
Join Date: Jul 2011
Posts: 224
Quote:
Originally Posted by jackoneill View Post
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:
Code:
LoadPlugin("G:\AviSynth\plugins\DGDecode.dll")
MPEG2Source("G:\moon\enc\GradCurve\032t.d2v", iPP=false)
KillAudio()
ConvertToRGB24()
here is the vapoursynth script(windows):
Code:
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()

Last edited by xekon; 30th January 2017 at 08:01.
xekon is offline   Reply With Quote
Old 30th January 2017, 09:12   #84  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Quote:
Originally Posted by xekon View Post
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.
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 30th January 2017, 11:37   #85  |  Link
xekon
Registered User
 
Join Date: Jul 2011
Posts: 224
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
xekon is offline   Reply With Quote
Old 30th January 2017, 12:14   #86  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
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
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 30th January 2017, 12:20   #87  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
Quote:
Originally Posted by shekh View Post
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
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is offline   Reply With Quote
Old 30th January 2017, 12:22   #88  |  Link
jackoneill
unsigned int
 
jackoneill's Avatar
 
Join Date: Oct 2012
Location: 🇪🇺
Posts: 760
Quote:
Originally Posted by xekon View Post
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:
Code:
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

Quote:
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.

Quote:
Originally Posted by shekh View Post
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.
__________________
Buy me a "coffee" and/or hire me to write code!
jackoneill is offline   Reply With Quote
Old 30th January 2017, 12:38   #89  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Quote:
Originally Posted by Myrsloik View Post
NonononononononononoNOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!11111111111
Tell the truth, you would spend how much time for this whole porting project, 15min maybe?
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 30th January 2017, 12:51   #90  |  Link
xekon
Registered User
 
Join Date: Jul 2011
Posts: 224
Quote:
Originally Posted by Myrsloik View Post
NonononononononononoNOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!11111111111
LOL!

Quote:
Originally Posted by shekh View Post
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.
xekon is offline   Reply With Quote
Old 30th January 2017, 12:55   #91  |  Link
jackoneill
unsigned int
 
jackoneill's Avatar
 
Join Date: Oct 2012
Location: 🇪🇺
Posts: 760
Quote:
Originally Posted by xekon View Post
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.
__________________
Buy me a "coffee" and/or hire me to write code!
jackoneill is offline   Reply With Quote
Old 30th January 2017, 13:05   #92  |  Link
xekon
Registered User
 
Join Date: Jul 2011
Posts: 224
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 is offline   Reply With Quote
Old 1st February 2017, 16:09   #93  |  Link
xekon
Registered User
 
Join Date: Jul 2011
Posts: 224
Quote:
Originally Posted by jackoneill View Post
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.
xekon is offline   Reply With Quote
Old 1st February 2017, 16:13   #94  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
Quote:
Originally Posted by shekh View Post
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.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is offline   Reply With Quote
Old 1st February 2017, 17:08   #95  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Quote:
Originally Posted by Myrsloik View Post
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).
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 2nd February 2017, 03:50   #96  |  Link
xekon
Registered User
 
Join Date: Jul 2011
Posts: 224
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
xekon is offline   Reply With Quote
Old 2nd February 2017, 14:27   #97  |  Link
jackoneill
unsigned int
 
jackoneill's Avatar
 
Join Date: Oct 2012
Location: 🇪🇺
Posts: 760
Quote:
Originally Posted by xekon View Post
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.
__________________
Buy me a "coffee" and/or hire me to write code!
jackoneill is offline   Reply With Quote
Old 2nd February 2017, 15:58   #98  |  Link
xekon
Registered User
 
Join Date: Jul 2011
Posts: 224
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:

Quote:
Originally Posted by shekh View Post
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.
xekon is offline   Reply With Quote
Old 3rd September 2017, 20:48   #99  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,657
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

Code:
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)
lansing is offline   Reply With Quote
Old 26th June 2018, 21:21   #100  |  Link
shader
Registered User
 
Join Date: Jan 2016
Posts: 19
Float version s?!?

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?
shader is offline   Reply With Quote
Reply

Tags
color correct, curves, gradation, vapoursynth, virtualdub

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 15:37.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.