PDA

View Full Version : New Logo Removal Plugin


AMSS0815
12th January 2008, 13:25
Hi everybody,

finally I completed my logo removal plugin. This is the abstract from the help file:
Image Inpainting is the art of restoring destroied parts of an image by using information of valid parts of the image in a way, so that the human eye does not recognize the damaged areas (at least not at a first sight). In video processing image inpainting is often applied to videos in order to remove TV station logos. This plugin comes with the intention to provide a suit for the removal of logos, whether opaque or transparent. It provides algorithms for these tasks:

Logo detection: An obstacle is analyzed closely after being masked roughly by the user. The exact color map of the logo is determined as well as its alpha mask.
Deblending: Given the color image and alpha mask of an overlayed logo, the logo is removed where it is not opaque.
Logo inpainting: Opaque parts of the logo are interpolated. A fast method is used which has been published recently by Folkmar Bornemann and Tom März (see here (http://www-m3.ma.tum.de/twiki/bin/view/Allgemeines/Projekte#Fast_Image_Inpainting_Based_on_C)).

Finally, a function for calculating the distance function of a mask is provided, which can be used to expand or inflate masks as well as to provide smooth blending masks.


The logo detection and deblending are (more or less) what you (might) know from Karel Suhajda's DeLogo (http://neuron2.net/delogo132/delogo.html) filter for VirtualDub (but extended to YUV color spaces). The inpainting method is the implementation of a pretty new algorithm which produces much less blurring than the DeLogo filter. As I coded everything in pure C (without CPU optimizations) you shouldn't expect real-time performance:).

This mathematics and algorithms (concerning inpainting) behind this plugin are still under heavy development and the effects of the various parameters are not fully understood yet. If you have some experiences with this plugin and some ideas which settings produce good results in which situations, please post them here so the authors can learn from it. Please do not contact any of the authors (WB, FB, TM) directly. Also I should note that this algorithm has originally been developed for inpainting pictures, not movies, so you might observe strong discontinuities in time.

The plugin is attached to this thread as zip-file, including source code, a help file, and a demo script. Everything is licensed under the GNU GPL 2. See files AVSInpaint.htm and GNUGPLv2.txt for details. Have fun!

Regards,
AMSS

Edit: Added version 2008.02.23 as announced here. AMSS

mitsubishi
12th January 2008, 15:46
(but extended to YUV color spaces)

Sweet. I use the Delogo filter alot, but I only use the alpha deblending. There's maybe a better way of just applying an alpha mask, but that's how I do it.

With Delogo, I just find a blackest possible background the logo and the make my own masks in photoshop.

So I will test this out later.

CruNcher
12th January 2008, 17:09
Inpainting goes Avisynth nice work AMSS0815 :)
i think this here is interesting in those regards http://portal.acm.org/citation.cfm?id=1291237

it also seems a nice way for denoise/graining see http://www.mine.tku.edu.tw/advisors/tshih/tshih_projects/default.aspx Super-Resolution Inpainting
http://www.mine.tku.edu.tw/demo/inpainting/default.aspx

Fizick
13th January 2008, 00:53
will look to AVSInPaint!

Surpisingly, I prepare (almost finished, some doc need) two more avisynth impainting plugins :)
(different algos)
I partially interested in hole filling in motion stabilization and compensation, may be interpolation.

Malcolm
13th January 2008, 03:35
Hey, this is great!
I was just looking for an inpainting solution for avisynth and bang - the same day you release your plugin! :thanks:
Just your demo.avs - it's too much for me (it's really late now where i live) Could you just please provide a simple(!) realworld example. maybe a small clip; a logo file and a small avs?
I guess this would really help people to really understand what's needed to use your plugins!

Thanky a lot,
greetings,
Malcolm

Fizick
13th January 2008, 23:54
AMSS0815, why you do not use stdcall calling convention instead C? It is now default in avisynth, and extra avisynth_c.dll is not needed

Your plugin is not very slow! :)

GreyCstoration method in new GreyC plugin is probably slower:
http://forum.doom9.org/showthread.php?t=123081

AMSS0815
19th January 2008, 14:54
Hi there,
i think this here is interesting in those regards http://portal.acm.org/citation.cfm?id=1291237When I try to download the pdf-file, I'm forwarded to their homepage (http://portal.acm.org/portal.cfm). I think last summer I read some things about the stuff your other url points to: Seems they're both pretty good and pretty slow. However, I created AVSInpaint because I heard some talks about that algorithm. So I probably won't create more plugins. (Unfortunatelly I'm not in the image processing business anymore.)

Surpisingly, I prepare (almost finished, some doc need) two more avisynth impainting pluginsThe examples presented in the Microsoft-Paper (for ExInpaint) do look great! I have no opportunity to test it right now. The GREYCstoration seems to apply similar techniques as AVSInpaint (After skim reading their docs, I think they also compute something like Weickert's structuring tensor), but it seems their using an iterative scheme (which might reduce speed significantly)..?

I was just looking for an inpainting solution for avisynth and bang - the same day you release your plugin! ... Could you just please provide a simple(!) realworld example.Glad to help you. No - I avoid posting image or avi files. But Demo.avs really is a small example, only blown up with stuff that is not inpaint-related:Please ignore lines 1-130: They only provide the test clip with the logo and a framework to arrange the nice output clip.
Lines 133-139 actually create the test clip, so these lines would be replaced byMask4Analyze = ImageSource("LogoMask.png").ConvertToYV12
AVISource("Movie.avi").ConvertToRGB24
BigMovie=last
Clip=Crop(64,64,64,64) # Where the logo is and a lot space aroundLogoMask.png should be painted by hand, so it is white where the logo is (and some space around) and black elsewhere.
Lines 154-197 will find and remove the logo from Clip and put the result in RepairedClip.
Line 201 layeres the repaired (small) clip on top of the original clip (you will have to change the line by adding x=64 and y=64 or something else, and using BigMovie as base clip). Done.
There is also a small example in the help file (just put in your movie and try)...

why you do not use stdcall calling convention instead C
That's something I tried a lot about a year ago, but I failed. At the moment I'm using AviSynth_C.{dll|lib|h} in AviSynth_C-0.15.zip (http://kevin.atkinson.dhs.org/avisynth_c/avisynth_c-0.15.zip). When replacing AviSynth_C.{lib|h} by those in AviSynth_C-StdCall.zip (http://kevin.atkinson.dhs.org/avisynth_c/avisynth_c-stdcall.zip) (and recompiling and removing AviSynth_C.dll and the corresponding line in the avs-file), AviSynth 2.57 (build: Dec 31 2006) replies Unableto load C Plugin: AVSInpaint.dll. When replacing LoadCPlugin with LoadPlugin in the avs-file, I get LoadPlugin: unable to load "AVSInpaint.dll".:confused:
I'd appreciate any help in getting rid of this dll-file.

Your plugin is not very slow!:thanks: very much! Good to hear this.


And:thanks::thanks:for all the comments so far!!

Regards,
AMSS

Fizick
19th January 2008, 19:21
AMSS0815,
avisynth_c from Kevin has known typo bug with ACSC_USE_STDCALL instead of AVSC_USE_STDCALL.
Fixed version is distributed with Avisynth 2.5.7 setup:
avisynth_c.h is with FilterSDK option (and folder)
and avisynth.lib is with Extras option (and folder).
See also Yadif plugin package.

AMSS0815
26th January 2008, 16:54
Hi Fizick,Fixed version is distributed with Avisynth 2.5.7 setup:
avisynth_c.h is with FilterSDK option (and folder)
and avisynth.lib is with Extras option (and folder).I tried and failed. To be precise, I (re)placed AviSynth_C.h and AviSynth.lib with the ones comming with AviS 2.5.7, and changed the makefile (so it uses AviSynth.lib). It compiles fine, but linking with the lib-file results in a lot of errors like:AVSInpaint.obj(.text+0x6e1):AVSInpaint.c: undefined reference to `_imp__avs_release_video_frame@4'
AVSInpaint.obj(.text+0x1ec7):AVSInpaint.c: undefined reference to `_imp__avs_release_clip@4'
.....The line #define AVSC_USE_STDCALL 1 suggests that it uses standard calling convention (as far as I looked into the header file, this holds for the imported functions, too).

See also Yadif plugin package. I uncompressed it, and running make resulted in similar error messages (but not so much).
I wonder if my compiler is improperly configured :confused:.
By the way: It's gcc 4.2.1 (compiled with some older gcc), and linker is GNU ld 2.15.91 (delivered with MinGW).

AMSS

Fizick
26th January 2008, 22:31
my first attempt to build avsinpaint failled. - i replace only one avisynth_c.lib to avisynth.lib in make file and missed second entry :)

Error was similar to reported

But now avsinpaint (and yadif) build fine.

My config:
gcc version 4.0.4
from http://forum.doom9.org/showthread.php?t=108215

GNU ld version 2.17.50 20070129
Seems, it is important! get new binutils 2.17.50

I do not use mingw directly, but with minsys or with Codeblock.

Reuf Toc
30th January 2008, 07:33
I've wrote a function for AVSInpaint. I hope it will help peoples who have difficulties to use this sympathic plugin. Since it's my first function I ask for leniency. :p

#____________________________________________________________________________________
# _____ _ _ ______
# |_ _| (_) | | | ____|
# | | _ __ _ __ __ _ _ _ __ | |_| |__ _ _ _ __ ___
# | | | '_ \| '_ \ / _` | | '_ \| __| __| | | | '_ \ / __|
# _| |_| | | | |_) | (_| | | | | | |_| | | |_| | | | | (__
# |_____|_| |_| .__/ \__,_|_|_| |_|\__|_| \__,_|_| |_|\___|
# | |
# |_|
#_____________________________________________________________________________________



# InpaintFunc is a new delogo function using AVSInpaint.dll an AviSynth C plugin developed by AMSS.
#See thread : http://forum.doom9.org/showthread.php?t=133682 to download this plugin and get
#more information about it. Just an advertise : AVSInpaint plugin is rather slow so be patient ;-)


#_______________________________________________________________________________________
#
# History :
#_______________________________________________________________________________________


# Actual revision : InpaintFunc v1.13

# Author : Reuf Toc

# Requirement : AVSInpaint.dll


# Changes :

#Rev 1.00 : First release 2008/01/30
#Rev 1.01 : Add debug for "mode". Removed two useless operations.
#Rev 1.02 : Added "Speed" parameter.
#Rev 1.03 : Fixed bug in PAR calculation. Fixed bug with non-RGB32 mask.
#Rev 1.10 : Fixed bug due to overlay. Added post-processing + a lot of things.
#Rev 1.11 : Added Show parameter and InpaintAssist function. Process in RGB24 instead of RGB32.
#Rev 1.12 : Fixed bug in "loc" calculation
#Rev 1.13 : Fixed bug for .ebmp creation (did not happen in several cases)




Find last version of InpaintFunc on the wiki : InpaintFunc (http://avisynth.org/mediawiki/InpaintFunc)

geminihc
16th February 2008, 19:59
sorry if this questions very stupid, but i'm using FFDshow with avisynth. what exactly do i type in avisynth section in ffdshow to use this..?

foxyshadis
16th February 2008, 23:39
It'd doubtful that you could do this in realtime even if you put it in ffdshow. You'd also have to change the parameters for every movie's logos.

Adub
17th February 2008, 06:21
@ Reuf Toc

I have added your function to the Avisynth wiki.
Here:
http://avisynth.org/mediawiki/InpaintFunc

Feel free to edit and update your function on there when ever you feel like it. (Plus, it makes the function easier to find and maintain.)

Reuf Toc
21st February 2008, 08:09
Function updated (here and on the Wiki)

The two majors changes are a correction of a bug caused by overlay and the addition of a basic post-processing feature.

Changelog :

Fixed bug due to overlay()
Added basic post-processing.
Suppression of Cropval parameter.
Check if the logo analysis has already been computed.
Default value are differents.
Added parameters to tweak InpaintLogo.
Changed debug variables from int to bool.
Changed mask creation method.

AMSS0815
23rd February 2008, 15:40
Hi everybody,

I updated AVSInpaint to version 2008.02.23. Main change is the removal of AviSynth_C.dll. Thanks to Fizick, this file isn't necessary anymore (Plugin is still loaded with LoadCPlugin). Further (minor) changes are listed in the help file. The file is attached to the original post of this thread.

Nice work, Reuf Toc. I really have to admitt, I didn't spend to much time on making this thing user friendly.

Have fun,
AMSS

Poutnik
3rd February 2010, 11:37
I have a question to InPaincFunc about manual setting of crop area to localize logo ( loc "x1,y1,-x2,-y2" ).

Should I set it to logo quite tightly (with some border) to speed up the things ?
Or, is it a trade off between speed if tight and quality if large enough to have more out-of-logo info ?r
Or it does not matter and "TL" is enough ?

Reuf Toc
5th February 2010, 13:39
I don't know exactly how AVSInpaint works internally but from what I understood, the number of pixels computed to restore the damaged area is defined by "radius" parameter.

So the minimum border around the logo should be at least equal to the radius. If this condition is fulfilled, setting an larger area does not increase quality but only time computation.

So I recommend to use your own loc parameter, especially if your source is HD

pbristow
1st July 2010, 18:23
Hi! I'm trying to use AVSinpaint via the InPaintFunc script, as follows:

<code>
LoadCPlugin ("C:\Program Files\AviSynth 2.5\C_plugins\AVSInPaint.dll")

AVISource("GP1.TESTCLIP.avi")
Trim(0,10)

InpaintFunc(mask="G:\GP\Logo_1280x720.bmp", loc="48,48,152,52", speed=20, mode="both", show=false)
</code>


AVSInPaint keeps failing with the error "mask is full". Can anyone explain what that message means? I've searched the docs provided, and the forums, and tried Googling for ' AVSInPaint "mask is full" ' - No luck. (Except for a thread on a Chinese forum, where, if I'm correctly interpreting the machine translation, they don't know what it means either!)

N.B. I'm using the older version of AVSInPaint because I couldn't persuade the newer one to load. (Tried every combination I could think of, using loadplugin/loadCplugin, putting the .dll file in plugins/c_plugins folder, etc. - again, no joy.) If this is a known prob that's fixed in a newer version, could someone point me to it and clarify how it has to be loaded?

Thanks.

Reuf Toc
1st July 2010, 19:20
Hi! I'm trying to use AVSinpaint via the InPaintFunc script, as follows:

<code>
LoadCPlugin ("C:\Program Files\AviSynth 2.5\C_plugins\AVSInPaint.dll")

AVISource("GP1.TESTCLIP.avi")
Trim(0,10)

InpaintFunc(mask="G:\GP\Logo_1280x720.bmp", loc="48,48,152,52", speed=20, mode="both", show=false)
</code>


AVSInPaint keeps failing with the error "mask is full". Can anyone explain what that message means? I've searched the docs provided, and the forums, and tried Googling for ' AVSInPaint "mask is full" ' - No luck. (Except for a thread on a Chinese forum, where, if I'm correctly interpreting the machine translation, they don't know what it means either!)


"mask is full" means that your mask is "full white" after cropping. Either you cropped too much the clip with the "loc" values you used or there is a problem with your mask (make sure that black parts of your mask are really black).
If you post a screenshot of your source and your mask, I can take a look.


N.B. I'm using the older version of AVSInPaint because I couldn't persuade the newer one to load. (Tried every combination I could think of, using loadplugin/loadCplugin, putting the .dll file in plugins/c_plugins folder, etc. - again, no joy.) If this is a known prob that's fixed in a newer version, could someone point me to it and clarify how it has to be loaded?

Thanks.
Have you tried Load_Stdcall_Plugin, the alias for LoadCPlugin ? AVSInpaint is still a C plugin so loadplugin can't work.

pbristow
1st July 2010, 21:51
<quote>"mask is full" means that your mask is "full white" after cropping. </quote>

Ah! I understand now. :)

From looking at the source, I could see that it should only say "Mask full" if the mask was 100% white, but my mask isn't (I thought)... but I was overlooking the "after cropping" detail. :) For my first experiments, I'm using a simple white rectangle against full black as my mask, and in my keenness for speed, I see that with my loc="" string I've cropped well inside the white rectangle.

<quote>Have you tried Load_Stdcall_PluginM</quote>
Not yet. I'll try the newer version with that later.

Thanks for your help. :)

StainlessS
16th September 2010, 01:20
@Reuf Toc

Love your script, tried the newer alternative (dont off hand remember name)
but prefer yours. Can I though suggest that with your next script update, you include
the below mod:

catch (dummy)
{
show=true
in2.analyzelogo(Masque).trim(0,-1).converttoRGB32
imagewriter(ID,0,1,"ebmp")
}""")

Namely the "Show=true" line.

makes it much more usable and would obviate the need for me
to replace it when you do make an update.

Forces the script to actually save the bitmaps, dont really
know how it's supposed to work without it.

Also, can I suggest that you and others viewing this thread
see update just posted minutes ago here:

http://forum.doom9.org/showthread.php?t=154559

Have had great success using my script as a post processor
to AvsInpaint, InpaintFunc combo.

thanx, be good :)

StainlessS
22nd February 2011, 18:10
@Reuf Toc

See this post for future problem in InPaintFunc.avs

http://forum.doom9.org/showthread.php?p=1479855#post1479855

Beak
26th April 2011, 01:05
Hello. This is my first try at logo removal. I am marginally familiar with scripting but have never seen the error I am getting.

I have AVSInpaint.dll in my Avisynth 2.5 plugins folder. The script is as follows

import("C:\Program Files (x86)\Winnydows\XviD4PSP5\dlls\AviSynth\functions\AudioFunctions.avs")
import("C:\Program Files (x86)\Winnydows\XviD4PSP5\dlls\AviSynth\functions\VideoFunctions.avs")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\AVSInpaint.dll")
Import("C:\Program Files (x86)\AviSynth 2.5\lsfmod\InpaintFunc.avs")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\FFT3dGPU.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\MT.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\MCTemporal Cleaner\mt_masktools-25.dll")

LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\MCTemporal Cleaner\RemoveGrainSSE3.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\MCTemporal Cleaner\RepairSSE3.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\lsfmod\RSharpen.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\lsfmod\WarpSharp.dll")

Import("C:\Program Files (x86)\AviSynth 2.5\lsfmod\LSFMod.avs")
DirectShowSource("G:\In the heat of the night\2011_4_24_15_58_17.avi", fps=23.976, convertfps=true)

ConvertToYV12()
Trim(1168,159461)


MT("""InpaintFunc(last, mask="G:\In the heat of the night\Logo White.bmp", loc="br", AR=16.0/9.0, mode="both", speed=10, ppmode=3, pp=75)""", threads=4, overlap=8)

I get an error for line 3 that says "AVSInpaint.dll is not an Avisynth 2.5 plugin" Does this plugin only work for 2.6? Is there a 2.5 version available.

My LSFMod scripts work etc. I just hadn't added the parameters for LSFMod yet.

I would really appreciate any help that you can offer. Thanks BK

Gavino
26th April 2011, 01:40
I get an error for line 3 that says "AVSInpaint.dll is not an Avisynth 2.5 plugin" Does this plugin only work for 2.6? Is there a 2.5 version available.
AVSInpaint.dll is not a standard plugin (it is writtten in C, not C++) and must be loaded by
LoadCPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\AVSInpaint.dll")

Beak
27th April 2011, 00:36
Thank You. The script now loads with the following error

Mask dimension does not match that of input file.

I checked and they are both 1920X1080.

Any hints for this?

shark000X
7th April 2012, 15:28
Fizick, AMSS0815, thank you for the great work in creating inpaint tools; and Reuf Toc, StainlessS, thanx also for improving appropriate functionality. I'm not a code-writer, so having terrific difficulties to further adopt your tools according to current needs, and hope for effective help.

The problem is with semi-transparent logos, they eliminated under AVSInpaint+exInpaint+Rm_Logo, their inside fields became perfectly transparent but there are glass-like remainders after their borders. At first, I presumed that is the result of encoding artifacts (slight ringing, graining, so on), and treated the logos under variable customizations, including different logo-templates, but nothing could help. Now I guess, the glass remainders caused by aliased edges in the Pre-multiplied Alpha Channels (http://faculty.mdc.edu/jvanvori/Docs/Alpha%20Channels%20de-mystified.pdf) that probably exist in my HDTV-source.
Please, help to find out the right way:

1) Is it correct when I create RGB24 logo mask, or RGB32 is needed for correct operation?
2.1) Can this problem be solved if we change colorspace or matrix when creating "Logo Color" and "Logo Alpha"?
2.2) May be the key is RGBA convertion when creating "Logo Color" and "Logo Alpha" templates?
3.1) Is it feasible at all to eliminate the Pre-multiplied Alpha Channels using your tools, and which tunings to activate in this case?
3.2) If not, are you going to add such functionality?
4) Is it helpful to debug the "Logo Color and Alpha" picture in After Effects, and how to do this?

Sorry for my poor English. Thank you in advance for any help to the right way.

AMSS0815
8th April 2012, 13:40
Hi shark000X,

I can only speak for AVSInpaint here. I don't really understand what you're doing. I guess you used AnalyzeLogo to get the logo's image and alpha mask. Is your source RGBxx or YV12?

> 1) Is it correct when I create RGB24 logo mask, or RGB32 is needed for correct operation?
What is your "logo mask"? In AVSInpaint there are several functions which accept "Mask" arguments, but they will reject RGB24 Mask arguments.

> 2.1) Can this problem be solved if we change colorspace or matrix when creating "Logo Color" and "Logo Alpha"?
If you have to convert the colorspace of the logo's alpha channel, always use Matrix="PC.601" (see DeblendLogo documentation). If you have to convert the colorspace of the logo's image, you're probably doing something wrong.

> 3.1) Is it feasible at all to eliminate the Pre-multiplied Alpha Channels using your tools, and which tunings to activate in this case?
I don't understand this question. The DeblendLogo function eliminates the pre-multiplied alpha channels, frame by frame. This process is slightly faster if the Logo and Alpha arguments are clips with one frame only (see DeblendLogo documentation). Besides that, I don't see how this might be done better.

> 4) Is it helpful to debug the "Logo Color and Alpha" picture in After Effects, and how to do this?
No. I tried this (with other software), but I never managed to improve the output of AnalyzeLogo by hand. If you feel that your alpha mask is bad, you might play around with the DeviationWeight parameter (see doc). If your clip is YV12, SubsamplingWeight might also improve your alpha mask.

> their inside fields became perfectly transparent but there are glass-like remainders after their borders.
Is there a glass-like border of the shape of the logo, or is there a border of a rectangular shape (where you cropped your video when doing the logo removal stuff)? In the latter case, I guess you forgot Matrix="PC.601" somewhere. In the former case, try to improve the output of AnalyzeLogo with these ideas:

Make sure the logo is *completely* contained in the "Mask" which you provide to the AnalyzeLogo function (the mask, where you "suspect the logo to be", according to the docs). I guess you drawed this mask by hand in your favorite image editor. Expand this mask by a few pixels in all direcitions ("dilate" it, in image processing speek).
Crop away all non-image parts of your video (black bars at top/bottom of screen) before handing it over to AnalyzeLogo. If you cannot, include them in the "Mask" as well (see doc).
Areas which are legitimate movie content and not altered by any logo/whatever should not be covered by AnalyzeLogo's "Mask" argument. They serve as reference material to estimate the alpha mask.

There is also a chance that your glass-like border comes from mosquito noise (see wikipedia). This noise is like an alpha mask which changes in each frame and which cannot be fixed with AnalyzeLogo. Last resort might be to set mask this border by hand and cover it with InpaintLogo.

-- AMSS0815

shark000X
9th April 2012, 02:16
Hi AMSS0815, thank you for fast reply!

Just to avoid some misunderstanding (my fault), here is additional information:

5) The video source: 1280x720, YV12, TV.709, 4:2:0 (it doesn't contain any non-image parts at top/bottom of screen);
6) I provide *.bmp (RGB24 colorspace - is here possible mistake?) as the "Mask" argument to the AnalyzeLogo. The BMP contains the logo image (pure white template) surrounded by pure black background. The source logo is completely contained in the "Mask", moreover tried to vary its dilating range. Legitimate movie content is not covered by the AnalyzeLogo's "Mask" argument, except the dilated area.
7) The Logo and Alpha arguments are clips with one frame only (both BMP RGB24) processed further with assistance of the Rm_Logo.avs (Spuds' subfunction).
8) As a whole result of process, the source logo is correctly replaced by legitimate underlayer but the shape of source logo turned into glass-like border.

Now, after close examination I see that both subfunctions (Rm_Logo by Spuds, and InpaintFunc by Reuf Toc) operate the DeviationWeight and SubsamplingWeight parameters under default values (0.5). May be this is the graal for my situation - to tune both "Weight"s, starting with 0.25 SubsamplingWeight... Could you tell me please the reasonable measures for the DeviationWeight?

Nevertheless, the above-mentioned "Last resort" remains under my consideration, though it would be in history - I've tried to set a mask over the border and cover it with Inpaint in such a (perhaps stupid) way:

created an additional logo template where only the shapes are colored in white;
utilized the Logo.vdf to mix the additional logo as new semi-solid alpha channel into the source logo;
placed the Logo.vdf function right before the AnalyzeLogo function in the same avs-script.

Finally, the process was much-much-mucho slower, and the result was not satisfactory due to extensive blurriness. This is why I asked you about debugging (or "editing" may be more correct) the "Logo Color and Alpha" picture in After Effects. So, a specifying question:

9) For the above "to set mask this border by hand" - do you mean a simple painting (Photoshop or else) of white boarders in the Alpha-mask.bmp created by the AnalyzeLogo?

Thank you for support, AMSS0815. My mind is clearing up under your suggestions :)

Have a nice day!

AMSS0815
9th April 2012, 23:56
Hi shark000X,

I provide *.bmp (RGB24 colorspace - is here possible mistake?) as the "Mask" argument to the AnalyzeLogo.
How do you get this file into AviSynth? With ImageReader/ImageSource? Inside AviSynth these are always clips (possibly with one frame only). Use AviSynth's Info function to determine the colorspace of a clip. Well, AnalyzeLogo would fail if the Mask isn't RGB32 (or YUY2/YV12), so it probably is.

7) The Logo and Alpha arguments are clips with one frame only (both BMP RGB24) processed further with assistance of the Rm_Logo.avs (Spuds' subfunction).
What exactly happened with the output of AnalyzeLogo (which I presume was a clip with one 1280x1440 frame) before it became the input of DeblendLogo? I recommend to split the output of AnalyzeLogo with Crop into two frames (1280x720) and save them with ImageWrite as ebmp files. Yes, ebmp, not bmp (see my Demo.avs). ebmp is something like a AviSynth-only format, it can save anything, even YV12, and it reduces the chances that the brightness of your mask is modified in some conversion steps somewhere. I cannot comment on what Rm_Logo does with the logo/alpha mask. But I recommend to (temporarily) skip this "processed further" step.

This is really important! If you convert Y**<-->RGB** colorspaces with the output of AnalyzeLogo before handing the result over to DeblendLogo, you risk that the Y-levels of the mask get converted to a different scale somewhere.

Now, after close examination I see that both subfunctions (Rm_Logo by Spuds, and InpaintFunc by Reuf Toc) operate the DeviationWeight and SubsamplingWeight parameters under default values (0.5). May be this is the graal for my situation - to tune both "Weight"s, starting with 0.25 SubsamplingWeight... Could you tell me please the reasonable measures for the DeviationWeight?
Errr, don't expect too much here. I picked the default 0.5 because it gave me the best results for my own experiments. I always felt that DW=0 and SW=1 would be the natural choice here, but the results were bad. You might try values like 0.0, 0.1, 1.0 and maybe 1.5, (with 0.5, that's 25 combinations for both parameters together), but I'd be surprised if it solves your problem.


Nevertheless, the above-mentioned "Last resort" remains under my consideration, though it would be in history - I've tried to set a mask over the border and cover it with Inpaint in such a (perhaps stupid) way:

created an additional logo template where only the shapes are colored in white;
utilized the Logo.vdf to mix the additional logo as new semi-solid alpha channel into the source logo;
placed the Logo.vdf function right before the AnalyzeLogo function in the same avs-script.

Finally, the process was much-much-mucho slower, and the result was not satisfactory due to extensive blurriness. This is why I asked you about debugging (or "editing" may be more correct) the "Logo Color and Alpha" picture in After Effects. So, a specifying question:

9) For the above "to set mask this border by hand" - do you mean a simple painting (Photoshop or else) of white boarders in the Alpha-mask.bmp created by the AnalyzeLogo?

Yes. But I really don't see for what you use Logo.vdf (the VirtualDub Logo plugin?) here? I am talking about an additional mask here. You still use DeblendLogo as described above with the (unmodified) output of AnalyzeLogo. You use your favorite image editor to open any mask, or a screenshot of a frame with that glassy border, and then you draw a mask which covers the glassy border (and nothing else) by hand. It should result in a file that looks like a white ring with black interior and black exterior. This mask you save in a new file. Then you apply InpaintLogo to the output of DeblendLogo and feed the new (ring-like) mask as one-frame-clip "Mask" into InpaintLogo.

Another idea: Maybe the chroma subsampling is guilty here. I don't think so, but check what happens if you start with your clip converted to RGB24.

And a sidenote: I assume you do your experimentation just with a small part of the clip. Running AnalyzeLogo is a time-consuming operation! So if you want e.g. play around with the results of different Weight parameters, you might want to use AviSynth's SelectEvery filter to reduce the number of frames analyzed (which of course reduces the quality of the output of AnalyzeLogo). It is also legitimate to crop away parts of the movie that are far away of the logo, such that the Mask you provide to the AnalyzeLogo function occupies approx 1% of the frame's area.

Maybe you can post some pictures (of masks and logos and a glassy border). I'm still not sure if I understand what you're doing.

Another sidenote/disclaimer: I stopped using (Windows and) AviSynth years ago, so my hints are purely theoretical.

-- AMSS0815

shark000X
11th April 2012, 20:25
Hi AMSS0815,

...you might want to use AviSynth's SelectEvery filter to reduce the number of frames analyzed (which of course reduces the quality of the output of AnalyzeLogo). It is also legitimate to crop away parts of the movie that are far away of the logo...
I've saved a few % of the source movie into a separate experimental clip to reduce the number of frames as they be 100%-analyzed, so the quality of the AnalyzeLogo output is not reduced by partial analysis. Also I've cropped away the far-away-parts of the movie as follows: L=1040, T=0, R=0, B=-580 (240x140 input to the AnalyzeLogo).

I tried to play with the DeviationWeight and SubsamplingWeight, but failed to solve my problem, you were right as to their values.
Unfortunately, any code-writing is still complicated for me, so further I need to go through appropriate particles of a script in different variants (please check if they are legitimate or not) to meet the above specifying questions of yours.
How do you get this file into AviSynth? With ImageReader/ImageSource?...
AnalyzeLogo would fail if the Mask isn't RGB32 (or YUY2/YV12), so it probably is.
...........
Another idea: Maybe the chroma subsampling is guilty here. I don't think so, but check what happens if you start with your clip converted to RGB24.
I wonder, is it worthy here to change colorspaces another way or/and not to crop the analyze clip at all (?):
# We crop the analyze clip and set a percentage for speed
cropped = clip.crop(L,T,R,B)
snipSize = round( framecount( cropped ) / (framecount( cropped ) * (percent / 100.0) ))
AnalyzeClip = ( percent != 100 ) ? cropped.SelectRangeEvery( snipSize, 1 ) : cropped
# ...........
# We provide the RGB24 *.bmp (C1 above) as the "Mask" argument for analysis,
# the corner of interest is cropped out
logo_mask = imagesource(Mask,start=0,end=1)
logo_mask = logo_mask.crop(L,T,R,B)
logo_mask = logo_mask.ConvertToYV12(Matrix="PC.601")
logo_mask = logo_mask.DistanceFunction(255/deblendfalloff).Greyscale
# ...........
# We clean the analyze clip to improve results
AnalyzeClip = (IsYV12(AnalyzeClip)) ? AnalyzeClip : AnalyzeClip.ConvertToYV12
AnalyzeClip = AnalyzeClip.TTempSmoothF(maxr=2,lthresh=256,cthresh=256,scthresh=255).ConvertToRGB24()
# Is it better here to use ConvertToRGB32() instead of ConvertToRGB24(), or leave it without any?
#
# ...........here we check if a resulting ebmp exists or if it has changed
# We perform the logo analysis
{
AnalyzeClip.AnalyzeLogo(logo_mask)
# and save the resulting frame
Trim( 0, -1 )
ImageWriter( "AnalyzeResult", 0, 1, "ebmp" )
}

When I rename the resulting *.ebmp into *.bmp (that's why it was earlier called BMP) I can see its properties -- 240x280 RGB24, the Avisynth Info() referring to the *.ebmp shows me the same properties.
What exactly happened with the output of AnalyzeLogo... before it became the input of DeblendLogo?
...........
This is really important! If you convert Y**<-->RGB** colorspaces with the output of AnalyzeLogo before handing the result over to DeblendLogo, you risk that the Y-levels of the mask get converted to a different scale somewhere.
# We split the color map and the alpha channel from the resulting ebmp
AssumeFPS(AnalyzeClip.FrameRate)
LogoColor = Crop(0,0,0,last.Height/2)
LogoAlpha = Crop(0,last.Height/2,0,0).ConvertToYV12(Matrix="PC.601")
# We use MaskTools.v2 to mark pixels that cannot be deblended
LogoAlpha.Invert.mt_lut(expr="x " + " " + string(alphatorepair) + " " + "< 255 0 ?").mt_expand.mt_inflate
RepairMask = ( RepairRadius > 0.1 ) ? DistanceFunction( 84.0 / RepairRadius, PixelAspect=par ) : last

Instead of MaskTools (the last 2 strings of above script) I tried to use the particle from your Demo (but the problem was not eliminated):
# Prepare repair mask (marks pixels that cannot be deblended)
LogoAlpha
Invert
Levels(AlphaToRepair,1,AlphaToRepair+1,255,0,false)
(RepairRadius>0.1)?DistanceFunction(127.0/RepairRadius):last
Levels(127,1,128,0,255,false)
Greyscale
RepairMask = last

Graphics and gestures may be a better way to communicate for a non-English speaker as I am, so please excuse me for not providing pictures from the very beginning, that would save your time.

Here is a frame of my source (see A below) -- the logo is really annoying if untouched; btw, the movie needs some color denoise, I did it but couldn't help the problem we discuss here. The logo seems to be removed (B below) with your magic tool when I provide the "Mask" argument (C below) to the AnalyzeLogo followed by simple deblending (no inpainting, no extra tunings with "weights" or else):
A1>http://thumbnails71.imagebam.com/18419/fc31fb184184395.jpg (http://www.imagebam.com/image/fc31fb184184395) B1>http://thumbnails65.imagebam.com/18419/06e5e6184184400.jpg (http://www.imagebam.com/image/06e5e6184184400)
C1>http://thumbnails75.imagebam.com/18419/be104e184184425.jpg (http://www.imagebam.com/image/be104e184184425)
But under a closer look we can find unblended shapes of the logo (A below; it undergone triple upsampling for a comfortable look). Anyway, the result would be acceptable if only the shapes were not so intense against the deeply dark and light backgrounds (B below) over and over again, though disappearing within the contrasting light areas (C below):
A2>http://thumbnails76.imagebam.com/18453/1b6c95184527355.jpg (http://www.imagebam.com/image/1b6c95184527355) B2>http://thumbnails38.imagebam.com/18419/5b1051184184417.jpg (http://www.imagebam.com/image/5b1051184184417)
C2>http://thumbnails45.imagebam.com/18453/45347e184527354.jpg (http://www.imagebam.com/image/45347e184527354) D2>http://thumbnails75.imagebam.com/18440/50ef58184392713.jpg (http://www.imagebam.com/image/50ef58184392713)
The above B and C together is a good example of the glass-like effect (the opposite shapes of the logo change their luminance antithetically when crossing over dark and light areas) that goes through all the movie. Your magic tool, as I see, is strong enough to deblend the whole logo without distructive inpaintings, but something disturbs the ability :confused: Or is it really the mosquito-noise in my source (D above)?

Thank you.
Waiting for your wisdom and expertise.
Have a good time.

AMSS0815
12th April 2012, 09:53
Hi, I'm quite busy at the moment and will have a closer look this (UTC-)evening or at weekend. Just a few quick thoughts:

The logo itself looks "good", i.e., I have the feeling it should be easy to remove it. I cannot see dynamics though. Do you have the feeling that it changes from frame to frame, maybe in front of a bright background?
I cannot see any mosquito noise on your A1 frame, so that's not a problem.
You wrote something about color denoising. Try to put any such steps behind the delogo step. Linear filters (brightening etc.) shouldn't be a problem, but e.g. AviSynths spatial denoiser will modify the logo such that it can no longer be deblended by a simple linear map as my filter does it.
Your initial mask C1 looks OK. However: Inflate it by another 8 pixels.
You wrote you saved a small clip to a separate file. Try to avoid such steps, especially if they involve loosy compression. Always work with the original clip in AviSynth, i.e. the raw material which was produced by your DVB hardware or downloaded from Internet or whereever it came from. If you have to transform it with special software because it is a format not readable by AviSynth, do this with highest possible quality setting. In AviSynth, if you want to do a test run with few frames, use Trim or SelectEvery on /the original clip/.
Reducing the framecount (Trim/SelectEvery) and Crop'ping away parts of the movie will both reduce the AnalyzeLogo quality. I think you crop away too much. Maybe crop away 3/4 of the movie area... Since I feel we're running out of ideas: Try again with the inflated mask (see above) and the full clip (no Trimming/Cropping). Make sure you're delogo'ing does not inadvertedly use the old AnalyzeLogo output.
At the moment you should not need the DistanceFunction (I saw this somewhere in your scripts).
After running AnalyzeLogo /and/ after saving the output as ebmp, print out the "Info" of AnalyzeLogo output. The framecount of this clip is a hint on how many frame have actually been analyzed before the buffers of AnalyzeLogo ran full. Is it lower than the framecount of the original clip?

-- AMSS0815

AMSS0815
14th April 2012, 17:30
You wrote you saved a small clip to a separate file.[...]
Argh, sorry, I didn't read the script you posted.

So I suggest to cut away less (in space and time). I propose the following modified version of your script:

L=clip.Width/2 # [AMSS0815 modification!] More reference area
T=0
R=0
B=-clip.Height/2 # [AMSS0815 modification!] More reference area

# We crop the analyze clip and set a percentage for speed
cropped = clip.crop(L,T,R,B)
snipSize = round( framecount( cropped ) / (framecount( cropped ) * (percent / 100.0) ))
AnalyzeClip = ( percent != 100 ) ? cropped.SelectRangeEvery( snipSize, 1 ) : cropped
# ...........
# We provide the RGB24 *.bmp (C1 above) as the "Mask" argument for analysis,
# the corner of interest is cropped out
logo_mask = imagesource(Mask,start=0,end=1)
logo_mask = logo_mask.crop(L,T,R,B)
logo_mask = logo_mask.ConvertToYV12(Matrix="PC.601")
logo_mask = logo_mask.Grayscale # [AMSS0815 modification!] Remove spurious colors from cs conversion
logo_mask = logo_mask.DistanceFunction.Levels(254-8,1,255-8,0,255,false) # [AMSS0815 modification!] Inflate 8 px
#logo_mask = logo_mask.DistanceFunction(255/deblendfalloff).Greyscale # [AMSS0815 modification!] Not needed (me thinks)
# ...........
# We clean the analyze clip to improve results
#AnalyzeClip = (IsYV12(AnalyzeClip)) ? AnalyzeClip : AnalyzeClip.ConvertToYV12 # [AMSS0815 modification!] RGB is probably better
AnalyzeClip = AnalyzeClip.ConvertToRGB24(Matrix="PC.601") # [AMSS0815 modification!]
#AnalyzeClip = AnalyzeClip.TTempSmoothF(maxr=2,lthresh=256,cthresh=256,scthresh=255).ConvertToRGB24() # [AMSS0815 modification!] No! Not here
# Is it better here to use ConvertToRGB32() instead of ConvertToRGB24(), or leave it without any?
#
# ...........here we check if a resulting ebmp exists or if it has changed
# We perform the logo analysis
{
AnalyzeClip.AnalyzeLogo(logo_mask)
fc = FrameCount # [AMSS0815 modification!] Save now, print later
# and save the resulting frame
Trim( 0, -1 )
ImageWriter( "AnalyzeResult", 0, 1, "ebmp" )
}
MessageClip(string(fc)) # [AMSS0815 modification!] Print number of frames analyzed

Does the number printed here match the framecount of your input clip (with percent=100)?
Can you upload the resulting ebmp?
And of course the main question:

cropped = the clip from above !
ImageSource("AnalyzeResult%06d.ebmp",0,0)
AssumeFPS(cropped.FrameRate)
LogoColor = Crop(0,0,0,Height/2)
LogoAlpha = Crop(0,Height/2,0,0).ConvertToYV12(Matrix="PC.601")
cropped
ConvertToRGB24(Matrix="PC.601")
last.DeblendLogo(LogoColor,LogoAlpha)

What does this look like?

The logo in your picture A1 does not seem to have any opaque areas. If this is indeed the case, there is no need to use InpaintLogo (and no need to prepare RepairMasks).

Are B2 and D2 also frame from the movie --- did the camera focus on something very pink?

If this does not work, you will have to draw a mask for InpaintLogo (by hand) which marks the areas that exhibit this glass effect, and then use InpaintLogo to fix those areas. Sorry, but I have no further ideas.

-- AMSS0815

shark000X
16th April 2012, 20:00
Hi AMSS0815,

I spent the whole weekend and monday's night for additional experiments (have more ideas) and practice upon your suggestions, so please don't consider my silence as a falling away. My last good-buy to this problem will be obvious for you as soon as possible :)
You wrote you saved a small clip to a separate file. Try to avoid such steps, especially if they involve loosy compression. Always work with the original clip...
.............
Reducing the framecount (Trim/SelectEvery) will reduce the AnalyzeLogo quality.
.............
Does the number printed here match the framecount of your input clip (with percent=100)?
From the very beginning I've been processing the experimental clip (a 4-minutes cut out from the source) that keeps the original quality - no trimming, no compression. When experimenting, it's a rule for me to use the Lagarith lossless if encoding needed... The above-suggested FrameCount() shows the same number of frames as the input movie includes.

Make sure you're delogo'ing does not inadvertedly use the old AnalyzeLogo output.
No problem here.

Are B2 and D2 also frame from the movie --- did the camera focus on something very pink?
Here is the experimental clip: https://rapidshare.com/files/3942090763/ExperimentalClip.ts . The B2 and D2 are frames from the movie (see closer to the end of the clip).
Can you upload the resulting ebmp?
And of course the main question:
cropped = the clip from above !
ImageSource("AnalyzeResult%06d.ebmp",0,0)
AssumeFPS(cropped.FrameRate)
LogoColor = Crop(0,0,0,Height/2)
LogoAlpha = Crop(0,Height/2,0,0).ConvertToYV12(Matrix="PC.601")
cropped
ConvertToRGB24(Matrix="PC.601")
last.DeblendLogo(LogoColor,LogoAlpha)
What does this look like?
Here is the ebmp (https://rapidshare.com/files/3729381063/AnalyzeResult000000.ebmp) resulted from this script:
Movie = last # 1280x720 YV12 BT709-5

DeblendFalloff=8
L=0 # Movie.Width/2 # [AMSS0815 modification!] More reference area
T=0
R=0
B=0 # -Movie.Height/2 # [AMSS0815 modification!] More reference area

# We provide the "Mask" argument for analysis, the corner of interest is cropped out
ImageSource("D:\Temp\Logo\LogoMask.bmp",start=0,end=1).crop(L,T,R,B)
Logo_mask = last
Logo_mask = Logo_mask.ConvertToYV12(Matrix="PC.601")
Logo_mask = logo_mask.Grayscale # [AMSS0815 modification!] Remove spurious colors from cs conversion
Logo_mask = logo_mask.DistanceFunction.Levels(254-DeblendFalloff,1,255-DeblendFalloff,0,255,false) # [AMSS0815 modification!] Inflate 8 px

cropped = Movie.crop(L,T,R,B)
AnalyzeClip = cropped.ConvertToRGB24(Matrix="PC.601") # [AMSS0815 modification!]

try{ # We check if a resulting ebmp exists or if it has changed
ImageSource("D:\Temp\Logo\AnalyzeResult%06d.ebmp",0,0)
(Interleave(AssumeFPS(Movie.FrameRate),AnalyzeClip.Trim(0,-2).AnalyzeLogo(Logo_mask)).FrameCount>-10)?last:last
}catch(dummy){
# We perform the Logo analysis, the color and the alpha mask are returned
AnalyzeClip.AnalyzeLogo(Logo_mask)
# AnalyzeFrameCount = FrameCount # [AMSS0815 modification!] Analyze returns the number of frames processed as frame count of the resulting clip
Trim(0,-1)
ImageWriter("D:\Temp\Logo\AnalyzeResult",0,1,"ebmp") # Frame is written to hard disk
}
#MessageClip(string(AnalyzeFrameCount)) # [AMSS0815 modification!] Print number of frames analyzed

ImageSource("D:\Temp\Logo\AnalyzeResult000000.ebmp",0,0)
AssumeFPS(movie.FrameRate)
LogoColor = Crop(0,0,0,Height/2)
LogoAlpha = Crop(0,Height/2,0,0).ConvertToYV12(Matrix="PC.601")

cropped
ConvertToRGB24(Matrix="PC.601")
DeblendedClip = last.DeblendLogo(LogoColor,LogoAlpha)
Here is Alpha (A below) from the above ebmp, and the result of deblending (B below, comparing to B1) that partially includes the Alpha -- this effect is more visible instead of light background (C below) /is it a wrong estimated alpha mask?/.
A3>http://thumbnails69.imagebam.com/18525/a7eac6185244183.jpg (http://www.imagebam.com/image/a7eac6185244183) B3>http://thumbnails65.imagebam.com/18525/536fc7185244197.jpg (http://www.imagebam.com/image/536fc7185244197)
C3>http://thumbnails70.imagebam.com/18525/835bb2185244191.jpg (http://www.imagebam.com/image/835bb2185244191) D3>http://thumbnails45.imagebam.com/18526/d4bf0e185252642.jpg (http://www.imagebam.com/image/d4bf0e185252642)
The above D3 shows the final result when completing the code with the "step by Karel Suhajda" as you call it:Movie.ConvertToRGB32.Layer(DeblendedClip.ConvertToRGB32.Mask(Logo_mask.ConvertToRGB32(Matrix="PC.601")))
ConvertToRGB24
I cannot see dynamics though. Do you have the feeling that it changes from frame to frame, maybe in front of a bright background?
When deblending with previous settings (a highly-cropped clip analized), I have the feeling that aftershapes change their colors depending on a mix of surrounding colors, and a mix of dark colors is partially masked by a darker background, while be more visible instead of bright backgrounds. But uncropped frames as well as twice-cropped ones look as if AVSinpaint is focus-sensitive, I mean it may be not correct in analizing big areas and may cause mirror-effects on small areas (I do wish I'd be mistaken in this matter) when going far away from an artificial center (e.g. when a set of calculations start from and depend on a set of core measures, such as 720 width and 576 height, with further enlargement or shrinking from this core).

At this time I'm trying variable options to convert the colormatrix of my clip before feeding it to AVSinpaint. I feel it may help. Finally, if our efforts will not be productive, do you consider a two-stage deblending as a good variant instead of post-inpainting?

Thank you very much for your time.
Have a good, successful day!

shark000X
21st April 2012, 03:12
Hi AMSS0815,

There is not much progress with my problem. I've tried all variants of colormatrix transform (PC<->TV between 601, 709, 240 and FCC standards) that my source could possibly undergone before the final encoding. Some interesting results occurred, but they are hard to implement.

The shapes of logo look better for deblending after TV.709->PC.FCC transform (yeah, my source has a European nature for sure, so it was more intuitive than logical idea to try the American FCC standard). Moreover, TV.240->PC.601 is the best variant, but still not enough for illuminated areas especially.

The first conclusion here - the levels want to be restricted to TV-range before colormatrix changing.

Further, let us analyze the colormatrix tables (the right one created for comfortable searching of dependences):
http://thumbnails63.imagebam.com/18600/36cea4185998463.jpg (http://www.imagebam.com/image/36cea4185998463) http://thumbnails45.imagebam.com/18602/f0fd51186012582.jpg (http://www.imagebam.com/image/f0fd51186012582)
Keeping in mind the results, I see they are better when increasing the Red coefficient up to 41% (the 0.087 differential for both 709->FCC and 240->601), while decreasing the Green and increasing the Blue coefficients. The tendency is obvious, but the Blue doesn't like a much difference from the previous state (53% loose against 31%).

The second conclusion here - the color balance is not suitable for the AnalyzeLogo.

Proceeding from the above conclusions I tried (assuming it is useless) to prepare the movie under AutoGain and AutoLevels (simultaneously and not) -- they certainly helped to make the logo more solid (it's a kind of goodbye to further deblending). I don't know any other way to find the good color balance for AnalyzeLogo, except the hundreds or thousands iterations for manual picking-up-and-down. Uuuff, it's driving me crazy sometime, but I continue experiments and looking for new reasonable opportunities.

Since the above situation arrived, some new questions appeared:
10) Is there any additional convertion activated inside the AVSinpaint? (e.g. if YV12 or YUY2 inputed to AVSinpaint but further converted for inside RGB processing)
11) Does AVSinpaint include any specific restrictions as to color balance? If yes, how can I learn them and/or improve?

I am not going to annoy like the logo does, but AMSS0815 please tell me at least if you can help me or not to deblend it.
Thank you. Good bye.

AMSS0815
21st April 2012, 12:59
Hi shark000X,

I downloaded your ExperimentalClip and successfully reproduced your glass-like effect. I think you're doing everything allright, yet the problem persists. So my conclusion is that you cannot remove this logo with my tools. I observed that not only the borders of this logo, but also the interior is badly deblended: It is still brighter that its surrounding when it is in front of a bright background. Maybe the logo was added in some "nonlinear" way to the video or something else "nonlinear" happened with it while being processed further before it was delivered to you. (Nonlinear refers to some transformation that is incompatible with my linear model, see documentation of plugin). I tried to fix this with InpaintLogo, even to the point of inpainting the whole logo region, but since the logo is so big, the result was horribly ugly.

(I only considered 4 minutes of your clip since I had to transform it to huffyuv, but I'm sure the results would be the same if I took the whole clip).

Nevertheless I can answer your questions as follows:

But uncropped frames as well as twice-cropped ones look as if AVSinpaint is focus-sensitive, I mean it may be not correct in analizing big areas and may cause mirror-effects on small areas (I do wish I'd be mistaken in this matter) when going far away from an artificial center

I don't really understand this comment. The main functionality of AnalyzeLogo is the detection of the alpha mask of the logo. For this it computes the sample covariance of the logo pixels and compares it with the sample covariance of surrounding pixels (cf. doc). The underlying assumption is that the covariances would be the same without the logo and the covariances with logo are reduced by the alpha value of the logo (high opacity means low variance). This obviously fails if the variances differ in space, that's why non-picture parts of the movie have to be removed or masked before AnalyzeLogo is used. But I don't think your clip suffers from such a spacial variance difference. Also, I tested AnalyzeLogo with different croppings and it didn't help --- well, it didn't help me, but maybe you're lucky here.

Finally, if our efforts will not be productive, do you consider a two-stage deblending as a good variant instead of post-inpainting?

Two-stage means Analyze+Deblend, then Analyze+Deblend the result? This is an interesting idea. I just tried it and the second mask (result of second AnalyzeLogo invocation) shows just white noise where the logo is. The final result didn't really look better. (Theoretically, I would expect the second invocation of AnalyzeLogo to produce an all-black mask. I don't know where the noise comes from.)

10) Is there any additional convertion activated inside the AVSinpaint? (e.g. if YV12 or YUY2 inputed to AVSinpaint but further converted for inside RGB processing)

No. At some points averages of pixel color values are required. If I remember correctly, InpaintLogo has to create a common structuring tensor from gradients of red/green/blue color planes. This tensor is a convex combination of the three tensors of each plane, <NOT TRUE>with coefficients taken from some well known RGB-->YUV conversion matrix</NOT TRUE>. AnalyzeLogo has to compute a common alpha channel from each color plane's alpha channel, this is also a convex combination, and the coefficients can be controlled by the *Weight parameters. But I don't see a problem in all these conversations.

11) Does AVSinpaint include any specific restrictions as to color balance? If yes, how can I learn them and/or improve?

Err, somehow no. AnalyzeLogo assumes that the logo's alpha mask is the same for each channel (r,g,b or y,u,v). If you rescale one channel only, this assumption is no longer valid and AnalyzeLogo produces some average of the different alpha channels. While I'm not sure what "color balance" is, I don't think there are any more restrictions.

btw: I also tried to Analyze+Deblend a Grayscale version of your clip, and each RGB channel separately. All four tests failed, i.e., showed the glass-like effect.

Sorry, I'm out of ideas. As I said above, it seems AVSInpaint isn't suitable for this kind of logo.

Although my name is part of the AVSInpaint code/copyright-notes/documentation and hence public, I would prefer you use my pseudonym (AMSS0815) when you address me here. Thanks.

-- AMSS0815

shark000X
22nd April 2012, 15:41
Hi AMSS0815,

Two-stage means Analyze+Deblend, then Analyze+Deblend the result? This is an interesting idea. I just tried it and the second mask (result of second AnalyzeLogo invocation) shows just white noise where the logo is.
Yes, you understand me right. And perhaps the second stage of Analyze+Deblend needs some kind of pre- and/or post-processing with denoisers, but I'm going to try the denoising later if intrusion-free methods of simple deblending will be exhausted.

I also tried to Analyze+Deblend a Grayscale version of your clip, and each RGB channel separately. All four tests failed, i.e., showed the glass-like effect.
Me too. Sorry that have not mentioned it earlier, I could prevent you from this unnecessary action if only knew you were going for some experiments. And please have my excuse for neglecting the pseudonym, it was done automatically (sometimes it is much faster to write a wellknown human name than to copypaste a nickname consisting of character set not easy to remember).

...a common structuring tensor from gradients of red/green/blue color planes. This tensor is a convex combination of the three tensors of each plane, with coefficients taken from some well known RGB-->YUV conversion matrix. AnalyzeLogo has to compute a common alpha channel from each color plane's alpha channel, this is also a convex combination, and the coefficients can be controlled by the *Weight parameters.
Aha. It may be the reason why we need to make PC.601 before analyzing a clip, I presume the three-spined tensor is calculated according to the following matrix resulting in some restrictions:
http://thumbnails45.imagebam.com/18627/abc608186264261.jpg
I wonder would it be helpful to clean the restrictions if the AnalyzeLogo translated colorspaces using another method, e.g. as for Y'UV420p to RGB (see http://en.wikipedia.org/wiki/YUV ):
size.total = size.width * size.height;
y = yuv[position.y * size.width + position.x];
u = yuv[(position.y / 2) * (size.width / 2) + (position.x / 2) + size.total];
v = yuv[(position.y / 2) * (size.width / 2) + (position.x / 2) + size.total + (size.total / 4)];
rgb = Y'UV444toRGB888(y, u, v);
http://thumbnails64.imagebam.com/18627/1c96a8186264268.jpg
The Y', U and V components are computed separately in sequential blocks, the above diagram shows (corresponding Y', U and V values are shown using the same color). A Y' value is stored for every pixel, followed by a U value for each 2x2 square block of pixels, and finally a V value for each 2x2 block. Reading line-by-line as a byte stream, the Y' block would be found at position 0, the U block at position x*y (6*4 = 24 in this example) and the V block at position x*y + (x*y)/4 (here, 6*4 + (6*4)/4 = 30). Moreover, this method let us control the DeviationWeights separately for each channel, as I hope.

........
Errr, actually I've started this post yesterday after your reply, but the incorrect color balance of the movie was drilling my mind all the time, so I interrupted and tried the Photoshop to widely analize some frames of the source. Now it seems the movie is mainly out of gamut (Photoshop>> Select / Range / Out of Gamut). When certain colors cannot be expressed within a particular color model, those colors are said to be out of gamut. As I think, the out of gamut colors may lead the AnalizeLogo to a wrong color estimation and big mistakes when creating the color map. And, following back to
When deblending with previous settings (a highly-cropped clip analized), I have the feeling that aftershapes change their colors depending on a mix of surrounding colors, and a mix of dark colors is partially masked by a darker background, while be more visible instead of bright backgrounds. But uncropped frames as well as twice-cropped ones look as if AVSinpaint is focus-sensitive, I mean it may be not correct in analizing big areas and may cause mirror-effects on small areas (I do wish I'd be mistaken in this matter) when going far away from an artificial center
the bigger the analized area, the more volume of extragamut colors is estimated turning the AnalizeLogo into a blind kitten.

As I knew from the Photoshop Bible, to handle the out of gamut colors we need to change the hue and saturation. Heh, it is not so complicated when editing a separate image, but some kind of Hue-Saturation-Brightness model is needed to enough edit the thousands frames and preserve a good balance. Fortunately, after some non-productive experiments, I found two threads with great ideas as to this matter ( http://forum.doom9.org/showthread.php?p=1405481#post1405481 , EDIT: http://forum.doom9.org/showthread.php?t=154731 ), and now going to try the functions...

Would the end-point be successful or not, thank you AMSS0815 for your participation, efforts and the great tool. I'm going to post the results for other users here, if you don't mind, to help avoid some bothering questions in future. Anyway, if you'll have some time, the further comments are much appreciated since you are the only guru here for last years who explains the problems of logo-removing.

Good bye

AMSS0815
23rd April 2012, 22:51
...a common structuring tensor from gradients of red/green/blue color planes. This tensor is a convex combination of the three tensors of each plane, with coefficients taken from some well known RGB-->YUV conversion matrix. AnalyzeLogo has to compute a common alpha channel from each color plane's alpha channel, this is also a convex combination, and the coefficients can be controlled by the *Weight parameters.Aha. It may be the reason why we need to make PC.601 before analyzing a clip, I presume the three-spined tensor is calculated according to the following matrix resulting in some restrictions:
[.....]No. I was wrong about the RGB<-->YUV conversion matrix. It is never directly used in my plug in. If InpaintLogo is applied to a RGB clip, the convex combination is simply the average of all 3 (or 4 for RGBA) channels. For YUV clips, the ChromaWeight parameter controls the coefficients. Coefficients for AnalyzeLogo's common alpha mask value are controlled by the estimated alpha values of each channel and a subsampling factor. There is also no RGB<-->YUV matrix involved here. (I learned that by reading my own docs).Now it seems the movie is mainly out of gamut (Photoshop>> Select / Range / Out of Gamut). When certain colors cannot be expressed within a particular color model, those colors are said to be out of gamut. As I think, the out of gamut colors may lead the AnalizeLogo to a wrong color estimation and big mistakes when creating the color map.This is out of my expertise. If this means that the color values of your video were once rescaled and clipped (at least in audio processing this is called clipping, if they exceed the highest possible value), then yes, this is a kind of distortion that would violate AnalyzeLogo's assumptions about the logo and hence create a broken mask.I'm going to post the results for other users here, if you don't mind, to help avoid some bothering questions in future.Of course. I don't see myself as the owner of this thread anyway.
-- AMSS0815

shark000X
25th April 2012, 19:24
Eureka!

Hi AMSS0815,

I'm at complete understanding where the problem grows from.

I was wrong about the RGB<-->YUV conversion matrix. It is never directly used in my plug in... For YUV clips, the ChromaWeight parameter controls the coefficients. Coefficients for AnalyzeLogo's common alpha mask value are controlled by the estimated alpha values of each channel and a subsampling factor. There is also no RGB<-->YUV matrix involved here. (I learned that by reading my own docs).
.................
If ... the color values of your video were once rescaled and clipped ..., then yes, this is a kind of distortion that would violate AnalyzeLogo's assumptions about the logo and hence create a broken mask.
Yeh, now I see a matrix itself cause no problem here, but the AnalizeLogo operates the inner-restricted 128 range for Chroma -- the same way as a simple YUV->RGB convertion does (Ymax=255, Umax=128, Vmax=128) -- resulting all the U and V values out of 128 range to be clipped by the AnalizeLogo itself, even if they haven't been distorted while a source movie undergone editing and encoding. As a practical example, there is a kind of picture how the AnalizeLogo could do (if not restricted to 128 range) but does not recognize the logo EDITed>(the non-black parts show the clipped RGB-illegal colors which lead to the violate assumptions):
A4>http://thumbnails19.imagebam.com/18712/11b231187116958.jpg (http://www.imagebam.com/image/11b231187116958) B4>http://thumbnails75.imagebam.com/18712/426b68187116961.jpg (http://www.imagebam.com/image/426b68187116961)
C4>http://thumbnails22.imagebam.com/18712/c45262187116956.jpg (http://www.imagebam.com/image/c45262187116956) D4>http://thumbnails64.imagebam.com/18712/df75b8187116965.jpg (http://www.imagebam.com/image/df75b8187116965)
The A4 image is correspondent to A1, B1, A2 sourced from the same frame, and B4 corresponds to B2, D2. The tendency is obvious: the logo remains closer to untouched when itself containing illegal colors (see B4<->B2), and it's better deblended when free of illegal colors (A4<->A2) but still remains visible because surrounded by out-of-gamut areas or because of the violate assumptions caused by the rest of frames (there are a lot of them like C4, D4). These images are taken after running the ShowBadRGB function, thanx to Gavino (http://forum.doom9.org/showthread.php?p=1403732#post1403732).<EDITed

It is worthy to be mentioned that the RGB space has been preliminary intended for analog devices, so nowadays it's an archaic way to produce an original material in the field of RGB which casually exists for rendering and filtering. Modern devices use the YUV space to produce video clips that often include the U and V ranged over 128 limits (so-called "out of gamut"). This means the problem is going to be typical for the majority of sources originated from the YUV space, not only mine.

At this moment I see two ways to throw this problem globally away:

I. If the appropriate AVSinpaint algorythm allows, to expand the analyze range to 255 for U and V to be calculated without clipping. Then the Alpha and ColorMap results have to be furhter processed and saved in the YUV colorspace (RGB processing and further conversion to YUV is not helpful of course). Here may be reasonable to process and save the U and V channels separately keeping luma the same for both.

II. If the above-mentioned algorythm doesn't allow and there is no other one that could be based on 255 range, to implement the independent U and V limitation technique (http://downloads.bbc.co.uk/rd/pubs/reports/1987-22.pdf). The idea intends to avoid clipping and to keep the out-of-range U and V by means of Uout/Uin and Vout/Vin ratios. There are three variants (algorythms) but the simpliest one might be enough for logo-removing.

AMSS0815, would you be so kind to modernize the AVSinpaint? You have the needed knowledge, practical experience and an alfa-beta tester in my person :o

Looking for the productive cooperation, thanx.
Have a nice day.
Good bye.

AMSS0815
26th April 2012, 09:45
OK, I just skimmed your response and I hope I understand you correctly.
but the AnalizeLogo operates the inner-restricted 128 range for Chroma -- the same way as a simple YUV->RGB convertion does (Ymax=255, Umax=128, Vmax=128) -- resulting all the U and V values out of 128 range to be clipped by the AnalizeLogo itself
Short response: No, and: a simple YUV->RGB conversion clips U and V values?? Maybe there is some shifting going on, like [0,255]-->[-128,127] or similar, but I cannot imagine that YUV wastes halve of its color range.

Anyway, up to programming bugs (which might always exist), AnalyzeLogo does not clip any color range. I suspect that your analysis refers to this part of the docs:
To prevent overflow of the sum of squares, all pixel values are reduced by 128 prior to computation. This means that all color channels that get analyzed (R,G,B, maybe A, or Y,U,V) get shifted [0,255]-->[-128,127]. The reason for this is that AnalyzeLogo sums up the squares of the channels pixel values until the end of the movie clip or until the 32-bit buffer runs full (a 32-bit integer for each pixel and each channel). This shift keeps the squares a bit smaller and allows more frames to be summed up before the buffer runs full. No information is lost here, no clipping occurs. And the shift is reversed before the color part of the logo is returned to the user.

I cannot test this right now, only at weekend, but maybe you can: Apply AnalyzeLogo+Deblend to YourClip.Grayscale.Levels(0,1,255,0,127). This clip should have all pixel values in permitted ranges, and I expect you to observe the same (glass-like) problem. On the other hand, if this works well (and you have thus solved your problem at least for a Grayscale'd version of your clip), you have a point and I will have a closer look at my code.

-- AMSS0815

shark000X
27th April 2012, 10:25
Hi AMSS0815,

Please review the edited part of my previous post. The main idea and all the rest remains unchanged, but due to 42hoursnonsleeping I just got confused with some results of another experiment, then showed the images that are ill-fitting there and gave them assumptions accordingly; so the images and their explanation are changed now to avoid the further confusions for you and other possible readers.
...a simple YUV->RGB conversion clips U and V values?? Maybe there is some shifting going on, like [0,255]-->[-128,127] or similar, but I cannot imagine that YUV wastes halve of its color range.
Well, my English played a wrong game with me again... To be more precise further, I start with some third-party explanations here (http://www.tek.com/zh/education/PDF/25W_15618_3.pdf):

Gamut – The range of colors allowed for a video signal. Valid color gamut is defined as all colors represented by all possible combinations of legal values of an R'G'B' signal. Signals in other formats may represent colors outside valid gamut, but still remain within their legal limits. These signals, when transcoded to the R'G'B' domain, will fall outside legal R'G'B' limits. This may lead to clipping, crosstalk, or other distortions.
Legal/illegal – A signal is legal if it stays within the gamut appropriate for the format in use. An illegal signal is one that is, at some time, outside the limits in one or more channels. A signal can be legal but still not be valid.
Valid signal – A video signal where all colors represented lie within the valid color gamut. A valid signal will remain legal when translated to R'G'B' or other formats. A valid signal is always legal, but a legal signal is not necessarily valid. Signals that are not valid will be processed without problems in their current format, but may encounter problems when translated to another format.

I don't mean that YUV wastes exactly a halve of its color range when going to RGB. When the non-valid colors go under convertion from YUV to RGB space, their U and V values aim to be shifted to the valid range but this can not be done totally if we use a simple YUV->RGB conversion: the colors are clipped out when U/V is still to remain below zero for PC-range or below 16 for TV-range and so on. To avoid this generally, the technique is proposed (see my previous post, variant II).
...all color channels that get analyzed (R,G,B, maybe A, or Y,U,V) get shifted [0,255]-->[-128,127]... This shift keeps the squares a bit smaller and allows more frames to be summed up before the buffer runs full. No information is lost here, no clipping occurs. And the shift is reversed before the color part of the logo is returned to the user.
It is good, but not enough if we use the same color-table for both spaces when computing and creating our alpha-color-map. Let us examine the color-tables (http://multimedia.cx/eggs/yuv-and-rgb/):
YUV>http://thumbnails77.imagebam.com/18716/1abeea187154778.jpg (http://www.imagebam.com/image/1abeea187154778) RGB>http://thumbnails75.imagebam.com/18716/53b530187157564.jpg (http://www.imagebam.com/image/53b530187157564)
YUV>http://thumbnails19.imagebam.com/18716/66562d187157561.jpg (http://www.imagebam.com/image/66562d187157561) RGB>http://thumbnails44.imagebam.com/18716/5f5109187157559.jpg (http://www.imagebam.com/image/5f5109187157559)
So, all the minimum and maximum YUV components do not generate similar to RGB results, they should have negative R and B values out of gamut. In fact, all zeros in the YUV colorspace result in a dull green rather than black, because we get a conventional approximation by clipping the negative values (Y=0,U=-128,V=-128) to 0.

As I understand, the AnalyzeLogo always produce a result stored in RGB space (at least, *.ebmp looks as RGB file). So, an assumption here is that the RGB table is used for both spaces when analyzing, storing and deblending. This is why, proceeding from the above, the AVSinpaint may operate the U and V restricted each to 0-128 range when having a non-valid YUV input.
Anyway, up to programming bugs (which might always exist)...
IMHO, the above can not be directly named as a bug. We just may say the deblending function of AVSinpaint is not better than the Delogo's one existing since 2001 -- it is able to help with RGB-originated sources or with the old analog PAL's YUV color space, but is not modern enough in most other cases.

...maybe you can: Apply AnalyzeLogo+Deblend to YourClip.Grayscale.Levels(0,1,255,0,127). This clip should have all pixel values in permitted ranges, and I expect you to observe the same (glass-like) problem. On the other hand, if this works well (and you have thus solved your problem at least for a Grayscale'd version of your clip), you have a point and I will have a closer look at my code.
Considering the conclusions above, the Greyscale function is a bad test for YUV space in this situation, because its inner computations are totally based on valid RGB range, as a result the output clip "should have all pixel values in permitted ranges" of RGB for sure.

After some other experiments I think the "32-bit integer for each pixel" may be also not a good idea for YV12 sources if it is accompanied by chroma interpolation errors. I just examined the differences (see images below, grey shows no change) that occur as a result of convertions, running the Subtract function:
FILM_a = inputMovie
FILM_b = FILM_a.ConvertToRGB24.ConvertToYV12
Subtract(FILM_a,FILM_b).Levels(127,1,129,0,255)
YV16>http://thumbnails77.imagebam.com/18725/40770f187249043.jpg (http://www.imagebam.com/image/40770f187249043) YUY2>http://thumbnails43.imagebam.com/18725/d111d9187249040.jpg (http://www.imagebam.com/image/d111d9187249040)
YV24>http://thumbnails43.imagebam.com/18725/17a924187249033.jpg (http://www.imagebam.com/image/17a924187249033) RGB_>http://thumbnails7.imagebam.com/18725/0ffeeb187249035.jpg (http://www.imagebam.com/image/0ffeeb187249035)
The more interpolation is involved, the less chance we have to invert the process of blending two images. The RGB convertion (maximum interpolation) seems to be most of all similar to the resulting glass-like effect (see B2 http://forum.doom9.org/showthread.php?p=1569517#post1569517). If a similar non-precise algorythm is used in the AVSinpaint, it's a bug for sure because affects the main functionality. And here I go with one more suggestion for a possible imrovement:

III. If the appropriate AVSinpaint algorythm allows, to avoid any chroma interpolations. In other case, to improve the chroma interpolation algorythm (some interesting ideas for precise interpolation and rounding control attached to this post).

I'm out of further ideas at this moment, so the "Eureka!" voiced at last :o

Thank you
Have a good inspiration

AMSS0815
28th April 2012, 22:56
Hi shark000X,

I'm a bit lost. You convinced me that conversions RGB<-->YUV cause clipping. Thanks for this enlightment, I didn't realize that although it is obvious to me now.

Yet I don't see the connection with AVSInpaint. There are no colorspace conversions happening inside AVSInpaint, which the following far-fetched exceptions (n=number of color channels):

InpaintLogo: Generation of one common structuring tensor out of n. In YUV, this is controlled by the ChromaWeight parameter, in RGB(A), it's just the mean value. (The structuring tensor decides the direction of inpainting, btw.)
AnalyzeLogo: Generation of a logo's alpha mask out of each channel's alpha masks. This is controlled with the *Weight parameters.

Both exceptions do not really convert a picture, but they compute a common quantity for all channels out of per-channel-quantities. They are convex combinations and hence cannot cause any clipping.

As I understand, the AnalyzeLogo always produce a result stored in RGB space (at least, *.ebmp looks as RGB file).No. AnalyzeLogo's output has the same colorspace as it's input (except the A in RGBA if you don't provide a separate mask), please check the colorspace table in the doc. AnalyzeLogo doesn't even know what an (ebmp-)file is.

After some other experiments I think the "32-bit integer for each pixel" may be also not a good idea for YV12 sources if it is accompanied by chroma interpolation errors.These 32-bit integers serve the sole purpose of summing up the squares of the raw (8-bit) color values of each channel and each pixel (one 32-bit integer per pixel per channel). There is no interpolation going on here, no round-off, no floating-point arithmetic. When one of the 32-bit intergers reaches its limit AnalyzeLogo procedes with the next step.

If you suspect that the generation of the common alpha mask out of the channels alpha masks is the problem, then please try this: Start with you YUV clip, use Grayscale, UtoY and VtoY to create three independent grayscaled clips which contain the Y, U and V of your original clip as Y values. This step should not cause any clipping and also no round-off errors (Grayscale just sets U and V to 0x80, *toY just copies values around). Up to this point, there is hence no distorsion of any kind (ok?). Then apply AnalyzeLogo to each of those. Because U=V=0x80 are constant on these clips, AnalyzeLogo will not take U- and V-channel data into account when computing alpha masks (see DeviationWeight parameter). Unless there is a bug (behaviour deviant to documentation), AnalyzeLogo will also not clip anything. It will produce round-offs: After all the 32-bit integers are summed up, further computation is done with floating-point arithmetic and the final alpha mask has to be represented by 8-bit unsigned integers. Yet I don't see a problem here. At this point, AnalyzeLogo will give you three alpha masks (one for Y, one for U, one for V), and three logo color parts of course. Try to deblend each of the channels (the three clips you created with *toY etc) separately.

If you do not suspect that the generation of the common alpha mask is the problem, let me assure you: There is nothing else going on inside AnalyzeLogo which might be tantamount to a colorspace conversion.

-- AMSS0815

Iron Yuppie
14th August 2012, 07:18
Hi, need some help with an opaque logo. I just put in some preliminary functions to test out the plugin and to see if my .bmp mask was correct, and all it seems to be doing is remove the lettering inside the red logo itself which makes the whole area red. Am I doing something wrong already or is this logo too solid (which I didn't figure would be correct considering that's what I understand the whole Inpaint process is about in the first place, right?)

Here is the quick test code:
InpaintFunc(last, mask="logo0.bmp",loc="164,0,-1624,-766", mode="both")

Here are the masks:
http://thumbnails56.imagebam.com/20588/9f43c7205876805.jpg (http://www.imagebam.com/image/9f43c7205876805) http://thumbnails60.imagebam.com/20588/7c69ba205876856.jpg (http://www.imagebam.com/image/7c69ba205876856)

And here's what it looks like afterwards:
http://thumbnails79.imagebam.com/20588/ac1975205876926.jpg (http://www.imagebam.com/image/ac1975205876926)

AMSS0815
15th August 2012, 13:36
Am I doing something wrong already or is this logo too solid (which I didn't figure would be correct considering that's what I understand the whole Inpaint process is about in the first place, right?) [...] Here are the masks:
http://thumbnails56.imagebam.com/20588/9f43c7205876805.jpg (http://www.imagebam.com/image/9f43c7205876805) http://thumbnails60.imagebam.com/20588/7c69ba205876856.jpg (http://www.imagebam.com/image/7c69ba205876856)
From what I can see in your first mask (what is the second one?) is that the logo area is white and red. The comments in InpaintFunc state
The mask is a black and white picture. Parties where the logo is are white, the others are black.
It is possible that the AVSInpaint function treats the red area in your mask as black and inpaints the red rectangle into the white text (as it is supposed to do with this mask). You will have to change your logo0.bmp such that there is a small (all-white) rectangle in the logo place and all black around.
-- AMSS0815

P.S.: Nevertheless, the logo is quite big, so when you get it going, I would expect ugly discontinuities in time.

BoobieNoobie
11th December 2015, 00:43
Is there a plugin for virtualdub too?

StainlessS
11th December 2015, 03:22
Is there a plugin for virtualdub too?
https://www.google.co.uk/?gfe_rd=cr&ei=KRd1VKG6N5HCVND3gGA&gws_rd=ssl#q=delogo+virtualdub

Above is one, there are probably a few more de-logo plugs for Vdub.

EDIT: Try a search on "logo' in Vdub forum.

AMSS0815
11th December 2015, 19:09
As far as I know, AVSInpaint was never ported to VirtualDub, so you can't use it there (directly).
Karel Suhajda's DeLogo filter for VirtualDub (http://declic-video-fx.com/Tutorials/ID/732/Clean-up-a-Video-with-VirtualDub-and-DeLogo.aspx#Files) (also mentioned in my original post) does essentially the same to semitransparent logos as AVSInpaint does, for opaque parts of a logo, however, it produces strong blurs. Nevertheless, for VirtualDub it's the most flexible logo removal tool I know off.

Yanak
11th September 2016, 20:25
Hello AMSS0815,

First i want to say thank you for this tool, used it many times in the past and it always done a great job.

Now I'm trying to use it with StaxRip x64 version and the dll does not work there as apparently it's not compatible with x64 needs.

Is it possible for you to update or port it to be compatible with x64 please ?

Thanks a lot in advance.

StainlessS
11th September 2016, 21:15
Amss0815, was last online December 2015, don't hold your breath waiting for an answer.

Edit: source is available, I think.
If you don't code, now is you opportunity to try.

Yanak
11th September 2016, 23:39
Yeah i know it have very slim chances, need him to see this and then modify the stuff, if possible.

Sadly I don't code no, will probably take ages to get into this and get a result if i try it myself, don't even know where to start :/

Well i tried to ask, will see if he see this one of those days, it is a nice tool and can be of good use for all of us in need of a x64 version too, not only for me i mean.

Thanks for the answer.

manolito
12th September 2016, 02:01
Now I'm trying to use it with StaxRip x64 version and the dll does not work there as apparently it's not compatible with x64 needs.

I believe that Stax is a little too much obsessed with being at the frontier of technology. Insisting on 64-bit only means excluding a plethora of useful plugins which are only available in 32-bit versions. And the speed benefit of 64-bit is quite small IMO.

After many tests I decided for myself to revert back to the 32-bit version of StaxRip. I did not like version 1.2.2.0 all that much so I went all the way back to version 1.1.9.0, and I never looked back...


Cheers
manolito

TheFluff
12th September 2016, 03:53
I believe that Stax is a little too much obsessed with being at the frontier of technology. Insisting on 64-bit only means excluding a plethora of useful plugins which are only available in 32-bit versions. And the speed benefit of 64-bit is quite small IMO.

I'm genuinely curious what useful plugins are only available in 32-bit in this day and age. This one is the first I've seen anyone ask for in a while (disregarding rean and his general craziness, but he's a nutjob so he doesn't count).

This particular plugin seems to be fairly clean C with no inline assembly, compiler intrinsics or other weirdness so chances are you can just recompile it with the Avisynth+ C-interface header and it'll work. It's a single source file, shouldn't take you more than maybe ten minutes to give it a try, so what are y'all waiting for?

Yanak
12th September 2016, 09:38
I won't argue about the utility or futility of a full x64 program, StaxRip x64 in the last versions brings some options very useful for me, making my life way easier when it comes to encode videos, that's all :)

@TheFluff,
you give me some hope man , searched briefly on the net for converting x86 stuff to x64 but i don't understand fully the part about inline assembly and other potential weirdness you speak about, seems like a good sign tho.

The source code is in the AVSInpaint.c file right ? I checked it a bit his content and saw "#include "AviSynth_C.h"" , if this the thing you speak about when you say " just recompile it with the Avisynth+ C-interface header" ?

If so and if i understood correctly changing this part to use Avisynth+ x64 equivalent file and recompile the dll may work ?

I don't know yet how to recompile this or even what program to use to do this but might spend some time searching the web in the next days to try figure this out and do it, hopefully i will not screw up everything, or maybe a good soul having more knowledge about this will have pity of me and do it, if like you said it takes 10 minutes to do someone may be kind enough to try it :)

Thanks a lot.

StainlessS
12th September 2016, 16:28
Yanak, I see AMSS0815 on-site right NOW, perhaps you will be lucky.

AMSS0815
12th September 2016, 17:09
Hi Yanak,

thanks for your posting. I'm still watching this thread, and from time to time I'm wondering if someone (still) uses this thing...

Unfortunatelly I can only be of little help: I'm not running Windows anymore, and the only Windows I can access right now is a 32bit-XP-installation.

Here is what I know:

The code of my plugin is completely architecture-independent, so it should compile cleanly on 64bit or whereever.
"My" code is in AVSInpaint.c; in order to compile it into a dll, you need at minimum the files AviSynth_C.h and AviSynth.lib. The former is -- apparently -- also architecture-independent, but I have a very bad feeling about the latter. Quickly searching the web, I just found this little tutorial (http://avisynth.nl/index.php/Avisynth_Plugin_Development_in_C), which doesn't mention architecture at all. If you can find this AviSynth.lib somewhere, and it is advertised for 64bit systems, that would be very helpfull. But I'm not sure if this file is architecture-dependent at all.
If you have these files, you need the compiler. I used gcc from mingw32 (http://www.mingw.org/) when I compiled this plugin, but I guess something like the 64bit-version of gcc is necessary. I'm not sure if I can run this on 32bit Windows and still compile 64bit binaries. Skimming the mingw-w64 site (https://mingw-w64.org) I wasn't able to find anything that looks like a gcc which runs on 32bit and produces 64bit binaries. Maybe someone can help? Since your OS is 64bit maybe it's easier for you to compile this than it is for me.
As soon as you find a Windows-64bit-version of gcc, you can just invoke the commands in AVSInpaint.Makefile.gcc.txt manually, i.e. gcc -fdiagnostics-show-location=once -funsigned-char -mthreads -Wextra -pedantic -Wall -Wdeclaration-after-statement -Wundef -Wpointer-arith -Wstrict-prototypes -Wredundant-decls -O2 -fomit-frame-pointer -malign-double -s -march=x86-64 -c -o AVSInpaint.obj AVSInpaint.c
gcc -fdiagnostics-show-location=once -funsigned-char -mthreads -Wextra -pedantic -Wall -Wdeclaration-after-statement -Wundef -Wpointer-arith -Wstrict-prototypes -Wredundant-decls -O2 -fomit-frame-pointer -malign-double -s -march=x86-64 -shared -o AVSInpaint.dll AVSInpaint.obj AviSynth.lib Mind the "-march=x86-64" , I hope that is sufficient for 64bit binaries.


With this (non-)knowledge, I downloaded a file called i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z (https://sourceforge.net/projects/mingw-w64/files/) somewhere near the mingw64-project and recompiled the dll with the commands from above. Surprisingly there were no errors (but many warnings .. gcc grew quite strict within the past years). As I can't test that file I just attach it here for you to test. I'm doubting it will work. If it does: Celebrate, otherwise please try to find some 64bit-on-64bit-version of mingw, look for a 64bit-version of the lib-file, then follow the recipe outlined above. There is no real coding involved, the hardest part is probably searching for the requisites.

I'm running linux on x86-64. Maybe I can get some linux-version of mingw for my cpu, then I might be able to compile it myself, but this probably won't happen this week.

If someone around here has any hint on compiling C-plugins for 64bit-AviSynth, please let us know

Yanak
12th September 2016, 20:11
Thanks a lot for the answer, really happy to see this, the dll can't be downloaded for now as it seems to need some approval, not sure how it works on the forum and how long it will take but I'm really impatient to test it.

I am on a limited network for the moment and can't really browse efficiently the net to look into all the procedure you explained, but if the .dll doesn't work I'll try to search for the needed files as soon as possible, maybe someone else passing by will know already how to find those too.

Thank you very much for taking the time to make it, really appreciate it, hope it will work so i can continue to enjoy your great work .

Thanks a lot.

Yanak
13th September 2016, 01:19
Tested quickly and doesn't seems to work , i cannot get it to load in StaxRip, getting a error message

Cannot load file 'C:/Users/Yanak/Desktop/AVSInpaint.dll'. Platform returned code 193:
%1 is not a valid Win32 application.

Using Megui it still loads on my avs and does the job perfectly to remove the logo while under x86 avisynth, even combined with InpaintFunc.avs this new dll still works nicely under x86 and still do an awesome job on removing the logo .

Almost 2am here so i will search tomorrow for AviSynth_C.h and AviSynth.lib in x64, the first one might be available at avisynth+ (http://avs-plus.net/), Avisynth.lib for x64 might take a bit more time, first searches were not conclusive.

I'll also give a try at your instruction to compile the dll directly under x64 and see how it goes too, will have to go step by step as this is not really something i'm used to :scared:

Thanks again for having took the time to do it and help on this.

StainlessS
13th September 2016, 15:32
Not sure but I think I remember some kind of problem with an app (Yasm I think) where it would not work compiled with
later versions of a compiler (maybe gcc), where the platform ID had changed from upper to lowercase, ie Platform
should be (I think) 'win32' not Win32', or win64 not Win64. Hope AMSS0815 sees this.

EDIT: See here:- http://forum.doom9.org/showthread.php?p=1742975#post1742975
EDIT: In above link seems to apply to win32 Visual Studio build, but perhaps applies to win64 gcc too (maybe worth further examination).

Yanak
14th September 2016, 01:07
I tried to compile by myself with mingw-w64 , after some tries i could do some tests but no luck for me.

In mingw-w64 install options i can select i686 or x86_64 :
http://img15.hostingpics.net/pics/34565720160914013125cr.jpg

Tried the second one and doing the obj file works but getting the dll gives me this message :


E:\test>gcc -fdiagnostics-show-location=once -funsigned-char -mthreads -Wextra -pedantic -Wall -Wdeclarati
n-after-statement -Wundef -Wpointer-arith -Wstrict-prototypes -Wredundant-decls -O2 -fomit-frame-pointer -ma
ign-double -s -march=x86-64 -shared -o AVSInpaint.dll AVSInpaint.obj AviSynth.lib
AVSInpaint.obj:AVSInpaint.c:(.text+0x6c): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0xdd): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xef): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x137): undefined reference to `__imp_avs_copy_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x149): undefined reference to `__imp_avs_add_function'
AVSInpaint.obj:AVSInpaint.c:(.text+0x885): undefined reference to `__imp_avs_new_c_filter'
AVSInpaint.obj:AVSInpaint.c:(.text+0x91c): undefined reference to `__imp_avs_set_to_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x934): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xa0c): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xba7): undefined reference to `__imp_avs_set_to_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xbd5): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x16a3): undefined reference to `__imp_avs_get_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x16c0): undefined reference to `__imp_avs_make_writable'
AVSInpaint.obj:AVSInpaint.c:(.text+0x1837): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x1aee): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x2a1a): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x399c): undefined reference to `__imp_avs_get_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x3c09): undefined reference to `__imp_avs_make_writable'
AVSInpaint.obj:AVSInpaint.c:(.text+0x3e59): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x4bf6): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x51bd): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x53b4): undefined reference to `__imp_avs_new_c_filter'
AVSInpaint.obj:AVSInpaint.c:(.text+0x557d): undefined reference to `__imp_avs_new_c_filter'
AVSInpaint.obj:AVSInpaint.c:(.text+0x55e7): undefined reference to `__imp_avs_take_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x55fe): undefined reference to `__imp_avs_get_video_info'
AVSInpaint.obj:AVSInpaint.c:(.text+0x586a): undefined reference to `__imp_avs_get_video_info'
AVSInpaint.obj:AVSInpaint.c:(.text+0x588e): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x5fc7): undefined reference to `__imp_avs_take_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x6017): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x6134): undefined reference to `avs_is_yuy'
AVSInpaint.obj:AVSInpaint.c:(.text+0x6dca): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x6e55): undefined reference to `__imp_avs_copy_value'
AVSInpaint.obj:AVSInpaint.c:(.text+0x7077): undefined reference to `avs_is_yuy'
AVSInpaint.obj:AVSInpaint.c:(.text+0x711f): undefined reference to `__imp_avs_set_to_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x7195): undefined reference to `__imp_avs_get_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x71d0): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x71e5): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x776a): undefined reference to `__imp_avs_get_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x77ca): undefined reference to `__imp_avs_make_writable'
AVSInpaint.obj:AVSInpaint.c:(.text+0x79b5): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x79cb): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x79e1): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x7bfe): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x7c14): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x7e6d): undefined reference to `__imp_avs_get_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x7e81): undefined reference to `__imp_avs_make_writable'
AVSInpaint.obj:AVSInpaint.c:(.text+0x7ed9): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x839e): undefined reference to `__imp_avs_take_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x83ff): undefined reference to `__imp_avs_get_video_info'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8442): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8492): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x84a0): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x85f1): undefined reference to `__imp_avs_take_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8695): undefined reference to `__imp_avs_get_video_info'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8762): undefined reference to `__imp_avs_new_c_filter'
AVSInpaint.obj:AVSInpaint.c:(.text+0x87b4): undefined reference to `__imp_avs_set_to_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x87e3): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8b60): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8b7e): undefined reference to `__imp_avs_set_cache_hints'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8b99): undefined reference to `__imp_avs_get_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8be9): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8bff): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8c0d): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8e22): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8e4c): undefined reference to `__imp_avs_set_cache_hints'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8e57): undefined reference to `__imp_avs_get_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8edf): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x8faa): undefined reference to `__imp_avs_get_video_info'
AVSInpaint.obj:AVSInpaint.c:(.text+0x93f4): undefined reference to `__imp_avs_get_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x9597): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x9c02): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0x9f85): undefined reference to `avs_is_yuy'
AVSInpaint.obj:AVSInpaint.c:(.text+0xa824): undefined reference to `avs_is_yuy'
AVSInpaint.obj:AVSInpaint.c:(.text+0xaa6a): undefined reference to `__imp_avs_take_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xaa8f): undefined reference to `__imp_avs_get_video_info'
AVSInpaint.obj:AVSInpaint.c:(.text+0xaaec): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xab0d): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0xab3a): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xab4c): undefined reference to `__imp_avs_release_video_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0xabff): undefined reference to `__imp_avs_take_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xac75): undefined reference to `__imp_avs_get_video_info'
AVSInpaint.obj:AVSInpaint.c:(.text+0xaf45): undefined reference to `__imp_avs_set_cache_hints'
AVSInpaint.obj:AVSInpaint.c:(.text+0xaf6c): undefined reference to `__imp_avs_get_frame'
AVSInpaint.obj:AVSInpaint.c:(.text+0xaf85): undefined reference to `avs_is_yuy'
AVSInpaint.obj:AVSInpaint.c:(.text+0xafe2): undefined reference to `avs_is_yuy'
AVSInpaint.obj:AVSInpaint.c:(.text+0xafec): undefined reference to `avs_is_yuy'
AVSInpaint.obj:AVSInpaint.c:(.text+0xb230): undefined reference to `__imp_avs_new_video_frame_a'
AVSInpaint.obj:AVSInpaint.c:(.text+0xb2df): undefined reference to `__imp_avs_new_c_filter'
AVSInpaint.obj:AVSInpaint.c:(.text+0xb359): undefined reference to `__imp_avs_set_to_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xb383): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xb3e8): undefined reference to `__imp_avs_release_clip'
AVSInpaint.obj:AVSInpaint.c:(.text+0xb428): undefined reference to `__imp_avs_get_frame'
collect2.exe: error: ld returned 1 exit status

E:\test>


Strangely enough when i tied the second command line given without the AviSynth.lib file at the end the message ended in being almost the same if not the exact same error message, i'll have to try this again tomorrow and compare both, using this command missing the AviSynth.lib at the end ( i tried without it, who knows :p ) :
gcc -fdiagnostics-show-location=once -funsigned-char -mthreads -Wextra -pedantic -Wall -Wdeclaration-after-statement -Wundef -Wpointer-arith -Wstrict-prototypes
-Wredundant-decls -O2 -fomit-frame-pointer -malign-double -s -march=x86-64 -shared -o AVSInpaint.dll AVSInpaint.obj

I removed the program and installed it again, selected the i686 setting and this time it worked and got the dll done, also gave a try to mingw in normal version , not the mingw-w64 one, and got the dll done there too, both working nicely under Megui and avisynth x86 but same error message on Staxrip x64 as before,

Will test and try more tomorrow but seems like mingw-w64 with x86_64 setting the file AviSynth.lib might be the problem, searched a while for x64 version of it and only thing i could find is this discussion :
http://forum.doom9.org/showthread.php?p=1389791#post1389791

Sadly i could not find the lib file in the link of the second post and got lost in JoshyD's explanation to be honest, all this is new to me.

Well, no luck for me but managed to compile my first dll and it's working in megui under x86, that's something already :p

StainlessS
14th September 2016, 05:46
Yanak, Avisynth standard installer installs Avisynth.lib in Extras folder when you tick the 'Select Extra Files' tick box.
I assume that AVS+ 64bit does the same (If that is what you are using).

JoshyD post from 2010 MT 64 bit, so unlikely to be of use for AVS+ 64 bit (I think, unless that is what you are using).

TheFluff
14th September 2016, 08:14
I assume that AVS+ 64bit does the same (If that is what you are using).

It doesn't, but I'm pretty sure you can generate an import .lib from avisynth.dll using some tools that come with Visual Studio. Don't think you need to compile Avisynth itself just for that.

some low effort googling gave this, make of it what you will: http://stackoverflow.com/questions/9946322/how-to-generate-an-import-library-lib-file-from-a-dll

Groucho2004
14th September 2016, 09:00
It doesn't, but I'm pretty sure you can generate an import .lib from avisynth.dll using some tools that come with Visual Studio. Don't think you need to compile Avisynth itself just for that.

some low effort googling gave this, make of it what you will: http://stackoverflow.com/questions/9946322/how-to-generate-an-import-library-lib-file-from-a-dll
I've already tried this. It doesn't work, see kemuri-_9's comment about function decoration here (http://forum.doom9.org/showthread.php?p=1461594#post1461594). His suggestion under "B" may be worth trying.

I also tried building JoshyD's 64 bit Avisynth just to get the 64 bit avisynth.lib but porting that to VC10 is more difficult than one would expect. I might give it another go later.

TheFluff
14th September 2016, 11:06
But this plugin is using the C API, not the C++ one. I don't think name mangling should be an issue in that case. (may be completely wrong here though)

I don't really understand why you're trying to build JoshyD's Avisynth instead of Avs+ either. What am I missing here?

Groucho2004
14th September 2016, 11:21
I don't really understand why you're trying to build JoshyD's Avisynth instead of Avs+ either. What am I missing here?I would have to download several GB of stuff to build it (VC2015, SDKs, ...).

TheFluff
14th September 2016, 11:31
Oh. My world is post-bandwidth-scarcity (well, to a point, above 50 GB or so it starts getting a bit tedious) so I didn't even consider that as a problem, guess I need to check my privilege huh

feisty2
14th September 2016, 12:27
2015 version is a MUST if you're using visual studio
Note that the latest c++ standard is c++14, and gonna be c++17 soon

Groucho2004
14th September 2016, 12:59
2015 version is a MUST if you're using visual studio
For a pro developer, probably. As a hobby coder, I can use whatever version and standard I want and need.

Groucho2004
14th September 2016, 13:00
Oh. My world is post-bandwidth-scarcity (well, to a point, above 50 GB or so it starts getting a bit tedious) so I didn't even consider that as a problem, guess I need to check my privilege huh
It's not that I can't download it, I don't want to.

feisty2
14th September 2016, 14:00
For a pro developer, probably. As a hobby coder, I can use whatever version and standard I want and need.

True, but don't you wanna try out stuff like type deduction and lambda and whatever? New things are cool

Yanak
17th September 2016, 11:00
Spent last days trying to figure this out and search for a .lib file compatible with x64 without luck.

I can confirm that the error messages i get here (http://forum.doom9.org/showpost.php?p=1780617&postcount=59) is exactly the same as when using the command line without the lib file using mingw-w64 to compile.

using those 2 commands, one having AviSynth.lib at the end and the other not, both end up in the same error message output.


gcc -fdiagnostics-show-location=once -funsigned-char -mthreads -Wextra -pedantic -Wall -Wdeclaration-after-statement -Wundef -Wpointer-arith -Wstrict-prototypes
-Wredundant-decls -O2 -fomit-frame-pointer -malign-double -s -march=x86-64 -shared -o AVSInpaint.dll AVSInpaint.obj AviSynth.lib

gcc -fdiagnostics-show-location=once -funsigned-char -mthreads -Wextra -pedantic -Wall -Wdeclaration-after-statement -Wundef -Wpointer-arith -Wstrict-prototypes
-Wredundant-decls -O2 -fomit-frame-pointer -malign-double -s -march=x86-64 -shared -o AVSInpaint.dll AVSInpaint.obj


Well nothing more i can do now, hopefully Groucho2004 or somebody else can end up with something.

Thanks

real.finder
10th November 2016, 12:18
don't know if this what you looking for, I have it in mpp mod source http://forum.doom9.org/showpost.php?p=1746479&postcount=235

Yanak
11th November 2016, 00:15
Hello,

I started to look a bit into this and it looks promising to make it work as i need. :)
I'm waiting for the attachment approval to see what it is and will try this tomorrow or this weekend after reading a bit more about all this.

Thanks a lo for the info if it works you will save the day man :)

real.finder
11th November 2016, 01:15
Hello,

I started to look a bit into this and it looks promising to make it work as i need. :)
I'm waiting for the attachment approval to see what it is and will try this tomorrow or this weekend after reading a bit more about all this.

Thanks a lo for the info if it works you will save the day man :)

you can see it from http://www.mediafire.com/download/3szchn46e0ul6cy/MP_Pipeline-0.18.1+src.rar

Yanak
11th November 2016, 14:50
Hi,

I grabbed the one already compiled from your previous link " MP_Pipeline+0.18.1.rar"

After a few trial and errors i got this working now,

That's working fine and doing the job nicely, and on the top of this it also allows me to bypass a problem i had using debug frameserver outputting only a x86 codec that refused to work with x64 programs, one stone two birds :D

Thanks a lot for the help man, your really saved the day, now i will be able to use again my favorite logo remover tools, a big thanks to you, this is an awesome day :)

Gser
24th June 2017, 18:50
Hi,

I grabbed the one already compiled from your previous link " MP_Pipeline+0.18.1.rar"

After a few trial and errors i got this working now,

That's working fine and doing the job nicely, and on the top of this it also allows me to bypass a problem i had using debug frameserver outputting only a x86 codec that refused to work with x64 programs, one stone two birds :D

Thanks a lot for the help man, your really saved the day, now i will be able to use again my favorite logo remover tools, a big thanks to you, this is an awesome day :)

Would you care to share it with us? :thanks:

Yanak
3rd July 2017, 10:34
Would you care to share it with us? :thanks:

Hi, and sorry for the late reply, i posted here how to add it into Staxrip that needs x64 full chain to work :

https://github.com/stax76/staxrip/issues/170#issuecomment-302266265

I don't have much time for now to explain more in details than there but if you have questions let me know, i'll try to answer them.