My guess is that the detection threshold means the sensitivity when the program determines the borders. A low value means that the line must be darker to be considered as one that belongs to borders. If you set it too high, the automatic cropping will start cropping the active film pixel area as well.

Well everybody can choose for himself if a given PAR error is too much or not, so I'll keep the Error just mentioned as a value in the Info-Box.

Boulder is right. The Threshold is based on Luma detection lowerlevels means more sensitive, higher values means less sensitive.
Luma will be determinet via Y = (R * .299 + G * .587 + B * .114) as this resluts in a Y 0-255 range.

Sometimes a resulted autocropping does result in an active px area including black areas from the upper left. That means that in the black borders there where some px above the threshold. In such a case do use a diff. sampe count as then also diff. samples will be choosen.

Thanx.
Caught it now.

Switched to testversion "d2vReader_0.02b.exe" download is in the first thread - see changelog

Hi,

I'm sorry but even after copying mpeg2dec3.dll to c:\archivos de programa\avisynth 2.5\plugins, it doesn't work (just renamed the mpeg2dec3dg.dll).
What I am doing wrong? :oops:

Salu2
Fabrice

Hi Andrej,

Thanks for updating your excellent cropping tool and for including the extra features you promised, I know this tool is in very very beta stage but for me it still looks awesome and is the perfect tool to compliment resizing alongside FitCD.

So a BIG thank you buddy for releasing this we all appreciate it. :D

:bowdown: :bowdown: :bowdown: :bowdown:

a) Do upgrade to DgIndex and its dgdecode.dll

b) try "MPEG2Dec3.dll" (as its mentioned in the error popup, maybe?)

Hi Inc,

It worked copying dgdecode.dll to plugins directory.

Thanks!

It's test time ;-)

Salu2
Fabrice

EDIT: one typo: instead of safe, you should put save (I was trying to figure why the script is safe! :-) )

Hi again,

First pb. With a movie, it perfectly detect the border beginning at pixel 17, but even after selecting crop Mod 2, the generated crop is :
which is not even. Same if I change the crop value of height

And sorry to insist, but in my case, I don't need fitcd anymore! :-) (ok: just to check the result of you wonderfull app).

Salu2
Fabrice

EDIT: another strange thing: fitcd overscan 2 is like overscan 1 in your app, 3 like 2, etc... and overscan 0 give me negative calue for addborder?!

Neither do I :) That's because FitCD is screwed up (I'm almost positive of that) :!:
The correct way is what Andrej is doing.
You selected 704x, right :?:
FitCD doesn't take into consideration the target you have selected, and doesn't compensate.
Andrej can explain that in more details :cool:

-kwag

Yes: I almost always convert to 704x576.

That's only that I thought that an overscan of 1 was always 8 pixels. But now that I think about it, there is already a bigger implicit overscan in a 720x576 movie than in 704x576, so it's logical.

Thanks,
Fabrice

Thanks for the flowers but ....
DONT TRUST THE CALCS OF THAT APPL. IN THIS STILL EXPERIMENTAL STAGE! Do still use FitCD until the d2vreaders calcs are proofed to be totally correct.
;)


Im aware of that and this "cosmetic" should be fixed.
In practise that wont hurt as Avisynths internal Resize Commands do accept in their Params odd values, even floats! The Routine within avisynth "seems" to compensate it. It was very often the case that also FitCD does output a ResizeLine using odd values.

Ill also do switch the cropping totally to mod2 forced cause even if source is interlaced, the Cropping/Resizing will be done in a 'bobbed' state, means filtering on a temporary 'progressived' source.

The negative Addborders Command output is very weired and has to be fixed. Maybe the last beta 0.02b wont have that bug? Not shure.

The issue with the avisynths plugins path will also be solved as in the registry there is a pointer to where the actual plugins folder of avisynth is present on your system.

Do NEVER use both dlls in the avisynths plugins folder! dgdecode.dll or MPEG2Dec3.dll, .. you have to choose.
You 'could' use both if adding the dlls name before the command followed by an underscore like:

dgdecode_mpeg2source("....")
or
mpeg2dec3_mpeg2source("....")

You're right. the Overscan is setted regarding to the target final Size.
So '1' should result in ( 8+....+8 ) and '2' in ( 16+....+16 )

;)

Im thinking about rewriting the core of the resizer totally, as it makes NO sense for example when 704x576(480) sources should end up in 720x576(480) if then the final 720 area is filled up with the full sources width image information.
The proper conversion from 704x576(480) to 720x576(480) will be done by simple padding, means 704 --> 8+704+8 --> = 720.
Thats ITU conform and will keep the image to be in the same state as before when watching on TV.
720 equals 53,333µs
704 equals 52,248µs
both use 13.5Mhz for playback. And cause of the same playback the PAR is the same, means padding is the way to nothing else makes sense! As IF you would force 704x576 to fit in full 720x576 that would mean you would have to size up vertically by a few pixels to keep the correct PAR, this results in a blurry image while anyway the pix above 704(702) won't be shown on TV!

Getting from 720 to 544 would end up in resizing from 720 to 540 and padding to 544 = only resizing of the width is needed and its TOTALLY ITU conform. But if ResizeMOD is set higher that 4 then the resizer would force to resize the width to full 544 (mod 8/16) but also resizes and crops the height to compensate the mod8/16 resizing to 544.

Hi,

Just downloaded 2b version, and I don't see the negative value.

On the other hand, I know why I had problem with 17 value: I always separate crop from resizing (to apply filters after cropping, but before resizing).
And the following command:
give me an error in virtualdub So the problem doesn't come from your program... :oops:

Salu2
Fabrice

The diff. between a cropping "within" the resizer command like Bicubicresize(xxx,yyy,b,c,x,y,xxx,yyy) and a separate crop is the in the Resizer command Avisynth compesates the "odd" value.
In the Resizers internal cropping parameters there are even floats! allowed.

Hi Inc,
don't think it's important...
I loaded a .d2v file that was identified as 16:9, when it is 4:3

I don't know if this info is taken from d2v, but GDIndex identified the film as 4:3

No problem with identifying borders (there wasn't), nor resizing (I ignored it claimed to be 16:9, and didn't check anamorph to noanamorph) and output avs was OK.

If you keep the sources AR as it was when incoming, then NO vertical squeeze factor will be applied, thats why the result is ok.

Whats that type of dv2 source? Its resulted out of DGindex?
If yes, please do post in here the first very informative Lines of that d2v you used. I mean all the lines till that crypted numerical count starts.

Yes Inc, It's d2v file from DGIndex.

Here are the first lines:
Hope it's of a help

Not that I think this has anything to do with it but the DG project file is rather old.
It is maybe the one that came with the original DVD2AVIdg 1.3.0.
I have seen this happen even with recent DGMPGDec 1.4.x releases with one of my movies.
Unfortunately I can't remember which one :roll:.
Just thought I'd let you know.
Cheers

@Doc

I think thats clear ;)
So I have to look for which "exact" string the appl. is looking for.

As you anyway do use DgIndex, do upgrade to at least DgIndex/DgDecode 1.40.
It could be that neuron did made a significant change related to the aspect ratio line since DgIndexProjectFile08.
1.40 uses "DgIndexProjectFile10“ where 1.41 uses "DgIndexProjectFile11" for instance.

But anyhow, IF the first line does contain the chars "DgIndexProjectFile" in its string then the appl. recognises the project as DgIndex one, means it searches the whole lines in the projectfile till it reaches the line "Aspect Ratio=..." and then it parses the Value. So it could be that there has been made a change from "Aspect_Ratio" to "AspectRatio" or whatever.
Im here now in the Job so I cant look into the string parsing part of my code. Will be done this evening.