Watermark?

[DrPhill]

Is there a filter/function for 'watermarking' a video?

By 'watermarking' I mean writing text by deforming the video - an effect like placing glass lettering on top of a picture. Or anything similar would do - adding text without hiding too much of the video.

I imagine that this has already been done, but do not know what to search for.

Thanks in advance for any help you may be able to give.

Phill

[StainlessS]

Try search on "logo watermark" perhaps limiting to the Avisynth Usage forum.

EDIT: or to find those words including CODE blocks in search, google

logo watermark site:forum.doom9.org

[LoRd_MuldeR]

Maybe the standard Overlay filter will work for this:
http://avisynth.org/mediawiki/Overlay

If you have a 32-Bit PNG file with proper Alpha (transparency) information, it can be applied like this:

Image = ImageSource("C:\Your Overlay.png", pixel_type="RGB32")
Overlay(Image, mask=Image.showAlpha())

[DrPhill]

Maybe the standard Overlay filter will work for this:
http://avisynth.org/mediawiki/Overlay

If you have a 32-Bit PNG file with proper Alpha (transparency) information, it can be applied like this:

Image = ImageSource("C:\Your Overlay.png", pixel_type="RGB32")
Overlay(Image, mask=Image.showAlpha())

That does a basic subtitle, which could be semi-opaque. I was hoping for something a bit more slick. Imagine putting a caption made of glass - you would still see the image, and the image on the flat top of the text would be simply displaced. The image around the vertical sides of the glass text would be stretched and compressed depending upon where it was. I just thought that it would be a neat effect.

Maybe I need to work up an algorithm.....

But thanks anyway for the suggestions.

Phill

[ajk]

You could probably achieve something like that by using the mask to cut out the corresponding area of the image and shrink/expand/displace it by a little. Do this a couple of times and then overlay them all on top of each other on the original image. Add a bit of blur if needed.

[pandy]

sounds like perfect task for http://forum.doom9.org/showthread.php?t=161852

[DrPhill]

You could probably achieve something like that by using the mask to cut out the corresponding area of the image and shrink/expand/displace it by a little. Do this a couple of times and then overlay them all on top of each other on the original image. Add a bit of blur if needed.

Indeed, ajk, that is the sort of thing I imagined doing, but maybe in a filter, as there might be a lot of processor cycles wasted. I am not if I would need 'transparency' in the recombination. For example, the flat top would merely be a displaced image.

But it is certainly worth kicking these ideas arround as I have not thought them out well enough yet.

Phill

[DrPhill]

sounds like perfect task for http://forum.doom9.org/showthread.php?t=161852

It may well be, pandy, but is that OpenGL stuff a steep learning curve? I have never been near it before, but it may make a useful diversion.

(I started with leaning to play the whistle, then recording and mastering the tunes, then on to making videos, followed by video editing, writing AVISynth plugins in C, now OpenGL? 'What a long strange trip its been....)

[DrPhill]

Turns out that it is relatively simple - I have attached a zip with the DLL and a sample script. I left out the example mpg as it was fairly large and I am sure you all have some samples.

I will tidy up the code and documentation if there is enough interest. Let me know what you think.

Thanks

Phill

[Emulgator]

Virtualdub says "Access violation in watermark.dll" and collapses.
WinXPSP3, Graphic card GTX7950.

[DrPhill]

Thanks Emulgator (I think!). And sorry for any wasted time.

Seemed to work alright in AVISynth. I am not sure what to do now - I have no idea how to debug a plugin. I cannot see me mustering the enthusiasm to learn what I need to build an industrial strength solution - at least not while it is doing what I want. I can make the source code available to anyone interested.

The effect of the filter is to deform the clip as if there are lumps behind the screen. The lumps are defined by a black-and-white clip.

Phill

[librarian]

No problem here (win 7 home premium 64). Good work!
http://img195.imageshack.us/img195/7822/maschera0000.png

[DrPhill]

No problem here (win 7 home premium 64). Good work!

Thanks for the reassurance, Librarian. I have probably messed up slightly with my pointer arithmetic, but in a way that does not show on our platform. I have a couple of mods to sort out, then I will tidy the source code and publish it.

Maybe someone will give it the once-over for mistakes.

Phill

[Emulgator]

Looks good !
The GTX7950Go supports up to Open GL 2.0, maybe this is not enough...
I will try my luck later on...

[DrPhill]

Looks good !
The GTX7950Go supports up to Open GL 2.0, maybe this is not enough...
I will try my luck later on...

I do not use OpenGL - I never got as far as investigating it. I hand-coded this in C..... (which is probably why you get access violations).

I am grateful to Librarian for posting a pic. Some notes:
- the width of the border around the watermark is parameterised.
- the maximum intensity of lightening/darkening of the border is parameterised
- the lightening/darkening is graded from watermark to background
- the offset of the image in the watermark is parameterised

This means that the effect can be altered from very subtle to very not-subtle.

[DrPhill]

I am tidying up the code.

I have added some features:
- Specify light direction
- Specify light amount
- soft or hard edges
- depth
- image displacement

Are there any other features that might be useful?

I wondered whether making it dynamic would be good - the watermark could move/change. This may slow processing down a bit but should be simple to implement.

I also wondered if using a grey scale to indicate the height/displacement might be effective. I am not sure how I would calculate the lighting though. Any thoughts?

Would a colour shift be useful in the watermarked area?

Any thoughts appreciated.

Phill

[DrPhill]

OK, dynamic watermarking was simple. New DLL attached.

I have a new filter for testing called moveIt which can be used to move the watermark in a fairly boring fashion to illustrate that this works dynamically. Details in example.avs in the zip.

Feedback welcome, as are offers of help to make the C code up to 'platform independent' quality.

Thanks

Phill

[librarian]

Nice effect!
I'm wrong (my eyes aren't so good and my monitor is worse) or during horizontal motion there are jaggy edges on watermark?
Platform independence for an Avisynth plugin?

[DrPhill]

Nice effect!Thanks - and with motion it goes beyond my initial goal, and opens up some interesting posibilities. I am now investigating tools to create animated 'watermarks'. Floating music notes and the like...... Gimp is a contender.
I'm wrong (my eyes aren't so good and my monitor is worse) or during horizontal motion there are jaggy edges on watermark?There seem to be some interesting effects, but I think it is the way the combination of movement and distortion* is interpreted. The distortion* is the deliberate distortion blending from background to watermark with increasing/decreasing image offset.
Platform independence for an Avisynth plugin?Certainly. It functions as a plugin on at least two machines (thine and mine) so it is on the way to being useful. I really just bashed together an algorithm in C without worrying too much about portability and the like. I have been spoilt by Java I guess. And this shows in as much as Emulgator had problems - and I have neither the knowledge nor the tools to do much about it.

I have commented the code and will create a SourceForge project for it.

Phill

[librarian]

A (not too quick) experiment. I created a virtual machine with Virtual Box (latest available version, freshly downloaded) and installed Windows XP SP3 professional, Avisynth 2.5.8 and Xvid 1.3.2.
I run your script, the result is the expected one (see linked image (http://imageshack.us/photo/my-images/835/testwatermarkxp.png/))
Therefore there are at least 3 machines which can run your plugin:yours,mine,a virtual XP (but I think there are many more):-)
If I find the time I'll try with linux and wine.

[DrPhill]

A (not too quick) experiment. I created a virtual machine with Virtual Box (latest available version, freshly downloaded) and installed Windows XP SP3 professional, Avisynth 2.5.8 and Xvid 1.3.2.
I run your script, the result is the expected one (see linked image (http://imageshack.us/photo/my-images/835/testwatermarkxp.png/))
Therefore there are at least 3 machines which can run your plugin:yours,mine,a virtual XP (but I think there are many more):-)
If I find the time I'll try with linux and wine.

Thank you, Librarian. It is very good of you to take the time to verify this. Are your machines 64bit or 32? Mine is 64, and I could believe that there are portability issues between the two (though it is a long time since I have had any dealings with those deep layers, so I could easily be wrong).

I will check my wife's machine which may be 32 bit (XP) and if so give it a run on there.

When I get some quiet time (later today?) I will create a SourceForge project (is that the preferred vehicle?) , upload the source code and executable, and add a note on this forum (new plugin thread?).

Phill

[librarian]

Real machine win7 64 bit
Emulated machine win XP SP3 32 bit
On both computers Avisynth 32 bit 2.5.8, Virtualdub 1.9.11, xvid 1.3.2

[DrPhill]

I have created a project on SourceForge for this:

https://sourceforge.net/projects/watermarkplugin/

I will add a note to the new plugin thread

[librarian]

Tested on linux Ubuntu 10.04 LTS 32bit, Wine 1.2.2. , usual versions of Avisynth, Virtualdub, Xvid.
See output here (http://imageshack.us/photo/my-images/217/schermata1rv.png/).

[TheFluff]

I have not tested the filter but here are some source comments. I haven't really read all of the source, I mostly just skimmed it looking for suspicious things.

moveit.cpp

You #include "Watermark.h" but this file isn't actually included in the source archive.
File is called .cpp but you use no C++ functionality except the "new" operator. You use the Avisynth C interface rather than the C++ interface, too. Why not use plain C and replace new with malloc()? The problem with this is that you can't really compile C with MSVC, since it'll enforce C89 strictly (have to declare all local variables at that very top of the block, etc).
struct moveit_Params is pretty weird; it's mostly a subset of the Avisynth VideoInfo struct (AVS_FilterInfo->vi). Several of the values are hardcoded and never changed; they should probably be enums or defines instead.
Related to the above, since curX and curY depend on dx/dy and are calculated iteratively each time moveit_GetFrame() is called, behaviour will most likely not be what you expect it to be if frames are requested out-of-order. Since Avisynth doesn't have a way of guaranteeing linear access, filters must support random access. In other words, your filter must support delivering any given frame without being dependent on having the state for the frame preceding it in the video cached, since that frame might not have been requested yet.
Still related: since you only initialize moveit_Params once, you set the source pitch upon filter initialization and never again after that. That means you assume the source has constant pitch. This is not a safe assumption and will lead to crashes if the surrounding script is sufficiently complicated in the right way (http://forum.doom9.org/showthread.php?t=161437). You must call avs_get_pitch() on the source frame every time you get it.
On line 96 you write y++, but on line 97 you write x += 1. It's nice to be consistent. :)
The loop on lines 118-120 might possibly be faster if you copied a 32-bit word at a time instead of a byte at a time, but this is just speculation. I suggest you test it.
The memory allocated for the moveit_Params instance in the filter constructor is never freed when the filter is destroyed.


Watermark.cpp
No comments except again the .cpp/.c debate.

Watermark3.cpp

Any and all variables that have something to do with the size of an array (that is, a memory block) or an offset thereof should probably be declared as size_t rather than int. This guarantees it'll work properly in 64-bit mode too. You may have to include stddef.h to get the size_t typedef.
wm3_Params: most of the things that apply to moveit_Params apply to this as well, including the constant pitch assumption.
wm3_Params->hLight and wm3_Params->vLight: you should probably use #defines to avoid the magical numbers here.
Lines 45-46: while it's not strictly wrong to allocate an array of integers in C++ with new int[size]; it's usually not done that way. If you want a plain array of a basic datatype, use malloc(). Operator new is generally used only for class instantiations.
Lines 84-85: all-caps identifiers in C++ are generally reserved for typedefs, enums and preprocessor defines. Again, it's not wrong to use them, it's just that it's usually not done that way.
The loops in wm3_buildMask are extremely deeply nested; the innermost loops should probably be broken out into their own functions (the logic is very similar in many of the loops and it could most likely be generalized). Or you could rethink your algorithm.
Sorta stopped reading there; got sleepy. Sorry.


In general it seems like the effects of this filter could be duplicated fairly easily with existing filters, for example FluaG.

Regarding portability: it's not very meaningful to try to make Avisynth plugins portable, since Avisynth itself is so extremely unportable and the plugins aren't useful without it. Still, your code seems portable enough. It doesn't include any Windows headers at all and there are no particular MSVC-isms that I could spot.

Seemed to work alright in AVISynth. I am not sure what to do now - I have no idea how to debug a plugin.

If you have Visual Studio (you really should, if you are writing Avisynth plugins), it's pretty easy. Make sure your plugin isn't getting autoloaded (i.e. remove it from the Avisynth autoload directory), then create an Avisynth script that explicitly autoloads the debug build with LoadPlugin(). Make sure you load the output file generated by Visual Studio and not a copy you made yourself.

Now go to the project properties in Visual Studio. Hit the debugging tab, set the debug command to run to X:\path\to\virtualdub.exe and the commandline to X:\path\to\debug.avs. Set a breakpoint on AvisynthPluginInit2 (or the Avisynth C equivalent, or just your GetFrame implementation) and hit start debugging. When you do that VS will warn you that it can't find debugging symbols for virtualdub.exe; don't worry about that and just tell it to continue. You'll hit your breakpoint and now you're running your plugin in interactive debug mode. Go hog wild.

[DrPhill]

Thank you TheFluff, for taking the time to examine my code and to comment here. There is a lot that is very helpful.

Forgetting the header file is a big blooper - I will correct that soonest.

If codeblocks will compile *.c files in exactly the same way as *.cpp files, then I will change the names. I only used .cpp as I followed instructions on how to write a C interface plugin and that is what it said. That means that I will also have to use malloc and free rather than new and delete, but that is fine with me.

Not freeing the params block is a definite blooper.

The moveit funtion was just there to demonstrate that the watermark was dynamic, and that the algorithm could cope with edges. Anything problems specific to if can be documented.

I did not realize that sourcePitch could change, and I am not sure that my algorithm would handle that gracefully... will change the code.

The comments about size_t make a lot of sense - I vaguely remember them from an embarrassingly long time ago. They could easily be the source of crashes.

#defines for vLight and hLight are a good idea

the uppercase was left over from when the values were constant - will change.

The nested loops are fairly ugly. - they just sort of grew. I will think about rewriting the algorithm - that is the bit I like doing the most.
--------------------------------------------------------
I actually wrote the thing because the learning curve for the non-built-in filters seemed steeper than coding my own! Some scripts were suggested by experience folk here, but it seemed that things that I did not understand failed in ways that I could not describe for reasons that were unfathomable to me.

I understand what you are saying about portability - so that is one less goal to aim for. I did try to keep my C as simple as possible so that others could use/compile it should they wish.

As far as debugging goes - thanks for the info, but I will try to avoid that. :-)
-----------------------------------------------

So in summary, thank you, you comments are greatly appreciated and will guide me to improve the code. I am working this weekend, but hope to have the improvements up by the end of Monday (but likely before if the weather is bad).

Phill

[DrPhill]

I just tried changing the files to *.c, and started getting a compilation error that I do not understand:
C:\Users\Phill\VideoProject\Watermark\Watermark.c|26|error: conflicting types for 'avisynth_c_plugin_init'|

Added to the possibility of getting irritated by strict C89 enforcement I think I will revert to using a C++ compiler.

Phill

[Gavino]

I just tried changing the files to *.c, and started getting a compilation error that I do not understand:
C:\Users\Phill\VideoProject\Watermark\Watermark.c|26|error: conflicting types for 'avisynth_c_plugin_init'|
To be consistent with avisynth_c.h, it should be defined as
AVSC_EXPORT const char * AVSC_CC avisynth_c_plugin_init(AVS_ScriptEnvironment* env) {

[DrPhill]

To be consistent with avisynth_c.h, it should be defined as
AVSC_EXPORT const char * AVSC_CC avisynth_c_plugin_init(AVS_ScriptEnvironment* env) {

OK, thanks Gavino, I will go back and do that when I revisit c++ --> c conversion of the source code.

Phill

[Gavino]

If codeblocks will compile *.c files in exactly the same way as *.cpp files, then I will change the names. I only used .cpp as I followed instructions on how to write a C interface plugin and that is what it said. That means that I will also have to use malloc and free rather than new and delete, but that is fine with me.
Another change you will have to make if moving to a pure 'C' source is you can't use struct tags as type names, eg
struct wm3_Params {
...
};

void wm3_initialise(wm3_Params* params, ...
You would have to add typedefs, eg
typedef struct wm3_Params {
...
} wm3_Params;

[DrPhill]

Thanks, Gavino..... it just gets better:(.

Phill

[DrPhill]

I have done some code tidying and put the results (source and dll) up on SourceForge as 'second cut'.
For convenience I have added the files as an attachment to this note (Moderators: If this is frowned upon, then my apologies, and please feel free to remove them).

Changes - I have:

Used malloc/free instead of new/delete.
Used size_t where it seemed appropriate.
Set the values in params for each frame get.
malloced memory for the duration of frame get (is this a good or bad idea?).
Used some #defines to clarify code.
Reorganised the main algorithm to make it clearer (an a little slower, probably).


While doing this I removed a bug that could cause a memory access violation, so the problems seen by Emulgator may, just may, have gone away. I cannot promise anything though, but it did need fixing......

I think I addressed most things in the list by TheFluff. I will look at converting the files to *.c from *.cpp next.

I am not sure that I can improve the algorithm - I need to do work around boundaries between watermark and not watermark. It seems to me the quickest way to reduce workload is to detect the boundaries first, and work from them. I would be perfectly happy to be shown to be wrong, though.

Thanks all.

[DrPhill]

I think I have spotted a blooper. Can someone confirm that increasing pixel coordinates go from left to right and bottom to top? I had assumed left to right and top to bottom, so I may need to change some of my comments/constants..........

Thanks

[Gavino]

For RGB clips (but not YUV), frames are stored 'upside-down', so yes, there the coordinates do go from bottom to top.

[DrPhill]

For RGB clips (but not YUV), frames are stored 'upside-down', so yes, there the coordinates do go from bottom to top.

Thanks Gavino..... so if I comment it correctly for one it will be incorrect when(if) I implement the other :D. Ah well, I will comment it correctly for the RGB. And make a note when (if) I implement YUV. Since my algorithm is almost entirely symetric about the vertical and horizontal axes it probably matters little.

[Yanak]

Old thread and plugin but does some very interesting things, digging in this forum is full of surprises, the author have not logged since years apparently but i have 2 little questions, maybe one of the knowledge guru's of this forum can help :

- Is there a x64 version of this of this available somewhere please ? It will be really great.
For now i have to use MP_Pipeline to make it work in my x64 workflow:
MP_Pipeline("""
### platform: win64
LoadPlugin("H:\LSMASHSource.dll")
LSMASHVideoSource("H:\00.mp4", format = "YUV420P8").ConverttoRGB32
### ###
### platform: win32
LoadPlugin("H:\test\Watermark.dll")
myWatermark = ImageSource("H:\03.png", pixel_type = "RGB32")
Watermark(watermark = myWatermark, displace = 20, light = 200, depth = 6, softEdge = true, lightFrom = "NE")
### ###
""")
Result : https://s14.postimg.org/7wl2fcvwx/183093avisynthr1858x64.jpg

- The input video needs apparently to be converted into RGB32 which isn't always the best thing, so I'm wondering if it is possible with avs+ to do something like :
LSMASHVideoSource("H:\00.mp4", format = "YUV420P8").AddAlphaPlane()

Tried this quickly but i get a returned message telling me the video needs to be on a single plane, maybe i am using the AddAlphaPlane incorrectly... i don't know :confused:

Too bad the part about moving the watermark was not finished apparently, this could really have been a great plus if we could have set some coordinates to define a part of the video where the watermark had to move inside, this could have been a terrific thing but even without this option it's a nice little tool.

For now i will be more than happy with a x64 version of this plugin to bypass MP_Pipeline and a way to convert my input sources with the minimal quality loss possible or no loss of quality at all with something like like adding only an alpha channel to it ( i maybe misunderstood how exactly this function is supposed to work tho)

If anyone have any infos about a possible x64 version of this little thing or ideas to bypass the ConverttoRGB32 step with no loss of quality i will be really grateful.

Thanks in advance for any help.

[DrPhill]

Long time since anyone posted on this thread...... I have not thought of this stuff for ages. :o

The source code is up on sourceforge (https://sourceforge.net/projects/watermarkplugin/) - link in a post above.

Note that TheFluff said 'In general it seems like the effects of this filter could be duplicated fairly easily with existing filters, for example FluaG.'. This may be a better route as I am/was a novice at this type of coding in this type of environment, and C is not my strongpoint.

I eventually gave up on trying to do the video project using AviSynth and wrote my own tool in Java. Once I had achieved my goal with the java tool I forgot all about it. Where did the years go?

Good luck with your endeavours.

Phill

[Yanak]

Good to see you here :)
Like i said there is sometimes surprising things to discover digging this forum, the plugin does exactly what i needed with the few parameters it have, just perfect in terms of results.

There is indeed probably other ways to do this now, i'm not a avisynth knowledge guru like many around so i'll have to dig more into all this. I saw the FluaG plugin too but have no tried it yet, it's also not updated since like 6 years on his github page... :p

I just needed exactly what the watermark plugin does with the parameters it offers, it's perfect for me so i did not bothered much more once i saw the results obtained on my tests.

I saw there was the source code published but I don't know how to convert nor re-compile this into a x64 version sadly, maybe someone around will be kind enough and take a look at this.

This plugin had a nice potential, the option to make it move had been a blast if finished, at worst i will continue to use it with MP_Pipeline and the rgb32 conversion if i don't find any other way to obtain the same effect or if nobody tries to convert it into a x64 version + a way to byapss the converttorgb32, will have to dig into all this in the next days and see what i can do.

Thanks for the reply and for this plugin, still helpful years after ;)

[DrPhill]

Glad the plugin is of help - sorry I cannot be!

Making the code work on 64-bit might just be a case of choosing the right data types as indicated by an earlier post. (size_t instead of int)

Building the thing is a different matter, and part of the reason I went off the C/C++ languages quite early. For someone who does this regularly it probably raises no sweat, but to do it occasionally means a bit of set up.

If you do decide to jump into the development then take heart from the fact that I managed to do it and produce a pluggin.

Good luck.

[Yanak]

Yeah i will probably not put my hands into this , tried a few things in the past but it's a bit too much for me :/ Will cross fingers in hope a good soul will find it interesting as i did and find it worth a x64 version based on the source code (and why not add finish the options to animate it, you never know :p ).

Thanks again.

[DrPhill]

A pleasure - I had forgotten about that series of experiments.

[StainlessS]

A pleasure - I had forgotten about that series of experiments.

Well you aint gonna forget them again, for a while, doing conversion to CPP plugin (just the WaterMark thing), with Planar Watermark clip (Luma Only used) rather than RGB[blue channel], may also cater for RGB24 source. Might require assistance to check for legal arg limits, + maybe more. Finding a bit tricky but not producing exceptions any more (just nasty output).

Can take a look here to have some idea how the CPP API works, it makes it a lot easier than C API:- https://forum.doom9.org/showthread.php?t=163082

[StainlessS]

Yanak (and DrPhill), find mod of WaterMark given plug name WaterMark2, not exactly the same result as original, no idea why, could not find
difference (although I have changed from RGB32 [blue channel] mask to PLANAR luma channel, which is the 'right way up' compared to RGB32,
RGB32 is 'upside down']). Fixed a couple of bugs and convert to CPP plugin. Think maybe the slight difference is down to the change to 'right way up'
and rounding, but have not tried to compare code results as original would produce Divide by Zero exceptions where differences would have been
easiest to find (so I did not bother). [differences are not visible without eg subtract]

I have not used size_t all over the place as even RGB64 would have to be in excess of about 16K * 16K frame to cause problems in 64 bit and overflow 2GB array (signed).

anyway here tis:- http://www.mediafire.com/file/llippbe50biigys/WaterMark2_dll_x86_x64_20171205.zip

I'm washing my hands of it now, should be easy to compile, with project files included (VS 2008).
I have not done anything with any filter other than WaterMark2, eg not touched 'moveit' or whatever it was called.

Brief script

# EDIT: WaterMark2(clip c, clip WaterMark, Int "Displace"=10, Int "Light"=200, Int "Depth"=5, Bool "SoftEdge"=True, String "LightFrom"="NE")
LoadPlugin("Watermark2.dll")
#LoadPlugin("DGDecode.dll")
# Pixel type must be RGB32
# Watermark MUST be PLANAR same size as video (mask in Luma Channel).
# Watermark only needs one frame (but can be same len as clip # EDIT: so can be changing watermark)
# Watermark should be black (for mark) and white (for background)

myVideo = DirectShowSource("example.mpg", audio=false, pixel_type = "RGB32")
#myVideo = MPEG2Source("example.demuxed.d2v")
myVideo = Trim(myVideo, 100, 400)
myVideo = BilinearResize(myVideo, 640, 480)

myWatermark = ImageSource("ExampleText.jpg", end = 0, pixel_type = "RGB32")
myWatermark = BilinearResize(myWatermark, 640, 480)
myWatermark = myWatermark.ConvertToYV12 # EDIT: Oops, added in blue

return Watermark2(myVideo, watermark = myWatermark)

# EDIT: Script untested, modded it whilst on-line (should be about right though, except for below missing '2')
#return Watermark2(myVideo, watermark = myWatermark, displace = 20, light = 200, depth = 5,
# softEdge = true, lightFrom = "NE")
#displace = 10 - Default 10, maximum displacement of the image (range 0 -> 100)
#light = 200 - Default 200, maximum lightening/darkening of the image (range 0 -> 1000)
#depth = 5 - Default 5, amount of sloping border (range 0 -> 100)
#softEdge = true - Default True, 'round' the sloping border (false -> 'straight' or 'hard' border)
#lightFrom = NE - Default "NE", illumination direction N/S & E/W in logical combinations.
# Default or error = "NE", Strings case insensitive


Result:
https://s20.postimg.cc/bxzwbmo8t/Watermark.jpg (https://postimages.cc/)

EDIT: Actual parms used for above image were

LIGHT=200
SOFTEDGE=true
DEP=10
DISP=20


The "Text" Watermark is supplied in zip.
And looks like this
https://s20.postimg.cc/fud87w465/Example_Text.jpg (https://postimages.cc/)

EDIT: Defaults can be changed at bottom of cpp file in the Create function, and the min and max limits of args can be changed in the
class, implemented as enums, change and recompile if you dont like them (original had no limit checking).

EDIT: LightFrom, will also take "LTRB" instead of "WNES" characters, ie Left, Top, Right, Bottom, rather than West, North, East, South.

[Yanak]

Fantastic StainlessS,
Works nicely :
https://s14.postimg.org/ql342ax01/608899testcr.jpg

slower than original x86 dll but not a problem at all for me, it does the job and that's what is important.

Thank you very much for making this possible natively under x64, big thanks !

[StainlessS]

Forgot to mention, Watermark Luma Black is Y less than 32, white as greater or equal to 32 (can change in class).
(Was prev implemented at Black less than RGB 10, in blue channel).

EDIT: In Class

enum{WATER_SWITCH=32}; // Luma value boundary of Watermark (was 10 in RGB)


EDIT: Prototype

WaterMark2(clip c, clip WaterMark, Int "Displace"=10, Int "Light"=200, Int "Depth"=5, Bool "SoftEdge"=True, String "LightFrom"="NE")

[Yanak]

Thanks again, did not had much time last days to push testings a lot but the results are really nice for all type of "masks" i tested as watermarks. Really Happy about this :)

[StainlessS]

If you are not happy with defaults/limits, I could easily change for you, maybe WATER_SWITCH should have been set at 128.

EDIT: I did not play with it for long enough to best gauge if the limits were of sufficient scope.

[Yanak]

No worries, the outputs i had are more than satisfying, no need to change anything, at least for the few tests i done last days, did not had a lot of time to play with avisynth tools but the result is exactly what i needed and gives a nice effect, the only downside its the processing speed but i'll happily live with that, the end results are worth the wait :)

Thanks again for all.

[Yanak]

Had to start messing with Visual Studio 2017 Community to compile something from Github, then decided to look at avisynth plugins and this one in particular for the first attempt.

Based on StainlessS released source and solution i recompiled the x64 dll for testing and saw that the FPS gains were noticeable for the x64, so i pushed a bit more the testings with various options of VS2017 and here it is the final result.

With this script and this image (https://s10.postimg.cc/ulr8dgkdz/Water_Mark_Pic_000.png) for the watermark mask ( tested with bmp's, png's, jpg's, ebmp and there is no difference in fps results apparently, only the size of the "printed" text have an impact, the bigger the text/mask the less fps you get, here it's quite big ) :
https://s10.postimg.cc/apv8y1do9/2018-02-08_233924_cr.png
ColorBars(width = 1920, height = 1080, pixel_type = "RGB32", staticframes = false).killaudio().assumefps(60, 1).trim(0,7199)
Watermark2(watermark = ImageSource("H:\WaterMark_Pic_000.png", end = 0).converttoyv24, displace = 10, light = 100, depth = 3, softEdge = true, lightFrom = "NE")


This was for a "synthetic" test, on real footage the difference isn't that big but still nice :

https://s10.postimg.cc/u029hqul5/2018-02-09_005109.png

Here a list of scripts and video proprieties used for those last tests : https://pastebin.com/raw/V8JwA6v0
Same picture was used for the mask, only cropped on the top and bottom for the test on the 1920x800px video.


Compiled with Visual Studio 2017 using WIN10 SDK, avs+ r2580 header, runs nicely on my win7 x64 pro & 3770k CPU but cannot guarantee it works for all platforms, compiled with /MT parameter so it should not rely on some run-time library installed ( if i understood correctly ).

Made more tests enabling AVX ( i don't have avx2 or 512 CPU so could not test those ) and adding the Intel IPP libraries but the gains are really minimal, only +0.15 - +0.20 fps on the synthetic test so i didn't bother with those and left instructions non defined for better compatibility.


It's my first try at compiling something like this, for me the improvements are nice after dozen of tests done and i'm really happy, i can only hope it works for others too :)
After asking StainlessS i post it here as it may help somebody else on x64 plateform ( watermark2_x64.dll + VS2017 solution + source files included, beside avs+ header )

Thanks again to StainlessS for porting it and making this possible on x64 and thanks to DrPhill for this nice original plugin.

[Groucho2004]

@Yanak
Give this one (https://www.dropbox.com/s/b5qt5hldjnvw0sn/WaterMark2_x64_ICL.7z?dl=1) a try. It's built with ICL13 and PGO. In my tests it's quite a bit faster than the one you built with VC2017.

[Yanak]

Hello,

ran my tests again with this one and yes indeed it is faster :
https://s13.postimg.org/ggm8878h3/2018-02-09_212710.png

Now Master tell me your secrets please :p

Looked a bit and ICL13 seems to be a ( not much recent apparently ) version of the Intel c++ compiler, and PGO an optimization setting possible, seems also like there is something more or less similar in VS2017 so I'll have to document myself on this and try in vs2017, might serve for the future, like i said I'm very new to this and despites reading a lot last weeks i still am a complete noob and it probably will stay like this for a long long time...

I bet it is possible for the Intel compiler to be integrated into VS2017, a bit like it is possible with LLMV/clang ? and most probably the Intel compiler is not free too so probably useless for the little needs i plan to have.

Sorry for hijacking a bit the thread but now you got me really curious, if it's possible to get better performances i'd rather start with this before going on further experiments in this domain.

Thanks a lot,
and thanks for the faster dll ;)

[Groucho2004]

Looked a bit and ICL13 seems to be a ( not much recent apparently ) version of the Intel c++ compiler, and PGO an optimization setting possibleNot the latest version but that's what I have (and an even older ICL10).
PGO - Profile Guided Optimization, look it up.

I bet it is possible for the Intel compiler to be integrated into VS2017The Intel C compiler is not stand-alone, it has to be used in conjunction with Visual Studio (or at least its libraries and command line tools). It also integrates with VS.

most probably the Intel compiler is not free too so probably useless for the little needs i plan to have.Definitely not free.

[Yanak]

Was looking quickly around for PGO in VS2017, will have to figure out this in the next days as it seems to improve things nicely in some cases, will dig into this and do some testings.

For intel compiler i saw the prices for the basic version.. I'd rather renew a good part of my PC hardware if i had such sum to spend :/
There is ways to get it for free, but many years have passed since i was a student, and i'm not entering in other categories like Open Source contributor or an educator either, so nope, just need to forget about this option :p

PGO is something i will study as it can serve for many other things, something i had not seen before during all my readings and searches about optimizations for VS2017 in during the last couple of weeks, thanks for making me discover something new, it will keep me busy for the next few days until i figure it out.

Thanks again for all.

[StainlessS]

Not sure, think Intel compiler may be free on Linux, (not that it helps here).

I've finally downloaded XP64 bit updates (WususOfflineUpdate), and may at some point get a 64 bit sys up and running, and see if I can
improve on my 64 bit compile using VS 2008. I used 32 bit offsets to arrays (64 bit simply not necessary), but vs2008 may sign extend everything
and make compile slower, whereas the later compilers may do as they were told,(or convert ints to prtdif, or whatever that horrible replacement for int is)
dont know. I'll probably have to aquaint myself at least a little
with assembler so that I can see what code compiler issues, and so better judge what may be of benefit to speed.

Nice job guys, every little bit helps :)

[Groucho2004]

@Stainless
The reason for the slow speed of your build are the compiler settings. You neither specified "O2" nor "Ob2". I just did a test with VC10 and your settings and it is also very slow.
Here is my makefile with the VC10 settings I use for best performance:
CXX=@cl.exe
CXXFLAGS=/MT /EHsc /O2 /Ob2 /D "NDEBUG" /D "WIN32" /D "_WINDOWS"

LINK32=@link.exe
LINK32FLAGS=/dll /machine:x64 /nologo

WaterMark2_x64.dll: WaterMark2.obj
$(LINK32) $(LINK32FLAGS) WaterMark2.obj /out:WaterMark2_x64.dll

WaterMark2.obj: WaterMark2.cpp
$(CXX) $(CXXFLAGS) WaterMark2.cpp -c

[Yanak]

After struggling to find a decent "How to" for PGO under VS2017 i found this : https://docs.microsoft.com/en-us/windows/uwp/debug-test-perf/pgo-for-uwp
All the rest i found reference things i don't seems to have installed or available on my version...

- Step 1 used my existing solution directly, step 2 was already set, followed step3, added also the same thing in "General > Whole Program Optimization > Profile guided optimization - Instrument" , this was not indicated.

- At step 4: i only built the .dll, it seems i can't activate the deploy option, for some reasons it stays grayed out...

- At Step 5 the pgort140.dll path is not correct, found it at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\bin\Hostx64\x64\pgort140.dll"

- Step 6 i done this :
I left the instrumented WaterMark2_x64.dll in the Solution folder ( AVSMeter seems to create 4 metric files on each run if the dll's are put inside avisynth+ auto load plugin folder, probably the auto load ).
Copied the pgort140.dll there, next to the .pgd file , then run all my above tests once using AVSmeter, ( it is very slow of course, around 6fps for all the tests and 8 fps for the 1920x800px file ...)
Only change was just indicating loadplugin() path for the watermark2x64.dll with the path to my solution release folder ( and removed also the already existing watermark2_x64.dll i had in avisynth plugins folder so it won't auto-load and mess everything)

- Skipped steps 7 & 8, not needed.

- AVSMeter created two .pgc file on each script i ran, WaterMark2_x64!1.pgc + WaterMark2_x64!2.pgc, one at the start of the script run and another once the script was processed, i guess the 2nd one is probably when it unloads the script/dll's so i deleted each 2nd metric .pgc files to keep only the ones created during the script running, *!1.pgc , *!3.pgc , *!5.pgc etc etc..

- Followed step 9 and 10 ( + went again to : General > Whole Program Optimization > Profile guided optimization - Optimize ), this was not indicated.


Then run my tests with the new created and "trained" .dll made using PGO, and this is the results :

https://s13.postimg.cc/aft4ofg93/2018-02-10_174906.png

Very very happy with this, wasn't expecting such boost of performances :)

Thanks a lot Groucho2004 for making me discover this, took me a bit to figure it out but it's something i will use again for sure. ( left me wondering what it could have been with the Intel compiler tho :p )


I'll have a last question about the compiler.h file and how to add more recent definitions coming from the sdk there but i won't pollute this thread more, i'll revive StainlessS's " Avisynth CPP Interface for C Programmers. - 31 Mar 2015" thread and ask there after trying first by myself tonight or tomorrow :p


I leave the boosted WaterMark2_64.dll + sources + solution + the .pgd & .pgc "training" files inside the "Source > x64>Release" folder
( initial pgd, not having the training metrics .pgc files merged, this will be done automatically when importing the solution and building the project for the first time and then not needed anymore, on the next builds only the .pgd file having metrics already merged will be used if i make no errors )

Thanks again to all, learned a lot doing this and I'm quite happy with the results, game changer for me to have been able to do this, couple of weeks ago i was staying far away from the compiling stuff after failing at it a few times in the past ;)


Mirror for file download : http://www75.zippyshare.com/v/o3gy0rpL/file.html

[StainlessS]

You neither specified "O2" nor "Ob2"
Then I need a good slap.

Yanak,
Nice job, did the "Learn X in Y minutes" thing come in handy ? [EDIT: Originally linked via VapourSynth thread]
https://learnxinyminutes.com/
Many Programming languages covered, and in multiple spoken language.

[Yanak]

Hi and thanks,

I started to dig and read into this, thanks again for the links provided earlier, but i'll need more time on this to read and assimilate some of this stuff, but it is really handy and well explained, hopefully i will finish this in a few days and maybe start to experiment a bit more.

PS: i don't set /Ob2, if i understood correctly it is automatically triggered when /O1, /O2 or /Ox are enabled, in vs2017 at least, so i just leave it by default but have/O2 set, might try to enable it too...

Thanks.

[StainlessS]

@Stainless
The reason for the slow speed of your build are the compiler settings. You neither specified "O2" nor "Ob2". I just did a test with VC10 and your settings and it is also very slow.


Actually, I think I've found a bit of a disturbing bug in VS2008 Express x64 [EDIT: and x86].

By default, in IDE project configuration, it looks like

Configuration Properties/C/C++/Optimization/Optimization=Maximize Speed(\O2)

With the Maximize Speed(\O2) not in bold, ie default setting.
However, seems that Maximize Speed is NOT the used default, and only properley set when switched to something else, and then back to Maximize Speed again(where it is now bolded).

If compiled with default (not bolded) I'm getting about 16.75 FPS on my quad core 2.4Ghz Core Duo (1 core used).

If switched to Full Optimization(\Ox), I'm getting about 36FPS.
If switch back to Maximize Speed(\O2), I'm still getting about 36FPS (where it originally gave 16.75 FPS).

Also NOTE, should have preprocessor definitions also set, "Configuration Properties/C/C++/PreProcessor/PreProcessor Definitions=_WIN64;_AMD64

_WIN64 is said by M$ to be a 'standard' definition, but also says that it is not set defaulted by IDE (when compiling x64), and must be specified in preprocessor definition.
https://social.msdn.microsoft.com/Forums/vstudio/en-US/b1efc987-490f-4690-a964-f9bcce1ae625/win64-is-not-defined-for-my-64-bit-appications?forum=vclanguage

EDIT: By MSDN moderator:-
The IDE doesn't know beans about x64. Maybe next version.

EDIT: This is used in Compiler.h"

// Compile for minimum supported system. MUST be defined before includes.
// NEED to use SDK for updated headers, TK3 will give error messages/Warnings about Beta versions.
#ifdef _WIN64
#define WINVER 0x0502 // XP 64 Bit or Server 2003
#define _WIN32_WINNT 0x0502 // XP 64 Bit or Server 2003
#define NTDDI_VERSION 0x05020000 // Server 2003 SP0
#define _WIN32_IE 0x0700 // 0x0700=IE 7 SP0
#else
#define WINVER 0x0501 // XP 32 bit
#define _WIN32_WINNT 0x0501 // XP 32 bit
#define NTDDI_VERSION 0x05010300 // XP SP3
#define _WIN32_IE 0x0603 // 0x0603=IE 6 SP2
#endif


EDIT: Maybe above _WIN64 is only a prob in IDE, and compiles ok, but IDE shows wrong code in Compiler.h greyed out when _WIN64 not defined.

[raffriff42]

36FPS? On an effect that doesn't change from frame to frame? You might not be caching properly. I can do 130FPS in script. FFMS2("Sintel.mp4")

## the watermark: any white on black mask
M=BlankClip(Last)
\ .Subtitle("© copyright Blender Foundation", size=42,
\ align=3, text_color=$ffffff)
\ .ColorYUV(levels="TV->PC")

watermark42(M, 0.2, nofill=true)
return Last

https://www.dropbox.com/s/tvzcpri8qbc2ykw/watermark22-demo1.jpg?raw=1

##################################################
function watermark42(clip C, clip M, float opacity, bool "nofill")
{
nofill = Default(nofill, false)
C

## 'CF' = 'fill' (white part of mask)
## this is one possible treatment: shift + low contrast
CF=BilinearResize(Width, Height, -(-3), -(-3), Width, Height) [* shift left, up 3px *]
\ .ColorYUV(cont_y=f2c(0.7)) [* lower contrast *]
\ .Trim(0, length=1).Loop
#return CF
(nofill) ? Last : Overlay(CF, mask=M, opacity=opacity)

## 'MC' = mask + convolution (embossed effect)
MC=M.ConvertToRGB32(matrix="PC.709")
\ .GeneralConvolution(128, "
-1 0 0
0 0 0
0 0 1")
\ .Trim(0, length=1).Loop

## 'MH' = highlight part of emboss
MH=MC.Levels(128, 1, 255, 0, 255, coring=false)
\ .Trim(0, length=1).Loop
Overlay(ColorYUV(off_y=(60)), mask=MH, opacity=0.5*opacity)

## 'MS' = shadow part of emboss
MS=MC.Levels(128, 1, 0, 0, 255, coring=false)
\ .Trim(0, length=1).Loop
#return MS
Overlay(ColorYUV(off_y=(-60)), mask=MS, opacity=0.5*opacity)

return Last

## scale ColorYUV args to a "normal" scale
function f2c(float f) {
return Round((f - 1.0) * 256.0)
}
}


as shown: 130FPS
w/o code in blue: 45FPS

[StainlessS]

I can do 130FPS in script.

I'm not too worried about my speed, was on original 'Text' logo over Colorbars [EDIT: As in post #43, much bigger than your little logo, little clip and simpler args]. My machine is Quad core Core Duo, Q6600 (Lithography 65 nano meter,
not the later 45nm), and DDR2, so is quite crappy (also switched off other optimize functionality for that bug test).
EDIT: Arh, your WaterMark42() does not even use WaterMark2() and so cannot produce same effect as in post #43.

I tested with VS2008 Express 32 bit, compiling to x64, and same bug as posted in my prev post (not tested with compile to 32 bit as yet, I imagine it will be same bug).

Tested the _WIN64 thing, and does indeed get defined and correct code produced, problem only for IDE.

You can set optimization to defaults by hand editing WaterMark2_x64.vcproj, this part (delete lines marked in BLUE,
[EDIT: Well actually delete them all except the Name="VCCLCompilerTool" line and preprocessor defines])


<Configuration
Name="Release|x64"
OutputDirectory="$(SolutionDir)$(PlatformName)\$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)\$(ConfigurationName)"
ConfigurationType="2"
EnableManagedIncrementalBuild="0"
>
<Tool
Name="VCPreBuildEventTool"
/>
<Tool
Name="VCCustomBuildTool"
/>
<Tool
Name="VCXMLDataGeneratorTool"
/>
<Tool
Name="VCWebServiceProxyGeneratorTool"
/>
<Tool
Name="VCMIDLTool"
/>
<Tool
Name="VCCLCompilerTool"
EnableIntrinsicFunctions="true"
FavorSizeOrSpeed="1"
WholeProgramOptimization="true"
PreprocessorDefinitions="_WIN64;_AMD64"
EnableEnhancedInstructionSet="2" # EDIT: SSE2, Will be ignored when compiled to x64, so remove anyway
AssemblerOutput="4"
Detect64BitPortabilityProblems="true" # EDIT: Deprecated
/>

Note, the Release|x64 section.

EDIT: Optimization="2" is set in the BLUE segment when non default Optimization=Maximize Speed(\O2) is bolded.

[StainlessS]

WaterMark2, v2.10 x86 and x64, new version (~61KB, EDIT: Actually correct zip is 137KB).
http://www.mediafire.com/file/61ugwwvvc7rx111/WaterMark2_dll_v2.10_x86_x64_20180218.zip
EDIT: Above link updated.

Considerably faster where single frame watermark.
For post#43 style Colorbars and "Text" logo [with loop() removed for single frame watermark], x86 about 194 FPS, and x64 about 209FPS, on my crappy machine.

Give it a whirl Yanak :)

EDIT: I took the opportunity to mod the WATER_SWITCH from 32 to 128,
Watermark Luma Black is Y less than 128, white as greater or equal to 128.

[StainlessS]

Oops, sorry guys, I linked older WaterMark.zip in above post, updated. :(

EDIT: Also available via SendSpace link below this post.

[Yanak]

Hello,

I won't be able to test it before a few days sadly, but be sure that I will do as soon as possible and report back, the improvements seems to be really nice, i have to deal with a few things and hopefully in 4-5 days i will have time to test this properly.

Thanks a lot.

PS :
Just noticed that my last attachment on previous post is still not approved :/ Added a mirror link for the download.

Edit :

Still didn't had time to dig into this compiler.h file and see what it does exactly, i noticed the reference to the SDK in it, this is the content of sdkddkver.h using win10 sdk in VS2017 :
https://pastebin.com/raw/wNggMEh8

Not sure if it can help to update the compiler.h file or not.

[StainlessS]

Compiler.h is just a 'standard' (ie my standard) header to switch off some things, switch on some things, and also set required
windows version and IE version for some of the plugs I compile, maybe not necessary for most plugs but just to save me time.
Also, provides for enable/disable my debug messages via DPRINTF(), for VS2008 and above, or alternatively below VS2008.
You dont really need worry about it at all (but to correctly set minimum OS, then should set _WIN64 on 64 bit where min req OS would be XP64 bit).
Not sure what the IE min was for, probably something in RT_Stats (open file selector or something like that).

EDIT: Yeh, not many attachments are approved of late, perhaps the mods are on sabbatical :)

I downed your mirror link and tried with same script where I got 209FPS in new x64 version, with yours I am getting 51FPS,
so new one about 4x faster for single frame watermark (BuildMask is only called once on a persistent buffer, rather than at every frame).

EDIT: Script used.

#LoadPlugin("D:\WaterMark\WaterMark2_x86.dll")
LoadPlugin("D:\WaterMark\WaterMark2_x64.dll")
Colorbars.killaudio.Trim(0,-1).Loop(20000)
L="TR"
#L="BR"
#L="BL"
#L="TL"

C =Last

WM = ImageSource(".\ExampleText.jpg", end = 0, pixel_type = "RGB32").BicubicResize(Width,Height)

WM2 = WM.ConvertToYV12 #.Loop(Framecount) # Single frame watermark ONLY

LIGHT=200
SOFTEDGE=true
DEP=10
DISP=20

return Watermark2(watermark = WM2,lightFrom=L,light=LIGHT,softEdge=SOFTEDGE,depth=DEP,displace=DISP)


And result:-
https://s20.postimg.cc/bxzwbmo8t/Watermark.jpg (https://postimages.cc/)

[Yanak]

Sorry for the delay in replying to this but was really too busy those last days.

Thanks for the infos StainlessS, i will not worry about compiler.h file then, was not sure what it was doing exactly, now i have the answer.

Took a couple of hours to try your new compiled dll, using the same scripts as before, the new code is more efficient compared to previous one.

Your x64 dll, then compiled in vs2017, then vs2017 and also PGO trained :
https://s14.postimg.cc/g61axmlxd/2018-02-21_003936.png

Very nice results and improvements.

Did not had much time to test the scripts above, but the default colorbars size is only 640x480, the smaller the size and also the smaller the mask size to "print" on the video and the faster it goes.

On 1080p footage and with a text or logo to print taking quite some space like in my tests the speed takes a hit.

Anyways resized my mask picture to 640x480 and run your script above ( only once, missing time to push this more ) :

- your compiled x64 dll gives me 475.2 FPS
- Mine with PGO training goes up to 584.7 FPS o_O

now if i use this script with 1080p size :


ColorBars(width = 1920, height = 1080).killaudio.Trim(0,-1).Loop(20000)
L="NE"
#L="BR"
#L="BL"
#L="TL"

C =Last

WM = ImageSource("H:\WaterMark_Pic_000.bmp", end = 0, pixel_type = "RGB24").BicubicResize(Width,Height)

WM2 = WM.ConvertToYV12 #.Loop(Framecount) # Single frame watermark ONLY

LIGHT=100
SOFTEDGE=true
DEP=3
DISP=10

return Watermark2(watermark = WM2,lightFrom=L,light=LIGHT,softEdge=SOFTEDGE,depth=DEP,displace=DISP)


- Your x64 dll : 74.07 fps
- PGO one : 91.25 fps

I leave the last dll i compiled with PGO training and your last code here : http://www56.zippyshare.com/v/91J6OXZq/file.html

The results are quite impressive if you look at where this .dll started for speed, really happy about this, and a big thank you for making all this possible guys.


PS :
@raffriff42 :

Thank you.

I'll try your script when i'll have a bit of time too, but i'm afraid the result is not the same, the dll give a kind of glossy effect that is really nice, can be used with text or a logo picture or even use a white and black rendered full frame and you can simply make a kind of glossy emboss effect on your video with it, the results you can get with this dll goes far behind a watermarking effect.

[Yanak]

Intel System Studio is now free (https://www.pcper.com/news/General-Tech/Intel-System-Studio-2018-Commercial-License-Now-Free), need to register to get a 90 day license that can be renewed after the 3 months for free still :
https://software.intel.com/en-us/system-studio/choose-download

Integrated the Intel C++ Compiler 18.0 into Visual Studio 2017 , made a Dll with PGO to compare with the one i had before and it gains a bit in some tests :

https://i.imgur.com/TcAgoRn.png

Well the previous one gains a bit too, it' a different version of AvsMeter and a different version of AviSynth+ too ( r2664), not sure what made the previous dll i posted gain a few fps compared to my last tests... anyways the Intel compiler squeeze it a bit more so all good for me.

Script i posted in previous post now bypasses 100 FPS by a tiny bit with this new dll.

For what it's worth this is it : http://www38.zippyshare.com/v/HOAQ2sJA/file.html
For Intel CPU's only i guess since it uses some Intel tricks for the optimizations.

:)