Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 Doom9's Forum Yoda's Resize Calculator
 Register FAQ Calendar Search Today's Posts Mark Forums Read

 26th June 2016, 11:41 #2  |  Link hello_hello Registered User   Join Date: Mar 2011 Posts: 3,484 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? Last edited by hello_hello; 26th June 2016 at 11:55.
 26th June 2016, 13:21 #3  |  Link Motenai Yoda Registered User     Join Date: Jan 2010 Posts: 635 - (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 __________________ powered by Google Translator
26th June 2016, 14:22   #4  |  Link
hello_hello
Registered User

Join Date: Mar 2011
Posts: 3,484
Quote:
 Originally Posted by 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
Older tools calculate it the wrong way around too?

Quote:
 Originally Posted by Motenai Yoda 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.

 26th June 2016, 19:17 #5  |  Link Motenai Yoda Registered User     Join Date: Jan 2010 Posts: 635 - 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. __________________ powered by Google Translator
 26th June 2016, 23:00 #6  |  Link Sharc Registered User   Join Date: May 2006 Posts: 3,263 - 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....... Last edited by Sharc; 27th June 2016 at 07:35.
27th June 2016, 02:56   #7  |  Link
hello_hello
Registered User

Join Date: Mar 2011
Posts: 3,484
Quote:
 Originally Posted by Motenai Yoda - 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.

Quote:
 Originally Posted by Motenai Yoda - 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.

Quote:
 Originally Posted by Motenai Yoda - 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

Quote:
 Originally Posted by Motenai Yoda - 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.

Quote:
 Originally Posted by Motenai Yoda - 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.

27th June 2016, 07:47   #8  |  Link
Sharc
Registered User

Join Date: May 2006
Posts: 3,263
Quote:
 Originally Posted by hello_hello ...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.

22nd August 2016, 05:24   #9  |  Link
hello_hello
Registered User

Join Date: Mar 2011
Posts: 3,484
Quote:
 Originally Posted by Motenai Yoda par ratios are from Brother John's post http://forum.doom9.org/showpost.php?...7&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.com...jpeg.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_...tal_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.

22nd August 2016, 06:09   #10  |  Link
Sparktank
47.952fps@71.928Hz

Join Date: Mar 2011
Location: Planet Express, Inc.
Posts: 789
Quote:
__________________
Win10 (x64) | GPU Caps Viewer v1.32.0.0
Crucial M500 240GB SSD | Kingston SSDNow V300 (Marvell) 120GB | NVIDIA GeForce GTX 750 Ti | R375.95 (Nov 18, 2016)
NTSC | DVD: R1 | BD: A

 23rd August 2016, 00:33 #11  |  Link hello_hello Registered User   Join Date: Mar 2011 Posts: 3,484 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/7bb8e8...f6bbf4f23.html The previous version can be found here: http://www.videohelp.com/software/Yo...ize-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.
24th August 2016, 00:13   #12  |  Link
Motenai Yoda
Registered User

Join Date: Jan 2010
Posts: 635
Quote:
 Originally Posted by hello_hello 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.
__________________

26th August 2016, 02:48   #13  |  Link
hello_hello
Registered User

Join Date: Mar 2011
Posts: 3,484
Quote:
 Originally Posted by Motenai Yoda 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_...tal_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.

Last edited by hello_hello; 26th August 2016 at 02:59.

 20th October 2016, 21:08 #14  |  Link dark76 Registered User   Join Date: Sep 2016 Posts: 2 I think filenurse deleted the files
 26th October 2016, 17:57 #15  |  Link Zetti Registered User   Join Date: Dec 2015 Posts: 59
27th October 2016, 20:18   #16  |  Link
dark76
Registered User

Join Date: Sep 2016
Posts: 2
Quote:
 Originally Posted by Zetti

24th November 2017, 14:56   #17  |  Link
DJ-1
Registered User

Join Date: May 2009
Posts: 313
Quote:
 Originally Posted by dark76
Cheers.

Sent from my HTC_M10h using Tapatalk

 24th November 2017, 20:21 #18  |  Link StainlessS HeartlessS Usurer     Join Date: Dec 2009 Location: Over the rainbow Posts: 5,161 Not latest, but here v3.5.11:- http://www.mediafire.com/file/42r610...eCalculator.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. __________________ I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but are any of them infinitely bigger ??? Last edited by StainlessS; 24th November 2017 at 20:25.
 24th November 2017, 20:51 #19  |  Link GMJCZP Registered User     Join Date: Apr 2010 Location: I have a statue in Hakodate, Japan Posts: 444 YodaResizeCalculator_0.4.0.1 Here __________________ By law and justice! Flea Market
29th November 2017, 01:03   #20  |  Link
Motenai Yoda
Registered User

Join Date: Jan 2010
Posts: 635
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.
Attachments Pending Approval
 YodaResizeCalculator_0.4.0.1.7z YodaResizeCalculator_0.4.0.1_src.7z
__________________

Last edited by Motenai Yoda; 29th November 2017 at 01:08.

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is Off Forum Rules
 Forum Jump User Control Panel Private Messages Subscriptions Who's Online Search Forums Forums Home Announcements and Chat     General Discussion     News     Forum / Site Suggestions & Help General     Decrypting     Newbies     DVD2AVI / DGIndex     Audio encoding     Subtitles     Linux, Mac OS X, & Co Capturing and Editing Video     Avisynth Usage     Avisynth Development     VapourSynth     Capturing Video     DV     HDTV / DVB / TiVo     NLE - Non Linear Editing     VirtualDub, VDubMod & AviDemux     New and alternative a/v containers Video Encoding     (Auto) Gordian Knot     MPEG-4 ASP     MPEG-4 Encoder GUIs     MPEG-4 AVC / H.264     High Efficiency Video Coding (HEVC)     New and alternative video codecs     MPEG-2 Encoding (HD) DVD, Blu-ray & (S)VCD     One click suites for DVD backup and DVD creation     DVD Rebuilder     (HD) DVD & Blu-ray authoring     Advanced authoring     IFO/VOB Editors     DVD burning Hardware & Software     Software players     Hardware players     PC Hard & Software Programming and Hacking     Development     Translations

All times are GMT +1. The time now is 10:22.

 Doom9.org - Archive - Top