Quantcast Avisynth: Help with Lanczos Resize in FitCD ? - Page 2 - digitalFAQ.com Forums [Archives]
  #21  
08-14-2005, 01:58 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
Yes according to DGIndex it is Interlaced, I hope this doesn't mean I need to check the Interlaced box in the destination?

If my source was Progressive then could you round up to a higher number then?
__________________
Regards.

Michael.
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  
08-14-2005, 02:15 PM
Dialhot Dialhot is offline
Free Member
 
Join Date: May 2003
Posts: 10,463
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by Zyphon
Yes according to DGIndex it is Interlaced,
Michael, come on ! DGIndex find 99% of the PAL DVD as interlaced while 99% of them are progressive. I'm sure you know that.

Quote:
I hope this doesn't mean I need to check the Interlaced box in the destination?
Don't worry, Alien DVDs are progressive.

Quote:
If my source was Progressive then could you round up to a higher number then?
Of course you can but I tried and in your case, the crop is even worse with round to 4 than 2 (personally I generally always use round to 4 to not being surprised by some "exotic" filters but in the present situation, it's just too bad).
Reply With Quote
  #23  
08-14-2005, 02:55 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
Quote:
Originally Posted by Dialhot
Michael, come on ! DGIndex find 99% of the PAL DVD as interlaced while 99% of them are progressive. I'm sure you know that.
Yes it is true Phil DGIndex does find 99% of PAL DVD's as Interlaced which is why I don't trust it.

Quote:
Originally Posted by Dialhot
Don't worry, Alien DVDs are progressive.
I thought as much.

Quote:
Originally Posted by Dialhot
Of course you can but I tried and in your case, the crop is even worse with round to 4 than 2 (personally I generally always use round to 4 to not being surprised by some "exotic" filters but in the present situation, it's just too bad).
Thanks again Phil for your testing you have done with my source aspect ratio and thank you with your patients with all my questions.

If you lived next to me mate, I would treat you to a few beers for all the headaches I have given you today answering my questions Same goes to the rest of you guys. Thank you all very much.
__________________
Regards.

Michael.
Reply With Quote
  #24  
08-14-2005, 03:05 PM
Dialhot Dialhot is offline
Free Member
 
Join Date: May 2003
Posts: 10,463
Thanks: 0
Thanked 0 Times in 0 Posts
You're welcome. And I'd rather a fresh Pepsi
Reply With Quote
  #25  
08-14-2005, 03:47 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
Quote:
Originally Posted by Dialhot
You're welcome. And I'd rather a fresh Pepsi
Done.
__________________
Regards.

Michael.
Reply With Quote
  #26  
08-14-2005, 06:32 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 Phil
.... And if I'm not wrong, if your source is interlaced then 4 is the minimum also (to be confirmed).
Confirmed!

Progressive crop round 2
Interlaced crop round 4

@ Zyphon

Yup, seems the pixeldetection is still not perfect. Although cropping at mod2 would sometimes cause maybe 1 pixel border active Movienformation to be dropped, your source seems to be cropped 2 pixels too much.

I think I should overthink my Loop, as the pixeldata detection starts on the upperleft (at Topdetction for example) at ZERO, so my for/Next Loop is like the following:

For y = 0 to (SourceHeight-1)
For x = 0 to (SourceWidth-1)
.... parsing pixels at (x,y)
Next x
next y

But thats wrong as the Pixeldata should begin at ONE:

For y = 1 to SourceHeight
For x = 1 to SourceWidth
.... parsing pixels at (x,y)
Next x
next y

Also a check routine implementation where the code checks for a DgDecode.dll presence in the same folder should be integratet.
Reply With Quote
  #27  
08-15-2005, 03:17 AM
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
@incredible

HI Andrej,

I think you new tool is awesom! Also seeing as it the first release I think it is pretty good, excellent in fact.

I think a check for DGDecode.dll would be a good thing also at startup as it crashes if it is not in there.

Yes maybe the pixeldata For/Next loop probably needs a little more work.

What I will do is use DGIndex on a small section mid film and see how it goes just to double check.

Keep up the great work this tool rocks.

Also thank you for pointing out the round off points for both Progressive and Interlaced sources.
__________________
Regards.

Michael.
Reply With Quote
  #28  
08-15-2005, 04:07 AM
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
@Incredible

Hi Andrej,

I just did another quick test with Alien 4. I just selected a small section from within DGIndex and for my eyes it seemed to crop o.k.

I will re-rip Alien 3 and cut a section out and see if it crops that o.k

I am wondering if it was because it was the end credits that made it bleed over as the screenshot below looks fine to my eyes, maybe you can see different?


Thanks to ImageShack for Free Image Hosting
__________________
Regards.

Michael.
Reply With Quote
  #29  
08-15-2005, 04:10 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
@Zyphon
Quote:
LoadPlugin("F:\Program Files\DIKO\avisynth plugins\MPEG2Dec3.dll")
Uops, ... do you still use mpeg2dec3.dll ? I think this will get into conflict if you use DgIndex also as my Tool only accepts as Input DgIndex's d2v files.

Ill add the support of mpeg2dec3.dll if wanted, so u dont have to build 2 diff. project files.

You last Alien Screen does look perfect, means the little overhead of maybe 1 pixel down right is due the mod2 cropping.
BUT anyway your Image some postings more above does crop too much of the credits. Anyhow, credits in white letters do clearly mean RGB values above 200 for example, so that should have been recognised by my routine as the limiter is about 20-30 in RGB Values.

@Generally

Another Problem of not properly catching the borders in pixel-exact croppings could be that the parse Command Pixel(x,y) in purebasic (same as GetPixelV(x,y) in WIN API) results in a full RGB Value of 7Letters like 276489.
That Value is used to match the "limit" of beeing active pixels.

So better would be parsing EACH rgb channel out of the 7Letters Dezimal order.

Result = Pixel(x,y)
AverageRGB = (Red(result)+Green(result)+Blue(result)) / 3

This results in a 0-256 Value (more common for rgb parsing I think )

But as you already recognised the Border Checking NEEDS Time as the Win API GetPixelV(x,y) is slow. And if adding on each Pixel parser the 3 R/G/B descrambler .... ough this will take even more time.
Reply With Quote
  #30  
08-15-2005, 08:39 AM
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
Quote:
Originally Posted by incredible
@Zyphon
Quote:
LoadPlugin("F:\Program Files\DIKO\avisynth plugins\MPEG2Dec3.dll")
Uops, ... do you still use mpeg2dec3.dll ? I think this will get into conflict if you use DgIndex also as my Tool only accepts as Input DgIndex's d2v files.
Oh ignore this line Andrej I don't know how that crept in there.

I used DGIndex and to be honest I think your tool is better kept to keeping with DGIndex. I made my d2v projects with DGIndex.

Quote:
Originally Posted by incredible
Ill add the support of mpeg2dec3.dll if wanted, so u dont have to build 2 diff. project files.
It's up to you if you wanted to support both formats but maybe it would be better to offer the new DVD2AVI format seeing as it now being re-developed.

For me I will stick with DGIndex.

Quote:
Originally Posted by incredible
You last Alien Screen does look perfect, means the little overhead of maybe 1 pixel down right is due the mod2 cropping.
BUT anyway your Image some postings more above does crop too much of the credits. Anyhow, credits in white letters do clearly mean RGB values above 200 for example, so that should have been recognised by my routine as the limiter is about 20-30 in RGB Values.
I wont be home tonight Andrej, but when I get home tomorrow. I will rip Alien 3 again and select a section of it again without the credits and post a screenshot of the cropping and see if it does it ok.

Quote:
Originally Posted by incredible
@Generally

Another Problem of not properly catching the borders in pixel-exact croppings could be that the parse Command Pixel(x,y) in purebasic (same as GetPixelV(x,y) in WIN API) results in a full RGB Value of 7Letters like 276489.
That Value is used to match the "limit" of beeing active pixels.

So better would be parsing EACH rgb channel out of the 7Letters Dezimal order.

Result = Pixel(x,y)
AverageRGB = (Red(result)+Green(result)+Blue(result)) / 3

This results in a 0-256 Value (more common for rgb parsing I think )

But as you already recognised the Border Checking NEEDS Time as the Win API GetPixelV(x,y) is slow. And if adding on each Pixel parser the 3 R/G/B descrambler .... ough this will take even more time.
Thanks Inc, this will be very useful to perfect the cropping params.

I love this tool and I wish you luck with the upgrades to it.
__________________
Regards.

Michael.
Reply With Quote
  #31  
08-15-2005, 10:03 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
Hmmmm ....

I still have the Mencalc Sources on my Disk.
Maybe its a nice Idea to implement the resizer Core into the d2v Application at the left lower side. Means an autocropping would be performed where you manually can modify the box in its size posizion using a spin gadget so it fits to your perfect needs. After that these values will be send into the resizer core and an XXXresize(xx,yy,a,b,xxx,yyyy) Avisynth Script will result as the final gift.


Reply With Quote
  #32  
08-15-2005, 11:14 AM
Prodater64 Prodater64 is offline
Free Member
 
Join Date: Mar 2003
Location: Palma de Mallorca - España
Posts: 2,925
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by Zyphon
Quote:
Originally Posted by incredible
Ill add the support of mpeg2dec3.dll if wanted, so u dont have to build 2 diff. project files.
It's up to you if you wanted to support both formats but maybe it would be better to offer the new DVD2AVI format seeing as it now being re-developed.

For me I will stick with DGIndex.
@Incredible
I still do use DVD2AVIdg as it is more compatible with Calcumatic and MovieStacker. Maybe there are more people like me.
I think it would be better to add support for those versions.
I think also there are people that uses 1.76.
Reply With Quote
  #33  
08-15-2005, 11:22 AM
Dialhot Dialhot is offline
Free Member
 
Join Date: May 2003
Posts: 10,463
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by Prodater64
@Incredible
I still do use DVD2AVIdg as it is more compatible with Calcumatic and MovieStacker. Maybe there are more people like me.
I think it would be better to add support for those versions.
I think also there are people that uses 1.76.
I personally use DGIndex but it seems that d2v format changed a lot, and a lot of times in it. You can find a D2V_format_v10.txt and I have all text files since v6 on my disc !
If I would do an app that read d2v, I have to confess that I will hesitate to choose DGIndex as reference
Reply With Quote
  #34  
08-15-2005, 11:43 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
imho there are 2 diff d2v syntaxes incompatible by each other on air now.

the old dvd2avi one and the dgindex one. Can someone confirm that?

In that Appl. a simple openfile().readstring() parser does its work where the first string in the d2v is parsed and compared to a determined string in the app which includes the correct DgIndex's d2v first string. So There is NO problem supporting diff. d2v syntax versions except there's one rule:

The allocated dll for that specific d2v format has to be in the same folder as the appl. and the API of the dll HAS TO BE THE SAME.

Both mpeg2dec3.dll and DgDecode.dll for example do use as API:

openMPEG2Source()
getFrame()
getRGBFrame()
closeVideo()

... where getFrame() in my case not needed as I load the Frames out of the d2v frameserver into a previewing appl. where the Pic will be displayed on a PCscreen directly using RGB.

According to Calcumatic ... maybe Karl will update his d2v Parser sometime so d2v files out of DgIndex will be supported.

Quote:
Originally Posted by Prodater64
I still do use ......... MovieStacker
Are you aware that Moviestacker gots a bug related to 528/544 sizes no matter if in- or output? GripCrop also does as "they" simply use a 3/4 of 128/117 PAR to obtain the 528/544 PAR which isnt correct.

I was able to update the c++ core within GripFit_YV12 to proper 528/544 values but I have to figure out how to compile it using DevC++.

The Proof on GripFits Source:

Code:
double GripCrop::DeterminePAR(GripCrop::STANDARD standard, const Dimensions& dim)

{

	int w = dim.width.AsInt(), h = dim.height;



	if(NTSC == standard)

	{

		if(720 == w && 480 == h) // DVD

			return 72.0 / 79.0;

		else if(704 == w && 480 == h) // KVCDx2

			return 72.0 / 79.0; // FIXME?

		else if(544 == w && 480 == h) // KVCDx3

			return (72.0 / 79.0) / (3.0 / 4.0);     // <------ !!!!!

		else if(528 == w && 480 == h) // KVCDx3

			return (72.0 / 79.0) / (3.0 / 4.0);    //  <------ !!!!!

		else if(480 == w && 480 == h) // SVCD

			return 108.0 / 79.0;

		else if(352 == w && 480 == h) // 1/2 D1

			return 144.0 / 79.0;

		else if(352 == w && 240 == h) // VCD

			return 72.0 / 79.0;

	} else if(PAL == standard)

	{

		if(720 == w && 576 == h) // DVD

			return 128.0 / 117.0;

		else if(704 == w && 576 == h) // KVCDx2

			return 128.0 / 117.0; // FIXME?

		else if(544 == w && 576 == h) // KVCDx3

			return (128.0 / 117.0) / 0.75;      //  <------ !!!!!

		else if(528 == w && 576 == h) // KVCDx3

			return (128.0 / 117.0) / 0.75;      //  <------ !!!!!

		else if(480 == w && 576 == h) // SVCD

			return 128.0 / 78.0;

		else if(352 == w && 576 == h) // 1/2 D1

			return 256.0 / 117.0;

		else if(352 == w && 288 == h) // VCD

			return 128.0 / 117.0;

	}



	// Unknown



	return 0.0;

}
Reply With Quote
  #35  
08-15-2005, 02:32 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
Well first this Code was purposed to be part of a new appl. but as it seems that its also useful as standalone, so I made it to version 0.12b.

Now dgdecode.dll AND MPEG2Dec3.dll are supported as d2v decoding libs, means DgIndex and DVD2AVI d2v files are supported.
If the specific dll is not found by the appl. even if you've copied it into the applications folder then check its name and the type of typing case as maybe the parser could be case sensitive.
If for DVD2AVI decoding a different dll name is common, please let me know.

If there are d2v files which use a different identifier in their first text line also here: Let me know.

Actually the appl. recognises as following when parsing the first textline out of an ingoing d2v:

"DGIndexProjectFile..." (only first 18 Letters will be parsed) means : dgdecode.dll will be used

"DVD2AVIProjectFile" means MPEG2Dec3.dll will be used
Reply With Quote
  #36  
08-16-2005, 10:32 AM
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
Quote:
Originally Posted by incredible
Well first this Code was purposed to be part of a new appl. but as it seems that its also useful as standalone, so I made it to version 0.12b.

Now dgdecode.dll AND MPEG2Dec3.dll are supported as d2v decoding libs, means DgIndex and DVD2AVI d2v files are supported.
If the specific dll is not found by the appl. even if you've copied it into the applications folder then check its name and the type of typing case as maybe the parser could be case sensitive.
If for DVD2AVI decoding a different dll name is common, please let me know.

If there are d2v files which use a different identifier in their first text line also here: Let me know.

Actually the appl. recognises as following when parsing the first textline out of an ingoing d2v:

"DGIndexProjectFile..." (only first 18 Letters will be parsed) means : dgdecode.dll will be used

"DVD2AVIProjectFile" means MPEG2Dec3.dll will be used
Thanks for the update Andrej, I suppose it is better to support both formats of the d2v files.

Quote:
Originally Posted by incredible
Hmmmm ....

I still have the Mencalc Sources on my Disk.
Maybe its a nice Idea to implement the resizer Core into the d2v Application at the left lower side. Means an autocropping would be performed where you manually can modify the box in its size posizion using a spin gadget so it fits to your perfect needs. After that these values will be send into the resizer core and an XXXresize(xx,yy,a,b,xxx,yyyy) Avisynth Script will result as the final gift.
This sounds like a fantastic idea the best of both Worlds. It would be nice if this could be implemented.

Just off to test the new version.
__________________
Regards.

Michael.
Reply With Quote
  #37  
08-16-2005, 11:01 AM
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
@Incredible

Hi Andrej,

I just ripped (Again ) Alien 3 to my HDD to test out the new version of your tool.

To keep it consistent with the test for Alien 4 I used DGIndex.

I used DGIndex to use a small section of the filma and made a d2v project.

The screenshot below clearly shows that the cropping at the bottom is still slightly incorrect.

If you look under the green crop line at the bottom you can still see Ripley's body beneath it.

So maybe this is cropping one or two pixels to many in this case.

I am going to rip Red Planet and try and see how this crops, as I like Karl usually use this movie for my benmarking and I have done so many tests using this movie.

I shall post my results here.



Thanks to ImageShack for Free Image Hosting
__________________
Regards.

Michael.
Reply With Quote
  #38  
08-16-2005, 11:22 AM
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
@Incredible

Hi Andrej,

Below is a screenshot of Red Planet and the cropping looks perfect!

Maybe there is something strange going on in Alien 3 that makes the crop area incorrect.

Would you like me to upload a small sample of a VOB from Alien 3 to test on your machine?

EDIT: I have just now noticed that the crop on the top line looks a bit off by a pixel if you take a good look.

Maybe we could start a new topic regarding this tool and put all my findings in a bug list report post?


Thanks to ImageShack for Free Image Hosting
__________________
Regards.

Michael.
Reply With Quote
  #39  
08-16-2005, 11:31 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
Thanks for the Info Michael.

I do think the WIN API command GetPixel() for getting Pixel Values isn't that confiable! The For/Next Loop in my code ist correct, also that the counter starts from 1 to the picture's width or height value and not starting from zero.

I got the returned rgb data from dgdecode.dll at a given memory adress, so it would be much more effective and FASTER using a peek() routine directly on that memory adress where the origin rgb data is stored instead of scanning rgb values in a created image generated out of that same origin rgb data.

EDIT: Just saw your RedPlanet crop scan!

I do assume that inside the Movie there is a scene where the right sided Imagearea gots more overhead then the screen where the autodetection ends! I had that same issue on KillBill Vol1. And if also the Mod2 factor will be applied then this clearly results in the state on your pic above. Means the engine keeps watching the Movie and "keeps" the maximum Active Area of the each parsed frame in mind, finally it chooses the maximal value of the image area within the movie that occurs and uses the mod2 on it.

Ill add also an "Crop actual frame" Button where you can determine the auto cropping on that actual frame which is choosen via a slider tracking bar. I already have that routine on my hd.

EDIT2:

I did examine your 720x576 pic using Photoshop and the cropping on top and bottom is 2px too much, means if the orig value would have been used (without round to mod2) it ALSO would even been in mod2 state!
Thats why I'll enter the routine again. Thanks for your pics!! Keep on testing Michael.


Thanks to ImageShack for Free Image Hosting

BTW. I do recognise a "blending" on Ripleys arm! I dont hope they treated the source like SITC ones where also dynamic phase shifts have been added.
Reply With Quote
  #40  
08-16-2005, 02:08 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
Quote:
Originally Posted by incredible
Thanks for your pics!! Keep on testing Michael.
Your welcome Andrej only happy to offer some input on my testing.

To be honest I don't think these couple of pixels is a problem considering it is cropped in Mod2, as long as it is as we say over here "as near as dammit" then I think it should be fine.

The slider bar idea seems like a very good idea for fine tuning the crop boundaries.

I wonder if karl could do a quick test with the NTSC version of Red Planet and see how hes cropping comes out. Maybe the same? Who knows.

I like the picture you posted showing the crop marks and the overclipped pixels.

If there is any else I can do for you just ask.

I think this tool is excellent and it make cropping such an easy task and takes the headache out of it, so a big thank you for this.

Btw if you did want a section of that VOB please let me know.
__________________
Regards.

Michael.
Reply With Quote
Reply




Similar Threads
Thread Thread Starter Forum Replies Last Post
Avisynth: Lanczos Vs Spline resizers supermule Avisynth Scripting 10 04-26-2007 03:26 AM
Avisynth: Gaussian Vs Lanczos4 Vs Lanczos Resize supermule Avisynth Scripting 3 10-13-2005 10:21 AM
Avisynth: Bilinear Vs Bicubic Vs Lanczos? Anonymous Avisynth Scripting 4 08-18-2003 08:17 AM
Avisynth: How come not many people use Lanczos resizing? audi2honda Avisynth Scripting 3 06-16-2003 02:16 PM
KVCD: Help with resize/borders in fitcd musicthebee Video Encoding and Conversion 7 05-30-2002 07:50 PM

Thread Tools



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