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? |
Quote:
Quote:
Quote:
|
Quote:
Quote:
Quote:
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 :drunkard: Same goes to the rest of you guys. Thank you all very much. |
You're welcome. And I'd rather a fresh Pepsi :)
|
Quote:
|
Quote:
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. |
@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. :D |
@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? http://www.digitalfaq.com/archives/i...2005/08/28.jpg Thanks to ImageShack for Free Image Hosting |
@Zyphon
Quote:
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. |
Quote:
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:
For me I will stick with DGIndex. :D Quote:
Quote:
I love this tool and I wish you luck with the upgrades to it. :D |
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. :) http://www.digitalfaq.com/archives/i.../2004/05/7.gif |
Quote:
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. |
Quote:
If I would do an app that read d2v, I have to confess that I will hesitate to choose DGIndex as reference :cry: |
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:
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) |
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 |
Quote:
Quote:
Just off to test the new version. :D |
Another test with Alien3 and New DG Decode Playback
@Incredible
Hi Andrej, I just ripped (Again :D) 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. :lol: I shall post my results here. :D http://www.digitalfaq.com/archives/i...2005/08/29.jpg Thanks to ImageShack for Free Image Hosting |
Red Planet tests
@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? http://www.digitalfaq.com/archives/error.gif Thanks to ImageShack for Free Image Hosting |
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. http://www.digitalfaq.com/archives/i...2005/08/30.jpg 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. |
Quote:
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. :D 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. :D 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. :) |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.