Paranoia: Bug reports
 

Please do report bugs or issues in here.
Thanks

:ole:
:ole:
:ole:

:mrgreen:

Thanks Andrej :D :bowdown:

I'm the second!
 

@Andrej

THX mate! :D I already got it!

Cya!

Please do first keep it in here so the very first known bugs will be fixed before it gets public for the ouside. Thanks :)

Well done Inc.
:D

Looking very good Andrej :D.
You deserve a :drink: :lol:.
This baby will surely become a must in my PEN disk.
Sorry but I've got too many things in hands, so no time to test it yet.
Nevertheless it's already in my HDD ready for action :P.
Cheers buddy

LOL
I said I wasn't going to test it right away, but I couldn't help it and I tried it just once :lol:.
I went to the Source>Open D2V Source, browsed for my D2V project, clicked the name of the file xxxx.d2v and pushed the Open button.
But then I received a message saying
And then the tool did nothing!
Does it mean it is looking for the dgdecode.dll only in that specific path?
You see, all my videotools are installed in "c:\video\...".
Cheers buddy

PS: BTW the window that popped up that message showed "shure" instead of "sure", but that's obviously because of it's youth :D.

It's confirmed.
I just copied all my c:\video\avs255 to c:\program files\avisynth 2.5 and now your tool works.
So it seems it's path dependent, which is not so bad after all.
As soon as I load the script on it my movie starts running.
At that time if I press "Esc" to exit the tool, it doesn't respond and keeps playing the movie.
Actually I needed to push the pause button (at the bottom) to be able to close the tool.
I'll keep bugging you with my experiences :D.
BTW, you really have to come up with a name for this baby and choose a license for distribution ;-).
Cheers buddy :)

Yes, it looks for your windows Program path and there for /avisynth 2.5/plugins.

If that not works, put a copy of dgdecode.dll or MPEG2Dec3.dll in the applications folder.

also its forced that when playing no windowactions will be permitted except teh "pause" button, that makes it much more easy to keep out actions via gadgets when the movie is running.

Woooow :!: . GrEaT pal :!:

I just tested it. It's... incredible :wink:

Some ideas (sure no need to consider even a single one, but just in case you find them useful) after opening it once:
- I find it would be nice an exit button in main window (yes, it's in the menu, but... I advised I was not going to be very helpful) and later in avisynth script (if you don't preview or save, you need to exit) and in preview avs.
- In the info screen, you could highlight the PAR error (bold letters, or as in FitCD: blue OK, yellow hmmm, red: change settings)
- It would be nice to have more avisynth commands to use, and something like a preset, with those commands we use more often

A doubt: what does it mean Pix Detection threshold?

Good Inc, really good. Congratulation

I just tested several runs, and all I can say is
:arrow: :jawdrop:
The cropping is just perfect :D
Congrats Andrej :!:

-kwag

Well an exit via menue-option and the upper right systemwindow-close button imho is enough as if I would add more buttons to the apps. surface, the main window will need to get even bigger.
Hmmmm ... in FitCD imho in its newer releases there even isnt any PAR error mentioned anymore.
I do quote myself from my "to do" from the first post above:
but .... this will be not in the first priority but I had that Idea when adding the most needed functions like limiter(), converttoXXX() etc.
Also I was searching for a syntax-highlightning procedure for purebasic so that I could use one of these syntax-templates available at avisynth.org

:)

@ Karl
The cropping is doing fine now, yep.
But I want to make it possible to enter the final vertical resize (you already can see the spin-option in that little gadget where the vertical resize result is shown. So we can choose for example if 720>704 will be resized or cropped.

Thanks Andrej.
Here, I just encoded a small 30 second or so KDVD sample with your program, using overscan factor of 2, anamorph->non-anamorph, just to see how it came out :)
http://sr2.mytempdir.com/164369

-kwag

well Inc... they where just a few simple ideas.

Again, very nice tool.

And I did apreciate them! Go further on! :)

@ Karl

DONT trust that baby in this state 100% as I didnt had the possibility to check several NTSC inputs, the only VOB I do have is the RedPlanet chunk you gave me a time ago :)

EDIT: Ahhhh, saw your sample: RedPlanet ... seems to be your main testing object.
But it seems you did apply a resized overscan on that 2.35:1 source?

I always use that for consistency :)
That way, I can compare to past encodes :cool: Yes indeed!
I just wanted to see the crop/resize result :)
Not bad for a CQ of 75, MIN 300, MAX 6,000 and no filters at all ;)

From your program, safe (save?) script:

-kwag

Hi Inc,

Thanks for that great program: I'm sure it will replace fitcd and manual cropping from now on! :-)

And what about reading the registry key that store plugin path (HKEY_LOCAL_MACHINE\SOFTWARE\AviSynth\plugindir2_5 )? Or simply ask the user?
In my case, it don't matter, as I don't put any plugin in the plugins directory (fot stability and speed reason), and I have to copy it! :-)

Thanks,
Fabrice

A very good hint! I didn't know that its mentioned in the registry where the plugins folder does exist.

@ General
I found out that theres still a bug when loading a 704x576 source where the output will be 720x576, even its not the common procedure, the result is false! So the calculator still isn't perfect as mentioned above.

FitCD for shure is an excellent appl. as it gots its own things which this apll. doesnt have, means a total tweakable calculator. This appl. was meant to be a more comfortable one incl. some nice helping functions.
It wasn't my intention to stay in a clear concurrency to FitCD ;) And at least "in the state of" now FitCD is prooven to be far more accurate as this one in its beta state, so please do use this appl. to check/report bugs and still use FitCD for confiable resizing outputs up to the time when this appl. is more proofed.
Thanx

You're right when clearing things related to FitCD, even I also think your tool will be more useful for me (and sure for others).

I'm sorry to come again with a comparison with FitCD, as you want us to consider them as different tools. Yes, in FitCD it doesn't say a thing about PAR error, but it gives a Crop AR/Resize AR that I guess is similar. And this number appears in black if OK, yellow or red. This is what I refered to when suggesting you could put PAR error in bold or colors. But the info is anyway there, so you can forget it.

I keep in a doubt: what does it mean Pix Detection threshold?. What efects can we expect if we change it?.

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.