Yoda's Resize Calculator

[Motenai Yoda]

I'm into a mod of the tool, and I'm glad to get feedbacks and suggestions about the changes

par ratios are from Brother John's post http://forum.doom9.org/showpost.php?p=1058927&postcount=11

Old YRC ITU's are basically Jukka Aho’s ones multiplied by Industrial Square's 767/768 ratio
http://permalink.gmane.org/gmane.comp.video.mjpeg.user/5451

http://6.t.imgbox.com/7iRyFeMc.jpg (http://imgbox.com/7iRyFeMc)

It can be found on videohelp's page

Work in progress version:
v. 0.4.0.1 - http://filenurse.com/download/93500ae270caefcf71606fdf49e34e1d.html
v. 0.4.0.1 src - http://filenurse.com/download/b56b5eb2f3b78856e6e88727a757c10c.html

Changelog:
v. 0.4.0.1
- Fix: restore 1/999999 limits for custom dar up/down controls.
- Fix: restore Int32.MaxValue limit for Resize up/down controls.
- Fix: 16/99999999 limits for Source AR up/down controls.
- Ui: enlarged cropped_y label a bit

v. 0.4.x
- Add: Mpeg4 and "precise" ITU pars
- Fix: a bug on the error bar going to full on negative errors (I don't know how)
- Ui: enlarged a bit the whole form and crop controls to show more than 2 digits
- Ui: changed ITU checkbox with a ComboBox
- Ui: changed link to dead nps site to videohelp's page
- Compiled with .NET 2.0 compatibility

[hello_hello]

Nothing to complain about so far. Thanks!

Although a question..... how did you originally decide if an aspect error should be positive or negative? I ask, only because my brain insists on the aspect error being positive if the DAR is wider than the source and negative if it's narrower, whereas the calculator does it the other way around. It's no big deal of course. I'm just curious.

Edit: Although thinking about it, as an example.....
If the calculator is displaying a source aspect ratio of 1.77777 and a resize aspect ratio of 1.85, it seems counter-intuitive to me for that to be shown as a negative aspect error, given 1.85 is a larger number.

Cheers.

PS I'm probably being dumb, but what does "YRC" stand for?

[Motenai Yoda]

- (D)AR error is calculate as
100 * Source_AR - Resize_AR / Source_AR

as this is the way older tools calculate it, ie Moitah's Video Size Calculator

100 * 1.85 - 1.77 / 1.85 = 4,324324324324324 %

100 * 1.77 - 1.85 / 1.77 = -4,519774011299435 %

- Yoda's Resize Calculator

[hello_hello]

- (D)AR error is calculate as
100 * Source_AR - Resize_AR / Source_AR
as this is the way older tools calculate it, ie Moitah's Video Size Calculator

Older tools calculate it the wrong way around too? ;)

Yoda's Resize Calculator

For some reason I had it in my head YRC used the "Exact PAR according to ITU-R BT.601" from Brother John's list, not the "Jukka Aho PARs", so the penny didn't drop.... but I feel quite silly now.

I still think the drop down source list could include

Bluray Anamorphic (There's probably a better way to describe it, but I'm referring to 1440x1080 at 16:9)
Square 1:1 - 720p
Square 1:1 - 1080p

And including 4K in the source list probably wouldn't hurt, although that might also require widening the copping fields a little more to accommodate four digits. ;)

Thanks.

[Motenai Yoda]

- yep even GK and php resizecalc use this way (or equivalent)
actually the right formula should return an absolute value.

- the "Jukka Aho PARs" were the "Exact PAR according to ITU-R BT.601" until not long ago. I also doubt are more precise, coz ie it define top/bottom scanlines as half-height but indeed are half-width.
Also almost all post-y2k cameras are full digital, and I don't think who produce them has considered anything other than generic and mpeg4 pars.

- for Bluray Anamorphic I need to know what dar/par are related to
- 1:1 1080/720/4k are the same, you have just to change source values.
- on not ancient SOs crop controls can show now 4 full digits.

[Sharc]

- How about to specify not only the Source PAR, but also the target PAR? (In the current calculator the target PAR is fixed as 1:1 square pixels).
The application would be to re-size an ITU source to a Generic target, for example.

- SVCD and mpeg-1 standard PARs could perhaps be included in the PAR Spec. (historic legacy though ;) )

- You may also consider to add the calculation of NTSC/PAL/BD compliant borders after resizing.

But maybe this is all beyond the scope of the Calculator, so never mind.......

[hello_hello]

- yep even GK and php resizecalc use this way (or equivalent)

Aside from my brain being stubborn about seeing a wider aspect ratio as a negative aspect error, I think I'm also quite used to the way MeGUI calculates it... ie a wider aspect ratio produces a positive aspect error.
And 1.85 is still a bigger number than 1.77. ;)

- the "Jukka Aho PARs" were the "Exact PAR according to ITU-R BT.601" until not long ago. I also doubt are more precise, coz ie it define top/bottom scanlines as half-height but indeed are half-width.
Also almost all post-y2k cameras are full digital, and I don't think who produce them has considered anything other than generic and mpeg4 pars.

That's why I'd consider not bothering with the old "Jukka Aho PARs", if they're the least accurate, and including two different ITU PARs seems a bit redundant.

- for Bluray Anamorphic I need to know what dar/par are related to

There's only one Bluray complaint HD anamorphic resolution/aspect ratio and that's 1440x1080 at 16:9, which unless I'm mistaken makes the PAR 4:3.
https://en.wikipedia.org/wiki/Blu-ray#Video

- 1:1 1080/720/4k are the same, you have just to change source values.

Yeah, but I thought having a 720p source preset might be an added convenience, as then there's no need to change the source values, but it's not a big deal either way.

- on not ancient SOs crop controls can show now 4 full digits.

But I like XP. ;)

I had another thought or two....
As someone who pretty much always resizes to square pixels I'd prefer the resizing of PAL/NTSC not to default to resizing "down". That seems a bit last decade. :)
For example if you select PAL 4:3 or 16:9 from the source list, the resizing defaults to 640x464 or 640x352 etc. Given we live in a HD world and technically it's best not to resize the height, it'd be nice if the resizing could default to 788x576 or 1024x576 (or 1048x576 for ITU) instead.

Also, when you first run the calculator, the resizing defaults to mod4, but when you select something from the drop down source list, it switches to mod16, which I think is a bit unnecessary these days.

Thanks.

[Sharc]

...There's only one Bluray complaint HD anamorphic resolution/aspect ratio and that's 1440x1080 at 16:9, which unless I'm mistaken makes the PAR 4:3.
https://en.wikipedia.org/wiki/Blu-ray#Video

Yes, the PAR (or SAR in H.264 terminology) for 1440x1080 is 4:3 for DAR 16:9. I use it quite often to gain encoding speed, hardly loosing any visual loss of details in most cases. 1440x1080 is also popular for videocams.

[hello_hello]

par ratios are from Brother John's post http://forum.doom9.org/showpost.php?p=1058927&postcount=11

Old YRC ITU's are basically Jukka Aho’s ones multiplied by Industrial Square's 767/768 ratio
http://permalink.gmane.org/gmane.comp.video.mjpeg.user/5451

I have a PAR question or two, so I thought I'd ask here. It's more an "out of curiosity" thing than anything else, but I noticed something today and I was wondering.....

When you take the PAL "almost exact ITU PARs" from Brother John's list and apply a 767/768 almost-square pixel correction, the resulting PARs are the same as the exact PARs that should be obtained from an analogue to digital conversion.
ie 59/54 and 118/81 for 4:3 and 16:9 respectively.
https://en.wikipedia.org/wiki/Pixel_aspect_ratio#Analog-to-digital_conversion
I hadn't realised that before and it made me think maybe those PARs are fairly exact after-all, albeit minus the 767/768 correction.

I'm aware 59/54 and 118/81 aren't actually used, but instead fudged to 12/11 and 16/11 for convenience, but I tried applying the same idea to the PARs for NTSC, however they don't work out to be exactly the same as the NTSC digital PARs.

The "almost exact ITU NTSC PARs" multiplied by 767/768 are
34515/37912 (4:3) and 11505/9478 (16:9)
while the digital equivalents are 10/11 and 40/33.

My question is.... does anyone know why the "almost exact ITU PARs" multiplied by 767/768 are the same as their exact digital equivalents for PAL, but not for NTSC? If there's a logical reason I'm not seeing it. Is it just some bizarre coincidence the PAL PARs work out to be the same?

One more question while I'm at it.
Wikipedia says:
"As of this writing, ITU-R BT.601-6, which is the latest edition of ITU-R BT.601, still implies that the pixel aspect ratios mentioned above are correct".

Which means 59/54 and 118/81 for PAL, 10/11 and 40/33 for NTSC, which obviously aren't the same as the "exact ITU PARs" in Brother John's list.
Not that it's particularly important... I'm just wanting to increase my understanding.... but are the ITU PARs in Brother John's list from a much earlier ITU specification?

Thanks.

[Sparktank]

Work in progress version:
v. 0.4.0.1 - http://filenurse.com/download/93500ae270caefcf71606fdf49e34e1d.html
v. 0.4.0.1 src - http://filenurse.com/download/b56b5eb2f3b78856e6e88727a757c10c.html

all links dead. :(

[hello_hello]

Until Motenai Yoda returns, here's a new temporary link for the binary (v. 0.4.0.1). I don't have the source.
http://filenurse.com/download/7bb8e844be89ec08df031a9f6bbf4f23.html

The previous version can be found here:
http://www.videohelp.com/software/Yodas-Resize-Calculator
With Motenai Yoda's permission I had the calculator added to the VideoHelp software section a while ago, as it was no longer hosted anywhere else. I haven't submitted the new version yet as I was under the impression it was still a work in progress. If/when Motenai Yoda returns, hopefully he will let us know if that's the case and if he's happy for the current version to be uploaded there.

[Motenai Yoda]

I hadn't realised that before and it made me think maybe those PARs are fairly exact after-all, albeit minus the 767/768 correction.
nope difference between almost and exact is exact take into account how the scanline isn't perfectly horizontal too, and as someone said it should mean top and bottom lines are only half height

767/768 is a conversion from industry standard square (768/767) to 1:1 pixel square.

I've done a bit of work on, but actually I don't know if release it as is now or rewrite all from scratch.

[hello_hello]

nope difference between almost and exact is exact take into account how the scanline isn't perfectly horizontal too, and as someone said it should mean top and bottom lines are only half height

767/768 is a conversion from industry standard square (768/767) to 1:1 pixel square.

You might have misunderstood what I was asking. I wasn't referring to the "exact ITU" PARs in Brother John's list.

The PAL "Almost exact ITU" PARs from Brother Johns' list, multiplied by 767/768, equal the PAL digital PARs exactly.
https://en.wikipedia.org/wiki/Pixel_aspect_ratio#Analog-to-digital_conversion

ie
128/117 x 767/768 = 59/54
512/351 x 767/768 = 118/81

Applying the same to the NTSC "Almost exact ITU" PARs from Brother Johns' list doesn't result in the NTSC digital PARs.

4320/4739 x 767/768 = 34515/37912 (not 10/11)
5760/4739 x 767/768 = 11505/9478 (not 40/33)

The difference is very small, however I noticed it works out exactly for PAL but not for NTSC and wondered why.

[dark76]

I think filenurse deleted the files :(

[Zetti]

New links only for the binary (v. 0.4.0.1)

https://www.upload.ee/files/6287089/YodaResizeCalculator_0.4.0.1.7z.html
http://www19.zippyshare.com/v/hS4CdaSX/file.html
http://uppit.com/tyheb0s1ezio
http://filenurse.com/download/d2d8383431d272c48b5ec26c15ff2d53.html

[dark76]

New links only for the binary (v. 0.4.0.1)

https://www.upload.ee/files/6287089/YodaResizeCalculator_0.4.0.1.7z.html
http://www19.zippyshare.com/v/hS4CdaSX/file.html
http://uppit.com/tyheb0s1ezio
http://filenurse.com/download/d2d8383431d272c48b5ec26c15ff2d53.html

:thanks:

[DJ-1]

:thanks:Does anyone have the latest version of yoda resize they can share as all the links are dead..
Cheers.

Sent from my HTC_M10h using Tapatalk

[StainlessS]

Not latest, but here v3.5.11:- http://www.mediafire.com/file/42r610nbw626o8e/YodaResizeCalculator.7z

(from about 2015)

EDIT: thread from 2016, so this is old one, pre thread.
Guess that Yoda will be about within a few days, he aint no stranger here.

[GMJCZP]

YodaResizeCalculator_0.4.0.1

Here (http://www.filedropper.com/yodaresizecalculator0401)

[Motenai Yoda]

Sorry I usually don't scroll so down...
However, I am currently fully engaged in a completely different field, so I do not think I will have time or desire to work on it again.

[DJ-1]

Sorry I usually don't scroll so down...
However, I am currently fully engaged in a completely different field, so I do not think I will have time or desire to work on it again.Cheers.
Was looking at it as a means of comparison...

I know the whole far/par/Dar stuff & keep seeing mentions of SD standards & xMhz

I tried Googleing the relationship between the couple of rates of Mhz & keep going around in circles as to what exactly it has to do with the video & any calculations, if anything.

It's probable that I've just read it & missed the point entirely..
Do you have a slightly more dumbed down explanation of the relationship of Mhz & video (SD) standards?

Cheers.

Sent from my HTC_M10h using Tapatalk

[Motenai Yoda]

the image projected on screen is developed through a horizontal scan, where the single pixel is projected in row, and a vertical scan, where the next row is projected.
Usually you can find horizontal refresh as rows per seconds, and vertical refresh as screens per seconds.
In case of pal and ntsc crt standards, a row is skipped and then all first lines (Top Field First) and then all odd lines are projected (semi-fields).
Now in the distant era when brainiacs defined the standards, they prioritized reliability and ease of construction of devices rather than obtain round final values.
In the digital era, with the arrival of pixels, these fractional values became unpractical and calculations for a faithfully conversion too complicated to handle for available hardware, so rounded values were then used.
Unfortunately these standards have not always been respected, sometimes preferring greater fidelity, sometimes by simply making a mess.