Croplus 2.21

[Overdrive80]

Function for calculating error aspect ratio, with function crop. Function Aspect_error can be invoked separately.

Download here.

Examples:

Croplus(4,0,-2,0) # It will show info about source and aspect errors

Subtitle(String(Aspect_Error(4,0,-2,0))) #Show Aspect error resizing for source dimensions.

Subtitle(String(Aspect_Error(4,0,-2,0, 640,480))) #Show Aspect error resizing for certain dimensions. In this case, height= 640, width=480.

[StainlessS]

From Docs

The Subtitle filter adds anti-aliased text to a range of frames. 
If you want more than one subtitle,you have to chain several Subtitle filters together.

If you like, I could quickly knock up a filter that prints out text using a standard Info.h font (not the anti aliased font
of SubTitle), as used in plugin metrics. It would only take a single string arg and optional x,y coords (pixel or character) and the string
could hold layout formatting, eg.

s = "Hello World, " + String(1.0,"%.3f") + "\nNext line Down\t Tabbed right"

PluginName(s,x=0,y=0,pixel=true)

You interested, maybe a couple of hours to knock it up?

EDIT: and apply to a range of frames.

[StainlessS]

Just spotted this in docs:

Multi-line text using "\n" is added in v2.57 and it is used if the lsp (line spacing) parameter is set.
It sets the additional line space between two lines in 0.125 pixel units.

This works:

Subtitle("This is a test\nand so is this",lsp=0) # lsp must be undefined (by default), any value switches it on

EDIT: You could create a string, appending additional messages to the string with a "\n" separator and then
only use subtitle once.

[Gavino]

Originally Posted by Overdrive80

However with subtitle function I cant write in differents lines because if I use various instances of subtitle function, only shows the last instance. How I could insert returns???

As StainlessS says, you can get multi-line subtitles using \n with the lsp option.
But multiple instances will also add new subtitles if you use a different alignment (or position (x, y)) for each one.
The reason your code only shows the second one is you have

...
i.subtitle("Your config is "+Source+" "+Region+" on format "+Ana+".")
...
	i.crop(l_crop, u_crop, r_crop, b_crop).subtitle("The aspect error is: "+string(calc, "%1.16f")+" %",align=9)

where you apply the second subtitle to a different clip instead of to the result of the first, which is thus thrown away.

Note also your function only works if you call it with negative values of r_crop and b_crop - perhaps it should also support positive values (meaning width and height as in Crop() itself).

Originally Posted by StainlessS

Subtitle("This is a test\nand so is this",lsp=0) # lsp must be undefined, any value switches it on

Of course you mean defined.

[StainlessS]

Of course you mean defined.

Actually no, any value for lsp switches it on, even -1, so I assumed that it was undefined by default.
If wrong, then how exactly does it not work until any value is assigned to lsp?

EDIT: I meant undefined, by default. Dont bother answering, have clarified in orig post.

[Overdrive80]

Thanks to both.

Enviado desde mi XT910 usando Tapatalk

[Overdrive80]

Hi, For I can implement suggestions of resizes I want check If following data is correct:

According ITU-R BT.601:

- DVD NTSC 4:3:

SAR= 720x480
DAR= (720x480)x(4320/4739) = 1.367377...
PAR= 4320/4739

- DVD NTSC 16:9:

SAR= 720x480
DAR= (720x480)x(4320/4739)x(4/3) = 1.823169...
PAR= 4320/4739x(4/3)= 5760/4739

- DVD PAL 4:3:

SAR= 720x576
DAR= (720x576)x(128/117) = 1.367521...
PAR= 128/117

- DVD PAL 16:9:

SAR= 720x576
DAR= (720x576)x(128/117)x(4/3) = 1.823361...
PAR= (128/117)x(4/3)= 512/351

Is it true???

EDIT: I dont understand PAR numbers of Adobe Premiere . Is it right??

[gyth]

Originally Posted by Overdrive80

According ITU-R BT.601:

http://www.itu.int/rec/R-REC-BT.601/en

It is a spec for broadcast television, not DVDs.
I'm not sure where your 4320/4739 is coming from.

DVDs don't all follow a single spec.
Some have data for the full 720 width, some only fill the middle 704.
Most give you noisy ill-defined edges more reflective of their analog origins than any digital standard.

In your picture, the 0.9091 is a 10/11 'PAR', which I've heard is correct for NTSC 4:3 DVDs if they only fill 704 out of the 720 width.
Use 8/9 if there is picture data for the full 720.

[Brother John]

Originally Posted by Overdrive80

According ITU-R BT.601:
Is it true???

Yes, it is. See here: http://forum.doom9.org/showthread.ph...27#post1058927
There’s even a third possibility to split hairs with the ITU values, but the only meaningful distinction is Generic or ITU-ish. You might even be able to deduce this automatically with autocrop. Assume ITU-ish when the image has at least 8-10 pixels wide black bars left and right, Generic otherwise. For ITU I’d settle for the MPEG-4 values for simplicity’s sake.

I dont understand PAR numbers of Adobe Premiere

Yep, those are weird. They use “real” ITU for PAL and MPEG-4 for NTSC. Doesn’t really make sense, but all those variants are too close to each other to make a real difference anyway.

[Overdrive80]

Originally Posted by gyth

http://www.itu.int/rec/R-REC-BT.601/en

It is a spec for broadcast television, not DVDs.
I'm not sure where your 4320/4739 is coming from.

I extract info from here

In your picture, the 0.9091 is a 10/11 'PAR', which I've heard is correct for NTSC 4:3 DVDs if they only fill 704 out of the 720 width.

Its not is the same the in broadcast??

@Brother John Above, would it be ITU-ish???

Thanks

[TheSkiller]

Originally Posted by Overdrive80

Its not is the same the in broadcast??

It's supposed to be the same. But with DVDs there is a greater chance than in broadcast to come across a non-ITU (generic) mastered video (imo).


The numbers you used are the exact values derived from the ITU-R BT.601 - so yes they are fine and "ITU-ish".


Don't get confused with those very exact PARs and the so called MPEG4 ones such as 12/11, 10/11, 16/11 and 40/33. The difference is no more than 2 Pixel. Like Brother John said, for all practical applications it does not matter which of the ITU ones you use, it's more a question of ITU or non-ITU (generic) where the difference is big enough to worry about (at least for me).

The MPEG4 ones are compatible with 16x16 block sizes, i.e. an image of 704 pixel width exactly represents the shape of a 4:3 or 16:9 image.

[Brother John]

Yes, absolutely ITU-ish.

If you love overkill, you could show four different aspect error variants calculated with the respective PAR:
* generic,
* MPEG-4,
* digital ITU (the values from Jukka Aho’s site),
* analog ITU (taking into account that the first and last analog lines are only half lines = half height).
Oh, and a fifth one for NTSC, calculated with a width of 711 pixels instead of 710.85. And if that’s still not enough, let’s discuss what “generic PAR” actually means.

[Overdrive80]

Ok, i understand. Thanks to both for you great explanations. I hope to implement it properly.

[2Bdecided]

Originally Posted by Overdrive80

I extract info from here

Don't. It's wrong. He converts the half lines into full lines, and you can't do that. That's why he has such strange numbers that no one else has.

If you want perfection, PAL 4x3 is PAR=1150/1053, and more than good enough PAL 4x3 is PAR=12/11. Generic PAL 4x3 PAR is 16/15.

Similarly, perfect NTSC 4x3 PAR is too stupid to use, more than good enough NTSC 4x3 PAR = 10/11, generic NTSC 4x3 PAR = 8/9.

You can calculate the corresponding 16x9 PARs by multiplying these fractions by 4x3 (e.g. more than good enough PAL 16x9 PAR= 16/11).

from here...
http://forum.doom9.org/showthread.ph...19#post1110419

See also...
http://forum.doom9.org/showthread.ph...05#post1525105

Cheers,
David.

[TheSkiller]

I have to admit those halve scanlines still make my head hurt.
What is stated in that table that you linked to in the "error in the DV faq about aspect ratios?" thread seems plausible to me: PAL has 575 scanlines in total and the width is 702 pixels (52µs) which gives us a PAR of 1150/1053. I remember I have heard this number before somewhere but unfortunately there are many PARs that are almost the same but come from different scenarios which is what I want to understand.

On Brother Johns (German) website (link) he states that 1150/1053 is an "analog PAR" which (I think) means it is ambigous for any digital image on a computer because those cannot have halve scanlines. However, I don't understand why 128/117 is then stated to be the proper "digital PAR". 128/117 would suggest a proper digital PAL image is 702x576.
I think 703.22 (rounded to 704) x 576 makes more sense...?

[Brother John]

Originally Posted by TheSkiller

I don't understand why 128/117 is then stated to be the proper "digital PAR".

Because after the A/D conversion there are no half lines anymore. They get filled up to full lines so it’s only reasonable to calculate with full-height lines. In other words: The image gains a tiny bit of height during A/D conversion. That’s also the reason why I disagree with

Originally Posted by 2Bdecided

He converts the half lines into full lines, and you can't do that.

In the analog domain: absolutely you can’t. But once you’re digital things change. You absolutely should do that because you do have full-height full-width lines.

I think 703.22 (rounded to 704) x 576 makes more sense...?

Nope. In analog you have a height of 574+½+½. In digital you have 574+1+1. The width isn’t affected.

[TheSkiller]

OK, I think I understand it.
So basically one shouldn't calculate with 575 lines because – and that's what helped me understand – we actually have 576 lines but the top most and bottom most lines simply have (or get) half of their content blanked out and that's why PAL actually has "575 lines worth of picture wrapped in 576 lines" and in digital we don't bother blanking the lines to make them halve (although that's possible, have seen it many times).
Makes sense to me now. So that's why the width stays the same (702) although we have 576 lines.
Thanks Brother John.

[Overdrive80]

Originally Posted by 2Bdecided

Don't. It's wrong. He converts the half lines into full lines, and you can't do that. That's why he has such strange numbers that no one else has.

If you want perfection, PAL 4x3 is PAR=1150/1053, and more than good enough PAL 4x3 is PAR=12/11. Generic PAL 4x3 PAR is 16/15.

Similarly, perfect NTSC 4x3 PAR is too stupid to use, more than good enough NTSC 4x3 PAR = 10/11, generic NTSC 4x3 PAR = 8/9.

You can calculate the corresponding 16x9 PARs by multiplying these fractions by 4x3 (e.g. more than good enough PAL 16x9 PAR= 16/11).

from here...
http://forum.doom9.org/showthread.ph...19#post1110419

See also...
http://forum.doom9.org/showthread.ph...05#post1525105

Cheers,
David.

Megui uses this values too, is wrong his use in megui??

EDIT: I updated to version 1.0, renamed function to Croplus. With show= true, will show data material and resize suggestions. I hope that you could test results if they are fine.

[StainlessS]

So as not to hijack your thread, previous scipt snippet moved here (DGIndex Batcher):
http://forum.doom9.org/showthread.ph...93#post1576193
Please feel free to us any part of it.

EDITED

[2Bdecided]

Originally Posted by Brother John

Because after the A/D conversion there are no half lines anymore. They get filled up to full lines so it’s only reasonable to calculate with full-height lines. In other words: The image gains a tiny bit of height during A/D conversion. That’s also the reason why I disagree with

In the analog domain: absolutely you can’t. But once you’re digital things change. You absolutely should do that because you do have full-height full-width lines.

First things first. We're talking about differences of less than one pixel. The difference isn't visible without a reference, and is barely visible even with one. Human eyes just aren't that accurate. No one who created this stuff ever cared if the video was this accurate either. In short: this doesn't matter.


However, if we must pick it apart to the sub-pixel level...

This digital video we work with was born in 1982. It is a digitisation of the pre-existing analogue standards. It inherits its parameters from the already very well defined analogue standards.

Therefore the PAL 4x3 PAR is 1150/1053. There is no argument. There is no debate. That is the correct value. It comes from 52us (702 pixels @ 13.5MHz) by 575 lines - the active 4x3 area. The tolerances on these values are huge. Everyone at the time assumed 5% or more overscan would hide the edges anyway. But the "ideal" values are clear.

Digitising 576 lines doesn't add any height, because the two extra half lines just capture some extra black, not active picture. Just like capturing 720 pixels horizontally just digitises some extra black, not active picture. Classic 720x576 sampling still has a PAR of exactly 1150/1053 (matching the 702x575 active picture area). Sampling more black pixels does not make the active picture area any larger. Sampling more black pixels does not change the PAR. Think about that for a second - it's pretty fundamental.

If you're thinking "the half lines are half in terms of length - how does that reduce the picture height at all?" you should see the pictures here... http://www.pembers.freeserve.co.uk/W....html#Vertical ...because that's the world these standards were created to describe.


But now, we work in an all digital world. All the archive PAL content we process will have a PAR of 1150/1053 - there is no use pretending otherwise. However, when creating new digital SD content, it may be convenient to adopt a slightly different PAR. It might even be acceptable when re-purposing archive content. It's not as if half-height half-length lines have any meaning on modern digital displays!

Here are your options:

active 702x575 implies PAR=1150/1053 = no error
active 702x576 implies PAR=128/117 = 0.174% error
active 704x576 implies PAR=12/11 = 0.111% error

It's the last option that gives you the smallest PAR error, the simplest PAR, and lets you light up all the pixels in the MOD16 MPEG acceptable 704x576 resolution.

It's also common sense: if you're going to add height (jumping to 576), you've got to add a little width too - otherwise it's obvious that you're going to change the shape.


Note: while filling the extra half lines is nice on a PC display, it's irrelevant on any real SD output, because the first half of line 23 will almost always contain Wide Screen Switching data (WSS - all European DVD players will add it), so even in underscan mode you'll almost never see real picture data in that top half-line on a TV.

Cheers,
David.

P.S. I did mention that none of this matters, didn't I?

It's just that, given that 704x576 and 704x480 give the closest PARs to the original standards, are both MOD16 MPEG valid resolutions, and yet give really simple PARs, it seems strange to want to add one pixel black borders and use weird PARs to get a more "correct" result when a) the result is further away from the correct PAR, and b) the difference is almost invisible. It's like "damn this simple solution - I want things to be complicated".