VapourSynth Editor

[ChaosKing]

Test5.1: When you resize the window, shouldn't the "current cursor" stay on the current timestamp? Currently it stays relative the the right border.
See here https://i.imgur.com/VovMguf.gifv

[Myrsloik]

My #1 wish for vsedit would be a better code completion system. The current one only works for plugins and only if you write core.std.... ; clip.std. does not work + it writes all parameter while often you only need 1 or 2.

There have been some improvements that will show up in the next VS release that really help the completion in other pure python editors so it may be possible to do.

[ChaosKing]

As far as I know the generated "pyi" file only contains plugin stuff. Code completion for py modules / VS-Scripts in vsedit would be the best feature (for me at least :D)

I think some people use Visual Studio Code? But how do they handle video preview?

[DJATOM]

I'm using Visual Studio Code + VSPreview (https://github.com/Endilll/vapoursynth-preview) to write scripts.
It's not that difficult to combine VSPreview with VS Code: create folder ".vscode" in your working folder (where vpy scripts placed), put file launch.json (https://pastebin.com/aPfx98WB) in it and press F5 or Ctrl+F5 on active editor tab to run it.

[lansing]

Test5.1: When you resize the window, shouldn't the "current cursor" stay on the current timestamp? Currently it stays relative the the right border.
See here https://i.imgur.com/VovMguf.gifv

It did stay, the frame indicator didn't move when drag resizing the window.

[lansing]

What is the advantage of current separate script + preview window ui design than the combined design? I can see that it's more compact but 99% of the time people are going to be working on both the script and the preview at the same time, why the separation? And this came with a price, as an user for many years, the thing I found annoying is that the script window does not pin to the top, so when working with maximized/bigger preview window, every time I clicked on the preview window, the script window would go under and disappeared. And to make it come back again, I would have to go into my taskbar with 10+ programs icons on the bottom of the desktop looking for it, it's not a good user experience.

And to add multi-tab functionality on top of this...I think eventually it's going to come to a conclusion that it will need a new ui design, and the first thing to this is to join the script and preview windows back together.

What's your thought on this? How is your experience with the separate window design?

[_Al_]

What is the advantage of current separate script + preview window ui design than the combined design?
Exactly my thoughts, we have a Python working here so no separate EXE or command line is needed. This is Avisynth-Vapoursynth difference that favors vs.
You tried that my preview solution. Quick zooms, crops with mouse, fast to see differences between clips. Preview is popping on desired coordinates (argument position) even preview dimensions could be put as arguments. Also it should be kept simple and light weight.

Preview([clip, fixed_clip]) within script itself within Python editor. Works just fine. Preview as a python module.

But if some proper developer would tackle this, it could really go further.
Also if in that module is put:
if __name__ == '__vapoursynth__':
return
preview would be ignored if using with vspipe if someone forgets to delete calling that preview function.

[DJATOM]

Separate is better if you have 2 monitors: one can handle text editor and the other one can show preview.

[lansing]

Separate is better if you have 2 monitors: one can handle text editor and the other one can show preview.

Okay I’ll keep it then. I think a better setup would be a detachable window, where the script editor window can be detached from the main window for dual monitor workflow, while single monitor user can work under one single window.

[lansing]

Exactly my thoughts, we have a Python working here so no separate EXE or command line is needed. This is Avisynth-Vapoursynth difference that favors vs.
You tried that my preview solution. Quick zooms, crops with mouse, fast to see differences between clips. Preview is popping on desired coordinates (argument position) even preview dimensions could be put as arguments. Also it should be kept simple and light weight.

Preview([clip, fixed_clip]) within script itself within Python editor. Works just fine. Preview as a python module.

But if some proper developer would tackle this, it could really go further.
Also if in that module is put:
if __name__ == '__vapoursynth__':
return
preview would be ignored if using with vspipe if someone forgets to delete calling that preview function.

I think Preview need a more thought on how to output the comparison clips. It’s not what people would do when comparing results. Avspmod’s way makes the most sense, don’t touch the original script and make a copy of it to make changes there. And if you don’t like it, you can simply throw it away, fast and easy. With Preview it would be painful to remove when the script gets big.

[_Al_]

I think Preview need a more thought on how to output the comparison clips. It’s not what people would do when comparing results. Avspmod’s way makes the most sense, don’t touch the original script and make a copy of it to make changes there. And if you don’t like it, you can simply throw it away, fast and easy. With Preview it would be painful to remove when the script gets big.
This is about preference, comparing scripts vs. comparing VideoNodes within one script.

Comparing VideoNodes does not need to be re-thought because it is just different way of working with scripts. It just does not work for you or others I totally get it because workflow is different, saving scripts, forking them all the time.

But of course , you can even use both at the same time. When putting script together I'd always fork them anyway. Making a fork just to see one different value seams a bit too much though. Or to loop some values. Or do not forget you can simply import videonode output index from other script if you want some elaborate / sample comparison. This is Python, things could be done in more ways.

[lansing]

This is about preference, comparing scripts vs. comparing VideoNodes within one script.

Comparing VideoNodes does not need to be re-thought because it is just different way of working with scripts. It just does not work for you or others I totally get it because workflow is different, saving scripts, forking them all the time.

But of course , you can even use both at the same time. When putting script together I'd always fork them anyway. Making a fork just to see one different value seams a bit too much though. Or to loop some values. Or do not forget you can simply import videonode output index from other script if you want some elaborate / sample comparison. This is Python, things could be done in more ways.

I mean you can do VideoNodes comparison in the backend, but in the front, the syntax needs to be more user friendly. The users should not have to change their entire workflow just to adapt to one feature.

An idea of improvement, let the users start two scripts normally, and then requires them to run a common comparing function at the end of the scripts. And then internally, join the scripts into one implicitly and run Preview(v1, v2...).

[_Al_]

I misunderstood your post #663, hence we are going back and forth. You wanted just UI change where you have script and preview on the same UI.

An idea of improvement, let the users start two scripts normally, and then requires them to run a common comparing function at the end of the scripts. And then internally, join the scripts into one implicitly and run Preview(v1, v2...).
if, then using basic python import:
import other_script
Preview([clip, other_script.clip])
clip output settings are always below Preview() so it is not overwritten by vs. Yes, definitely scary if there is 10 version of scripts. But what if you need to change source file? You change it in all scripts again? That was a pain also using other standalone EXE, could not see simple print() from script so using python editor etc. Naming it *.py not *.vpy. I guess it goes all the way.
If you start to look at it as a python , throwing away avisynths workflows, something new possible will pop up. For example that major pain, changing source file, that comes with changing source filter, indexing etc. It is better to have it automatized and just switching top of the script, in one script. This would not work if you have already 5 other scripts Saved As.

[lansing]

if, then using basic python import:
import other_script
Preview([clip, other_script.clip])


That is good. I didn't know you can do that.


clip output settings are always below Preview() so it is not overwritten by vs. Yes, definitely scary if there is 10 version of scripts. But what if you need to change source file? You change it in all scripts again? That was a pain also using other standalone EXE, could not see simple print() from script so using python editor etc. Naming it *.py not *.vpy. I guess it goes all the way.
If you start to look at it as a python , throwing away avisynths workflows, something new possible will pop up. For example that major pain, changing source file, that comes with changing source filter, indexing etc. It is better to have it automatized and just switching top of the script, in one script. This would not work if you have already 5 other scripts Saved As.

I don't think people who're doing video comparison will change source file much if ever. Why would they? There is no one script fits all, a new video problem will need a new script. And the pain you talked about can be resolved by a find&replace function.

And I doubt many people would save their variant scripts either. You saved the best script and threw away all the others.

[lansing]

Update on my progress, I'm about 80% done. Many days had been spent dealing with exceptions caused by missing dll. And right now I have been hit with both of these which I couldn't ignore (program crashed).

Exception at 0x7ffcc94ba799, code: 0xe06d7363: C++ exception, flags=0x1 (execution cannot be continued) (first chance) at C:\libraries\vapoursynth\src\core\vscore.cpp:1527
Exception at 0x7ffcc94ba799, code: 0xe06d7363: C++ exception, flags=0x1 (execution cannot be continued) (first chance) in dwrite!DWriteCreateFactory

I think I miss some libraries?

UPDATE: I resolved the issue, expect a test build in a day

[l00t]

Hi lansing,

Is this your repo (shared with other authors) on GitHub or a completely different fork:
https://github.com/sandsmark/vapoursynth-editor

Thank you for your answer.

[lansing]

Hi lansing,

Is this your repo (shared with other authors) on GitHub or a completely different fork:
https://github.com/sandsmark/vapoursynth-editor

Thank you for your answer.

No, my fork is here:
https://bitbucket.org/gundamftw/vapoursynth-editor/src/master/

[l00t]

I see, thanks! Is it possible to merge/adapt the bugfixes from there?

[lansing]

Test 6 (https://www.mediafire.com/file/btn6gewftp89b9u/Vapoursynth_Editor_test6-build-64bit-gcc.7z/file) up, finally. Now with a detachable multi tab ui.

I want to make a correction first on Mystery Keeper's view on multi tab implementation. I was wrong on that he wanted a multi process design, he was talking about a single script with multiple output nodes (https://forum.doom9.org/showthread.php?p=1849241#post1849241) design, it would be what _Al_ is doing now.


I ended up with a single process multi tab design myself. The development process is longer than expected, I had spent a lot of days dealing with debugging messages that didn't tell me anything. For example it took me two days to find out that MingGW doesn't build 64 bit debugging build (the program didn't tell me that) while I don't have 32 bit Vapoursynth installed.

New feature highlight:
- Multi tab support
- Script window can be detached from preview window
- Logging window can be hidden
- Bookmark manager integration with multi tab support
- Timeline view control integration with multi tab support

All previous menu functions should work I think. Right click context menu not working yet.

[ChaosKing]

Some things I noticed in test6

How can I attach the script window back again?
It would be good if the current frame (cursor) position could be changed globally for all tabs (usefull for comparing multiple frames) otherwise I need the adjust the coursor for every tab every time...
FI "Frame info" is simple but usefull. It would ne nice if I could copy the current pixel color with right click or so
Can we get the same default font like in R19?
I tried to change the font, but vsedit crashed after I hit save

[lansing]

Some things I noticed in test6

How can I attach the script window back again?
It would be good if the current frame (cursor) position could be changed globally for all tabs (usefull for comparing multiple frames) otherwise I need the adjust the coursor for every tab every time...
FI "Frame info" is simple but usefull. It would ne nice if I could copy the current pixel color with right click or so
Can we get the same default font like in R19?
I tried to change the font, but vsedit crashed after I hit save

Double click on the script window and it will dock back. Or you can just drag it to the left side of the main window and it will dock back automatically.

Similar script comparison not implemented yet. I still couldn't decide how should the scripts be tied. Should the program detect similarity and lock them automatically or have the user lock them manually?

Next test build will fix the setting crash.

The theme is an area that I have never looked at because it was so confusing to me. I'm going to add a presets loading/saving function for it so I can use what others had made instead of me fiddling it myself.

[_Al_]

I checked that out that test6, comparing clips, but using different scripts.

Is your vsedit version using something like: vs.get_output(0).get_frame(x) to get data for a frame thru vs API?

Then it should not be a problem to implement loading clip name directly (or at least different ouput indexes) to exercise more of actual python. I think python workflows has lots of positives too. So if it is not difficult to implement, why not.

You could distribute those output indexes (if not different clips directly, but that would need to be wrapped into some function) into those different TABS.

[lansing]

Test 7 (http://www.mediafire.com/file/8utda44jk7htn3g/Vapoursynth_Editor_test7-build-64bit-gcc.7z/file) up!

- fixed crash when saving settings
- A new theme preset system for the editor. Theme presets are now saved. Theme presets can be import/export

A rewrite of the theme saving mechanism. Theme presets are now saved to a separate "theme_presets" text file instead of vsedit.config. I learned this the hard way, I had experienced wrong text display and I took the advice to delete the vsedit.config for the reset, which caused me to lose all my code snippets.

[lansing]

I checked that out that test6, comparing clips, but using different scripts.

Is your vsedit version using something like: vs.get_output(0).get_frame(x) to get data for a frame thru vs API?

Then it should not be a problem to implement loading clip name directly (or at least different ouput indexes) to exercise more of actual python. I think python workflows has lots of positives too. So if it is not difficult to implement, why not.

You could distribute those output indexes (if not different clips directly, but that would need to be wrapped into some function) into those different TABS.

No, I am building on what Mystery Keeper had already done. It had one single script processor that takes care of talking to the VS API and fetching frames. And it was closely tied to the timeline and preview area. In my implementation I take this processor and create a new instance of it and attached to every tab.

VS editor was written using C++ version of Qt, not Python.

[lansing]

Test 8 up (https://www.mediafire.com/file/ik06e0tihs2pqog/Vapoursynth_Editor_test8-build-64bit-gcc.7z/file).

- Similar clips comparison feature added. Clips are assign to group automatically on first load. Clips in same group will be sharing the same timeline
- Multiple groups navigation between clips. Frame position and timeline zoom level of groups are remembered
- Continuous playback when switching between clips in the same group

There's a minor issue of a frame flash when switching between clips during playback, I couldn't figure out where it came from.

[poisondeathray]

Thanks;

Does number hotkey tab switching work yet in this version? I can't get it to swap except with mouse click

Minor request -
"copy to new tab" command that avspmod has

[lansing]

Thanks;

Does number hotkey tab switching work yet in this version?

I never tried this routine, how do it work?


Minor request -
"copy to new tab" command that avspmod has
Okay will be added.

[poisondeathray]

I never tried this routine, how do it work?


Whhaaat do you mean ??! You haven't tried it ? That's the absolute "best" part of avspmod IMO ! The hotkey switching . The number keys are hot keys that correspond to the tabs. 1=tab1, 2=tab2, etc... The shared timeline and number keys enable fast swapping. You can check versions of scripts much faster. You can navigate with one hand on the mouse to check different frames, and one hand on the number keys to check different tabs. You keep the same frame number reference (as opposed to something like interleave method, and doing more than a few is difficult with interlave) . It's so handy that I sometimes use avspmod tabs and VSImport to check vpy scripts! But tabs in vsedit makes that unnecessary now. Enabling number hotkeys for tabs is the knockout punch!

VapourSynthMultiViewer attempts does this, but it's a bit buggy


Thanks for the continued improvements :D

[poisondeathray]

"save script as" doesn't seem to work

request:
-right click, tab context menu (popup) . That's where "copy to new tab" is in avspmod. Close tab can be useful too as a right click option, and save script, close tab - to include in that right click context menu . Those types of options require a specific tab to be selected , instead of being "global" - (e.g. so if you right click tab3, it would apply to tab3)

[poisondeathray]

Please include tab names and ability to rename tabs; in avspmod the tab takes on the script name automatically (and tab number pops up when preview activated), but you can right click, rename the tab too. Tab/Script names can help a lot with organization .


Not a huge deal, but in the original version, there were a bunch of commands under edit menu like "comment lines" , "move text block up" etc.... They are missing in this version.

[lansing]

I'll be transferring the remaining main menu options and right click context menu next.

[_Al_]

The number keys are hot keys that correspond to the tabs. 1=tab1, 2=tab2, etc... The shared timeline and number keys enable fast swapping.
You can download view.py (https://github.com/UniversalAl/view/blob/master/view.py) and use it in your script, fast zoom in and hot keys. Needs opencv. There are examples in Readme file that show how arguments could be alternated and compared.
Because vapoursynth = Python, it never hurts to change workflows as if developing python script or scripts.

[poisondeathray]

You can download view.py (https://github.com/UniversalAl/view/blob/master/view.py) and use it in your script, fast zoom in and hot keys. Needs opencv. There are examples in Readme file that show how arguments could be alternated and compared.
Because vapoursynth = Python, it never hurts to change workflows as if developing python script or scripts.

Thanks, I know about this and saw the other thread; it's on my "to learn" list .

[lansing]

I was testing out this lossless webp format when saving snapshot, on a 720x480 anime frame, at highest compression ratio, the png version is 455 KB while the webp version is 4.55 KB, WTF? The webp version is 99% smaller?

[poisondeathray]

I was testing out this lossless webp format when saving snapshot, on a 720x480 anime frame, at highest compression ratio, the png version is 455 KB while the webp version is 4.55 KB, WTF? The webp version is 99% smaller?

No, something is wrong. It should provide better compression, but it won't be less than 1/2 size

Are you sure you're using lossless profile ? If you check with ffmpeg -i input.webp it will identify lossless was used

Subsampling can make small difference too.
Was subsampling the same ? png supports rgb/rgba , webp supports rgb/rgba (actually bgra) and yuv420p/yuva420p . e.g. if you take from DVD directly it might be RGB vs. YV12 version of webp


This was on anime frame
png rgb 403kb
webp lossless rgb 285 kb
webp lossless yv12 283 kb

[lansing]

No, something is wrong. It should provide better compression, but it won't be less than 1/2 size

Are you sure you're using lossless profile ? If you check with ffmpeg -i input.webp it will identify lossless was used

Subsampling can make small difference too.
Was subsampling the same ? png supports rgb/rgba , webp supports rgb/rgba (actually bgra) and yuv420p/yuva420p . e.g. if you take from DVD directly it might be RGB vs. YV12 version of webp


This was on anime frame
png rgb 403kb
webp lossless rgb 285 kb
webp lossless yv12 283 kb

I got this from ffmpeg, don't know what it means

Stream #0:0: Video: webp, yuv420p(tv, bt470bg/unknown/unknown), 720x480, 25 tbr, 25 tbn, 25 tbc
At least one output file must be specified

[poisondeathray]

I got this from ffmpeg, don't know what it means

Stream #0:0: Video: webp, yuv420p(tv, bt470bg/unknown/unknown), 720x480, 25 tbr, 25 tbn, 25 tbc
At least one output file must be specified


Your webp was not using lossless profile, and it was using yuv420p


This is using lossless profile . I recompressed the png, so it says argb instead of yuv420p

Stream #0:0: Video: webp, argb, 720x480, lossless, 25 tbr, 25 tbn, 25 tbc



(EDIT: Clarification - lossless profile for webp only supports argb ; so that difference in 2Kb for RGB vs. YV12 was probably due to different upsampling algorithm)

[lansing]

Your webp was not using lossless profile, and it was using yuv420p


This is using lossless profile . I recompressed the png, so it says argb instead of yuv420p

Stream #0:0: Video: webp, argb, 720x480, lossless, 25 tbr, 25 tbn, 25 tbc



(EDIT: Clarification - lossless profile for webp only supports argb ; so that difference in 2Kb for RGB vs. YV12 was probably due to different upsampling algorithm)

Okay I found the problem. In the code, png and webp format saving are sharing the same "quality" setting. In png, quality 0 means best compression but in webp, 0 means worst quality. Saving webp at quality 100 gives me the lossless tag. I'll fix it.

[poisondeathray]

1) Some issue with viewing alpha channel in a gbrap source (Gray8 as alpha clip) . Affects original vsedit, and this mod . Vdub2 preview ok, VSImport in avisynth of .vpy ok too

clip[1].set_output() #view alpha


Error on frame 0 request:
Resize error -1: invalid graph state L878: !m_state.has_chroma() || m_state.plan



You can try this new LSmash release and this test clip, (or ffms2 supported alpha before too)
https://forum.doom9.org/showthread.php?p=1919446#post1919446
https://forum.doom9.org/showpost.php?p=1919295&postcount=1311



2) I can't find error message or log file in this test version. That error message was from original version


EDIT: more info - I think it has something to do with (matrix,transfer,primaries) props being read , explicitly set, or assumed that vsedit is using for the display. If you load something else that has metadata or values, it will display the alpha

[lansing]

My version and the original version are displaying it fine.

[poisondeathray]

My version and the original version are displaying it fine.

both clip[0] and clip[1] ?

clip[0] is ok for me, the clip[1] gray8 alpha clip has the issue . Not sure what's going on, because it's ok in vdub2

#clip[0].set_output(alpha=clip[1])
clip[1].set_output()

[lansing]

both clip[0] and clip[1] ?

clip[0] is ok for me, the clip[1] gray8 alpha clip has the issue . Not sure what's going on, because it's ok in vdub2

#clip[0].set_output(alpha=clip[1])
clip[1].set_output()

clip[1].set_output is fine for me, I'm seeing the spinning dollar sign in black and white

[poisondeathray]

clip[1].set_output is fine for me, I'm seeing the spinning dollar sign in black and white


Thanks; that's what you should see.

Then it must be some local issue, I'll try to figure it out

If I just re-encode it with qtrle, Gray8 preview works for me .
ffmpeg -i input.mov -c:v qtrle -an output.mov

Or some other PNG+alpha image sequence, or this re-encoded as a PNG+alpha sequence (loaded with imwri.Read, alpha=True) the Gray8 preview works . Not sure why, because it was PNG in MOV to begin with

ffms2 alpha=True has same issue for me, so I doubt it's source filter related


Not sure what's going on...

[Mystery Keeper]

I'm glad someone is actively working on new features. I'm very sorry I haven't been. For the last year my life has been a roller coaster, and I can't tell when I'll be back to active development.

[Myrsloik]

I'm glad someone is actively working on new features. I'm very sorry I haven't been. For the last year my life has been a roller coaster, and I can't tell when I'll be back to active development.

I suggest you name an official successor then. Or you have fork hell in no time... (if it didn't already happen)

[lansing]

Test 9 (https://www.mediafire.com/file/mrbgu8uhuxrslh1/Vapoursynth+Editor+test9-build-64bit-gcc.7z/file) up. I have transferred all the remaining menu/context menu functions that I can see except noted.

Log:

- Fixed webp saving in wrong image quality. Image formats now save with their own quality parameters instead of sharing one single parameter
- Transferred all the remaining menu/context menu functions as well as all the little functions except noted
- Closing handler for multi tab, that is save script on exist confirmation and garbage collections
- Default auto tab naming on creation works correctly now
- Removed bilinear scale mode on preview
- Crop editor temporary removed for new implementation

I removed the bilinear scale mode because I just don't see the usage. People used zoom for cropping and for cropping it needs to be pixel precised. You don't want a scale mode that smoothed out the pixels.

I also removed the crop editor for now because it needs a new window anyway and I'm still gathering ideas. I have checked out several other crop editors and the one from avidemux looks really cool.

Aside from those, I have pretty much completed transferring all the stuff from the original to the new one. After all bugs were fixed in these test builds I'll change it to release. Then it will be time to add new stuffs.

For the continuation of the project, I think I'll do what Staxrip and Staxrip 2 did and rename mine to vseditor 2.

[ChaosKing]

I removed the bilinear scale mode because I just don't see the usage.
I use it sometimes as it shows how the video would look like in a video player later.

The zoom field is a bit strange. If I use the arrow keys the zoom steps are 3x 2x 1x 0.6x 0.2x. Why not 0.5? And why is 0.1 not allowed? When I type 0.3 and then use the arrow keys the next zoom steps are 0.7x 1.1x 2.0x. With 0.5x it jumps to 0.9x :-/
The close all tabs button needs an icon :D

[lansing]

I use it sometimes as it shows how the video would look like in a video player later.

The zoom field is a bit strange. If I use the arrow keys the zoom steps are 3x 2x 1x 0.6x 0.2x. Why not 0.5? And why is 0.1 not allowed? When I type 0.3 and then use the arrow keys the next zoom steps are 0.7x 1.1x 2.0x. With 0.5x it jumps to 0.9x :-/
The close all tabs button needs an icon :D

The zoom steps goes by +-0.2x between 0.2x - 1.0x, and +-1x after that. The arrow keys are not working properly because I totally forgot about them :p . I was testing with mouse control mostly.

The minimum zoom ratio is 0.2x and maximum is 8x. I capped at 8x because anything more than that causes navigation to lag. I think Avspmod have had the same issue but gispos fixed it sometime ago. I'll need to look at his code for guidance.

Is there really a need for 0.1x zoom? I thought 0.2x is really really small already.

[_Al_]

I capped at 8x because anything more than that causes navigation to lag.
Some idea - using zoom as crop and zoom in for previewing rgb clip. This way zooms-in perform even faster than original resolutions. Keeping track for CropAbs() values in memory, values are always relative to original resolution. Then one button could be dedicated to just return to previous zoom. I do it that way. Always performing crops and zooms for all clips so clips could be compared (if loaded more clips) in any zoom state.

[ChaosKing]

Is there really a need for 0.1x zoom? I thought 0.2x is really really small already.
Well I once stacked 24 openings together to find differences :p