Quantcast Paranoia: Bug Reports - Page 2 - digitalFAQ.com Forums [Archives]
  #21  
09-19-2005, 04:32 AM
Boulder Boulder is offline
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.
Reply With Quote
Someday, 12:01 PM
admin's Avatar
Site Staff / Ad Manager
 
Join Date: Dec 2002
Posts: 42
Thanks: ∞
Thanked 42 Times in 42 Posts
  #22  
09-19-2005, 04:56 AM
incredible incredible is offline
Free Member
 
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via ICQ to incredible
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.
Reply With Quote
  #23  
09-19-2005, 10:16 AM
digitall.doc digitall.doc is offline
Free Member
 
Join Date: Jul 2003
Location: Valencia (España)
Posts: 741
Thanks: 0
Thanked 0 Times in 0 Posts
Thanx.
Caught it now.
Reply With Quote
  #24  
09-19-2005, 03:27 PM
incredible incredible is offline
Free Member
 
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via ICQ to incredible
Switched to testversion "d2vReader_0.02b.exe" download is in the first thread - see changelog
Reply With Quote
  #25  
09-19-2005, 03:39 PM
fabrice fabrice is offline
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
Reply With Quote
  #26  
09-19-2005, 04:14 PM
Zyphon Zyphon is offline
Free Member
 
Join Date: Oct 2003
Location: London, England (UK)
Posts: 1,035
Thanks: 0
Thanked 0 Times in 0 Posts
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.

__________________
Regards.

Michael.
Reply With Quote
  #27  
09-19-2005, 05:38 PM
incredible incredible is offline
Free Member
 
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via ICQ to incredible
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?)
Reply With Quote
  #28  
09-19-2005, 10:43 PM
fabrice fabrice is offline
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! )
Reply With Quote
  #29  
09-19-2005, 11:09 PM
fabrice fabrice is offline
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?!
Reply With Quote
  #30  
09-19-2005, 11:41 PM
kwag kwag is offline
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
Reply With Quote
  #31  
09-19-2005, 11:48 PM
fabrice fabrice is offline
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
Reply With Quote
  #32  
09-20-2005, 05:05 AM
incredible incredible is offline
Free Member
 
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via ICQ to incredible
Quote:
Neither do I
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 )

Reply With Quote
  #33  
09-20-2005, 05:17 AM
incredible incredible is offline
Free Member
 
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via ICQ to incredible
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.
Reply With Quote
  #34  
09-21-2005, 12:32 AM
fabrice fabrice is offline
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:
Code:
crop(17,2,686,572)
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
Reply With Quote
  #35  
09-21-2005, 01:46 AM
incredible incredible is offline
Free Member
 
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via ICQ to incredible
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.
Reply With Quote
  #36  
09-21-2005, 02:53 PM
digitall.doc digitall.doc is offline
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.
Reply With Quote
  #37  
09-21-2005, 03:31 PM
incredible incredible is offline
Free Member
 
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via ICQ to incredible
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.
Reply With Quote
  #38  
09-21-2005, 04:57 PM
digitall.doc digitall.doc is offline
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
Reply With Quote
  #39  
09-21-2005, 05:35 PM
rds_correia rds_correia is offline
Free Member
 
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
Quote:
DGIndexProjectFile08
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
Reply With Quote
  #40  
09-22-2005, 02:33 AM
incredible incredible is offline
Free Member
 
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via ICQ to incredible
@Doc

Quote:
Aspect_Ratio=4:3
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.
Reply With Quote
Reply




Similar Threads
Thread Thread Starter Forum Replies Last Post
WeatherWatcher desktop weather reports black prince Computers 0 02-08-2006 06:10 PM
MencodeME Bug reports Thread incredible Video Encoding and Conversion 36 06-28-2004 05:20 PM
MovieStacker Bug Reports - (MStacker 2.1.0) muaddib Video Encoding and Conversion 18 04-19-2004 06:48 PM
Bitrates: CQMatic Version 1.2.03 Reports kwag Video Encoding and Conversion 24 11-16-2003 05:33 AM
Bitrates: CQMatic Bug Reports kwag Video Encoding and Conversion 251 09-29-2003 01:00 PM

Thread Tools



 
All times are GMT -5. The time now is 03:19 PM  —  vBulletin © Jelsoft Enterprises Ltd