09-19-2005, 04:32 AM
|
Free Member
|
|
Join Date: Sep 2002
Location: Lahti, Finland
Posts: 1,652
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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.
|
Someday, 12:01 PM
|
|
Site Staff / Ad Manager
|
|
Join Date: Dec 2002
Posts: 42
Thanks: ∞
Thanked 42 Times in 42 Posts
|
|
|
09-19-2005, 04:56 AM
|
Free Member
|
|
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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.
|
09-19-2005, 10:16 AM
|
Free Member
|
|
Join Date: Jul 2003
Location: Valencia (España)
Posts: 741
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Thanx.
Caught it now.
|
09-19-2005, 03:27 PM
|
Free Member
|
|
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Switched to testversion "d2vReader_0.02b.exe" download is in the first thread - see changelog
|
09-19-2005, 03:39 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Madrid-Spain
Posts: 515
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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?
Salu2
Fabrice
|
09-19-2005, 04:14 PM
|
Free Member
|
|
Join Date: Oct 2003
Location: London, England (UK)
Posts: 1,035
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
__________________
Regards.
Michael.
|
09-19-2005, 05:38 PM
|
Free Member
|
|
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by fabrice
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?
Salu2
Fabrice
|
a) Do upgrade to DgIndex and its dgdecode.dll
b) try "MPEG2Dec3.dll" (as its mentioned in the error popup, maybe?)
|
09-19-2005, 10:43 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Madrid-Spain
Posts: 515
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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! )
|
09-19-2005, 11:09 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Madrid-Spain
Posts: 515
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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 :
Code:
MPEG2Dec3_mpeg2source("C:\DVDRip\mulan.d2v")
Lanczos4Resize(672,560,17,2,686,572)
Addborders(16,8,16,8)
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?!
|
09-19-2005, 11:41 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by fabrice
And sorry to insist, but in my case, I don't need fitcd anymore!
|
Neither do I Quote:
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?!
|
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
-kwag
|
09-19-2005, 11:48 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Madrid-Spain
Posts: 515
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by kwag
The correct way is what Andrej is doing.
You selected 704x, right
|
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
|
09-20-2005, 05:05 AM
|
Free Member
|
|
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
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.
Quote:
Originally Posted by Fabrice
Lanczos4Resize(672,560,17,2,686,572)
|
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("....")
Quote:
That's only that I thought that an overscan of 1 was always 8
|
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 )
|
09-20-2005, 05:17 AM
|
Free Member
|
|
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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.
|
09-21-2005, 12:32 AM
|
Free Member
|
|
Join Date: Mar 2003
Location: Madrid-Spain
Posts: 515
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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
Code:
YUV images only can be cropped by even number (left side)
So the problem doesn't come from your program...
Salu2
Fabrice
|
09-21-2005, 01:46 AM
|
Free Member
|
|
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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.
|
09-21-2005, 02:53 PM
|
Free Member
|
|
Join Date: Jul 2003
Location: Valencia (España)
Posts: 741
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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.
|
09-21-2005, 03:31 PM
|
Free Member
|
|
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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.
|
09-21-2005, 04:57 PM
|
Free Member
|
|
Join Date: Jul 2003
Location: Valencia (España)
Posts: 741
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Yes Inc, It's d2v file from DGIndex.
Here are the first lines:
Code:
DGIndexProjectFile08
15
28 D:\TARZAN XTRAS\VTS_01_1.VOB
28 D:\TARZAN XTRAS\VTS_02_1.VOB
28 D:\TARZAN XTRAS\VTS_03_1.VOB
28 D:\TARZAN XTRAS\VTS_04_1.VOB
28 D:\TARZAN XTRAS\VTS_05_1.VOB
28 D:\TARZAN XTRAS\VTS_06_1.VOB
28 D:\TARZAN XTRAS\VTS_07_1.VOB
28 D:\TARZAN XTRAS\VTS_08_1.VOB
28 D:\TARZAN XTRAS\VTS_09_1.VOB
28 D:\TARZAN XTRAS\VTS_10_1.VOB
28 D:\TARZAN XTRAS\VTS_11_1.VOB
28 D:\TARZAN XTRAS\VTS_12_1.VOB
28 D:\TARZAN XTRAS\VTS_13_1.VOB
28 D:\TARZAN XTRAS\VTS_14_1.VOB
28 D:\TARZAN XTRAS\VTS_15_1.VOB
Stream_Type=1
iDCT_Algorithm=5 (1:MMX 2:SSEMMX 3:FPU 4:REF 5:SSE2MMX)
YUVRGB_Scale=0 (0:TVScale 1:PCScale)
Luminance_Filter=0,0 (Gamma, Offset)
Clipping=0,0,0,0 (ClipLeft, ClipRight, ClipTop, ClipBottom)
Aspect_Ratio=4:3
Picture_Size=720x576
Field_Operation=0 (0:None 1:ForcedFILM 2:RawFrames)
Frame_Rate=25000
Location=0,0,14,132F
Hope it's of a help
|
09-21-2005, 05:35 PM
|
Free Member
|
|
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
|
|
Quote:
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 .
Just thought I'd let you know.
Cheers
__________________
Rui
|
09-22-2005, 02:33 AM
|
Free Member
|
|
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
@Doc
Quote:
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.
|
All times are GMT -5. The time now is 03:19 PM — vBulletin © Jelsoft Enterprises Ltd
|