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.