Quote:
Originally posted by Bogalvator
1) "Never crop after RemoveDust" - not even if you resize afterwards to a mod 16 resolution? Does it really effect the codec compression performance?
[/B]
|
That was only reasonable guess of mine. A codec expert has really to answer this question. Or one has to run a lot of tests. On the other hand, I know that all high quality codecs divide the frame into a grid of small blocks and on these blocks the dct = discret cosine transform, a variant of the classical Fourier transform, is applied, to separate the important from the neglible things. That is the reason why too much compression makes a video visibly blocky. As far as I know the dct already appears in jpeg compression. Now RemoveDirt uses also such a grid of blocks and the output gets also blocky, though the blockiness is hardly visable, if pthreshold is not too high. On the other hand, the dct is more sensitve than the human eye, and it should react badly if the edge of a RemoveDirt block is right in the middle of a dct block. To avoid this, any edge of a RemoveDirt block should be the edge of a dct block. That is at least my guess. Now, if you crop on each side by a multiple of 8 that should be ok. But if you crop on the right hand side by 4 and on the left hand side by 12, then both grids are out of sync. The RemoveDirt edges are exactly in the middle of the dct blocks.
A further Remark about blockiness is in order. Because RemoveDirt bases the decision, whether to clean or not to clean, solely on the luma, there should not be any really visible blockiness as far as the luma is concerned. However, theoretically the chroma alone can cause blockiness, though this should be quite unlikely in a normal video. But obviously, as reported by Kintaro, more likely for anime videos. If chroma blockiness becomes a severe problem I can solve it at the expense of execution speed. Also the filter gets a lot more complicated to use, because then the chroma needs its own set of variables.
Quote:
Originally posted by Bogalvator
2) With that in mind - what about colour space conversions? I would like to use Pixiedust after you filter, should I ConvertToYUY2() before using your filter, or will it be safe to use it in YV12 first then convert afterwards?
[/B]
|
As far as quality is concerned, it should not matter much, but RemoveDirt is certainly faster in YV12 than YUY2, at least if you use the default mode=2.
Quote:
Originally posted by Bogalvator
Also, when I added removedust.dll to my plugins directory, both VirtualDub and TMPGEnc requested a file, msvcr70.dll, on startup (before loading AVS script). Naturally this message went away when I copied a version of it into both the VirtualDub and TMPGEnc directories, but do you know why this message came up. Anybody else have this problem?
[/B]
|
That is a problem with all my filters! To get a rather small dll, I use dynamic linking. In other words, various windows support function are not getting put into the dll. They are in msvcr70.dll and that is the reason why this dynamic link library is needed. Dynamic linking also saves memory during execution, because many other parts of the program can share msvcr70.dll, if they too use dynamic linking. But, if you know how windows wastes memory that shouldn't really matter. Dynamic linking may also be a tiny bit faster. There is one further problem: if your version of msvcr70.dll is not compatible (I really don't understand why this happens), you get execution problems. Perhaps, this is the reason for the crashes reported by Kintaro. With a staticly linked dll, you would not have these problems, because all the support routines are put into the dll. But if you use many staticly linked filters the same support routines may be linked many times into the executable. Nevertheless, I should perhaps release also a staticly linked version.