Resize calculator PHP

[smok3]

Running at
http://resizecalc.sourceforge.net

sourceforge summary page
https://sourceforge.net/projects/resizecalc/

important note
- before posting bugs, please use alternative calculation method (preferably manual) and do mention which one was it, mkay? :) (nothing will get fixed without that)

licence
- unlicensed

php source
http://resizecalc.sourceforge.net/source/?C=M;O=D

-------------------------------

windows exe (not mantained)
http://sourceforge.net/projects/osx264/files/resizeCalcWapache/resizeCalc11aExe.7z/download

some reading
http://forum.doom9.org/showthread.php?t=145197
http://forum.doom9.org/showthread.php?p=1100187#post1100187

done
- php get method, so you can 'bookmark' your calcs
- 'any' pixel aspect to 'any' other one
- the usual pad or crop to
- echo a simple crop/resize avisynth
- crop source suggestions to minimize dar error (monte-carlo)
- new PAR recalc to fix error made with modN rounding
- blowup warning (check both output x and y if they are bigger than input (with croping) and color that result values in red or something)
- echo aftercrop resolution in avisynth part (before resizing)
- echo N up/down modN resolutions for onclick recalculations
- check also if calculated resolution is mod32 - nope, just enter custom mod into mod field instead
- change html to show some numbers with the options for AR correction
- crop suggestion for the aftercrop resolution to be modN
- echo mplayer command line (for playback)
- mplayer compatible crop input (704:416:6:80 = width, height, leftcrop, topcrop)

todo
- echo mencoder command line (for encoding), example from man;
Encode DVD title #2, resizing to 512xHHH (keep aspect ratio):
mencoder dvd://2 −vf scale −zoom −xy 512 −o title2.avi −oac copy −ovc lavc −lavcopts vcodec=mpeg4
- styling (css) and display type (show: more|less <- to be added) should not be part of the url, since this is user/browser specific, make cookie based preferences for that)
- write a little doc about how the math is handled (and simplified), with examples and how this may affect some of the calcs ('PAL' to 'NTSC' conversions may be a good example)
- add target height or no. of pixels
- change the avisynth display as a 2nd option, to be mod(1) friendly as described here (should i?):
http://forum.doom9.org/showthread.php?s=&threadid=91630

[LoRd_MuldeR]

1st try:
http://somestuff.org/resizeCalc.php
bookmark example; PAL to SQUARE:
http://somestuff.org/resizeCalc.php?ssmw=720&ssmh=576&sar=1.094&CL=8&CR=8&CT=0&CB=0&dar=1&trw=576&doit=true

That looks very useful. Thanks!
But the interface could be designed a little bit more eye-friendly :p

[Painkiller]

Looks Good :thanks:

[smok3]

But the interface could be designed a little bit more eye-friendly
color-wise or position wise? (for default browser look try http://somestuff.org/resizeCalc.php?css=false)
(interface will be redesigned anyway (when the source is released, it will be simply the matter of changing some css tags), but i need to implement all the features first, the priority now is to check all the math, so it is of 'reference' quality)

[LoRd_MuldeR]

color-wise or position wise?
Color-wise. Gray text on black background isn't too nice ^^
The "No CSS" version is completely "unstyled", but a lot better to use.


About the layout:

Maybe you can re-think the idea to place the input form on the very left side.
For example you can put the form into a box and place that box in the center of the screen...


About the calculation:

It would also be nice to calculate the new PAR for cropping only, but no resize.

1. Enter original resolution and original PAR
2. Enter what has been cropped (top, bottom, left, right)
3. Get the new (corrected) PAR value

This is needed to keep anamorphic video anamorphic, but crop the black borders away.
Without resizing!

[smok3]

so you are saying that PAR changes with cropping? (i would say no), example:
http://somestuff.org/resizeCalc.php?ssmw=704&ssmh=576&sar=1.459&CL=16&CR=16&CT=16&CB=16&trw=672&dar=1.459&css=false&doit=true
(manualy calculated requsted width=width-32 (based on cropping) and same for height=height-32, dar error=0 :))
or different crop:
http://somestuff.org/resizeCalc.php?ssmw=704&ssmh=576&sar=1.459&CL=16&CR=16&CT=72&CB=72&trw=672&dar=1.459&css=false&doit=true

anyway PAR is PAR and it will change only with resizing.

[LoRd_MuldeR]

I think this isn't the case or I'm doing something wrong ;)

For example my input captured from analog PAL TV is:

[Video]
Resolution: 720 x 576
Aspect ratio: 1.3333
Format: 0x10000002
Bitrate: 15000 kbps
Frames per second: 25.000
Selected codec: mpeg12

Now I crop away borders (-16 on left/right side, -8 on top/bottom).
Then I encode without resizing it. And I encode with PAR of "16:15" (PAL 4:3).
So I'm using the same PAR as the original/input was.

But the result is this:
[Video]
Resolution: 688 x 560
Aspect ratio: 1.3105
Format: H264
Bitrate: 1332 kbps
Frames per second: 25.000
Selected codec: ffh264

Obviously the Aspect Ratio isn't correct, the PAR needs to be re-calculated!

According to "ARS Calculator" I get:
688 x 560 and 4:3 Display AR => 140:129 PAR (not 16:15)

Using a "custom" PAR of 140:129 I get:

[Video]
Resolution: 688 x 560
Aspect ratio: 1.3333
Format: H264
Bitrate: 1332 kbps
Frames per second: 25.000
Selected codec: ffh264

So it's fine again, though it requires a non-standard PAR value....

All encoding done with Avidemux/x264. Video info/details taken from MPlayer.

[smok3]

Thats ok if DAR is different, since DAR may change with cropping (but PAR is the same), so there is nothing to recalculate (i think you are doing it wrong, no need to fix the PAR).

edit: i think you should use 128/117 for PAL PAR and keep in mind that usually active area is only 704 pixels wide.

edit2: this would be the 'correct' calc for your example (just happens that DAR error=0, since we crop mod16):
http://somestuff.org/resizeCalc.php?ssmw=704&ssmh=576&sar=1.094&CL=16&CR=16&CT=0&CB=0&trw=672&dar=1.094&css=false&doit=true
or this
http://somestuff.org/resizeCalc.php?ssmw=720&ssmh=576&sar=1.094&CL=24&CR=24&CT=0&CB=0&trw=672&dar=1.094&css=false&doit=true
(you have to take those 8 pixels into consideration)

edit3: or if you are sure that full 720 pixels are active area
http://somestuff.org/resizeCalc.php?ssmw=720&ssmh=576&sar=1.094&CL=16&CR=16&CT=8&CB=8&trw=688&dar=1.094&css=false&doit=true

edit4: honestly i don't even understand what 'ARS Calculator' does (it will fix the PAR for resizing mod16 error?).

p.s. this calc may eventually get some sort of:
- add autocrop left-right to minimize DAR error
- add autocrop all to minimize DAR error
(since i have no clue what the formula should look like, it will be some sort of monte-carlo calculation, time to start checking the speed of the script also...)

[LoRd_MuldeR]

Well, the facts are:

* My original (PAL) video is 720x576, the Display Aspect Ratio is 4:3
* If I encode that with a PAR of 16:15 ("as input"), the result plays with proper 4:3 aspect.
* There are black bars I want to crop away. The cropped video is 688x560.
* If I encode that cropped video with the "old" value of 16:15, the resulting video doesn't play at 4:3 any more!
* The "corrected" PAR value from ARS Calculator apparently does exactly what I need.
* The 688x560 video encoded with a PAR of 140:129 plays at proper 4:3 aspect.

[smok3]

well, interesting, i'am confused now :)

[LoRd_MuldeR]

Hmm, I guess I was thinking in the wrong direction:
"Improper" cropping might destroy the aspect ratio of the video, right?
Then re-calculating the PAR with ARS Calc will "stretch" it back to the original aspect.
So I get a video that has the same Display AR as the original, but the AR of the video is (slightly) wrong.
Do you understand what I mean?

[smok3]

yes i understand, however what i think the ARS calc does is fix the wrong resizing, since only with cropping you can't change PAR... (but i'am guessing)

The 688x560 video encoded with a PAR of 140:129 plays at proper 4:3 aspect
how can you tell?

anyway i realized that target PAR will usually be changed with mod16 or mod32 targeted resolutions, so new PAR could be calculated here... (however that is not the case in your example).

[LoRd_MuldeR]

how can you tell?

Well, the player displays my original 720x576 video with a Display Aspect Ratio (DAR) of 4:3. It's Pixel Aspect Ratio (PAR) is 16:15.
The cropped 688x560 video is not displayed with a DAR of 4:3, if I encode it with a PAR of 16:15.
But I now think that is "correct", because cropping parts away changes the DAR (if not cropped for the same percentage in both dimensions).
Using the 140:129 PAR will cause the 688x560 video to be displayed with a DAR of 4:3 again, but I think it's actually "stretched" then.

[smok3]

But I now think that is "correct", because cropping parts away changes the DAR (if not cropped for the same percentage in both dimensions).
Using the 140:129 PAR will cause the 688x560 video to be displayed with a DAR of 4:3 again, but I think it's actually "stretched" then.
yes, thats right,

- there is new version which will calc also a new PAR value based on mod16 error - but i guess this is more confusing than useful?

- also ugly php source is up there (check 1st post)

[smok3]

.added 'pad or crop to'.

[buzzqw]

well done smok3

very usefull thanks!

BHH

[smok3]

buzzqw: tnx, hopefully someone (else than me) will find this usefull :)

.added 'custom target mod' - if undefined defaults to 16.

.added 'suggest crop height or width or width&height to minimize DAR error - that pretty much equals/supersedes autocrop-all and autocrop left-right' -monte carlo calculus - user will have to be aware of the color-space limitations with avisynth cropping, but that seems still better than mod2 limitation.

[smok3]

08
.added blowup warning
.some html changes
.removed all javascript
08b
.echo aftercrop resolution

[krosswindz]

Its really useful I use it quite often. It would be really nice if you can have an option to generate multiple resolution along with the associated errors.

Given the crop value generate multiple resolutions if the user doesnt request a width.

608x?
624x?
640x?
656x?
672x?
688x?

Something like this so that user might choose the resolution depending on this.

[smok3]

krosswindz: are you saying that one would choose encoding resolution based on DAR error? - i don't really understand the request (calculating dar error for lot of them would take time, since the implementation is monte-carlo).
(echo N up and N down will be implemented thought)

[krosswindz]

^ yeah one can choose the encoding resolution based on keeping the DAR error to a minimum.

how about having something like a default resolution (currently 640) and buttons to change the width, then the user can choose the one that he prefers.

[smok3]

08c
.added : 'on click recalc with new width' thingy, which is simply 'width + mod' or 'width - mod' (will work with js disabled as well, one will just have to travel for another click on submit)

[krosswindz]

^ awesome

[krosswindz]

I have been reading up a bit on calculating the suitable resolution when trying to encode movies from DVD9. I was trying to figure out how once actually calculates the different aspect ratios.

There are different aspect ratios like

DAR (display aspect ratio)
PAR (pixel aspect ratio)

I read this http://www.doom9.org/capture/par.html to figure out the different PAR values.

I know that cropping doesnt affect PAR but resizing does affect PAR. The question I have is whats the relation between the change between source resolution and target resolution when one resizes.

Which aspect ratio error do you want to minimize when you resize?

How is DAR related to PAR etc. If someone could point me to some resources it would be much appreciated. I did some reading I am confused as some links they use things like 2.35 as DAR other places use it PAR.

[smok3]

internaly calc uses PAR, but DAR error is used (only for presentation and for croping suggestions) for better compatibility with other calcs out there, this is basically a representation of source (cropped) resolution vs target mod-resolution (i think, irc).

Which aspect ratio error do you want to minimize when you resize?
you want to minimize target DAR error introduced by (usually mod16) rounding basically, but in some cases you would want all the pixels to go into resizing, in other you would use smaller mod, or maybe just use new PAR, etc, it is a case by case 'problem'.

example:
pal to square;
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.094&sar2=&ssmh=576&CT=0&CL=8&CR=8&CB=0&trw=576&dar=1&dar2=&mod=&padw=&padh=&css=&doit=true
i could fix the error by using custom PAR;
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.094&sar2=&ssmh=576&CT=0&CL=8&CR=8&CB=0&trw=576&dar=1&dar2=1.003&mod=&padw=&padh=&css=&doit=true
or maybe with some additional cropping, since my encoding method does not support custom PARs;
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.094&sar2=&ssmh=576&CT=0&CL=8&CR=10&CB=0&trw=576&dar=1&dar2=&mod=&padw=&padh=&css=&doit=true

PAR and DAR, basic formula is

DAR width
--- = ------
PAR height

[Ranguvar]

Your calculator has a problem. Not sure exactly what, but as you can see, when one types in an input res of 1280x528 square pixels, and attempts to resize to NTSC wide, the calculator outputs resolutions like 688x352, 672x336, and 640x320. Which are, obviously, close to a 2:1 AR rather than the targeted 2.35:1.

The calculator reports the number of pixels in the modified resolution correctly, but thinks its erroneous output resolutions are ~2.35:1, with a very small error.

Example: http://somestuff.org/resizeCalc.php?ssmw=1280&sar=1&sar2=&ssmh=528&CT=0&CL=0&CR=0&CB=0&trw=640&dar=1.215&dar2=&mod=&padw=&padh=&css=&doit=true

Note how the calculator thinks "640x320" is 2.43:1...

[smok3]

Ranguvar: no, i don't see? 1*1280/528 = 2.42 no? (and 640*1.215/320 = 2.43)

please do some proper (manual maybe) calcs and then post a bug...

edit: since you didn't consider PAR, maybe start readin here
http://www.doom9.org/index.html?/capture/par.html

[krosswindz]

internaly calc uses PAR, but DAR error is used (only for presentation and for croping suggestions) for better compatibility with other calcs out there, this is basically a representation of source (cropped) resolution vs target mod-resolution (i think, irc).


you want to minimize target DAR error introduced by (usually mod16) rounding basically, but in some cases you would want all the pixels to go into resizing, in other you would use smaller mod, or maybe just use new PAR, etc, it is a case by case 'problem'.

example:
pal to square;
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.094&sar2=&ssmh=576&CT=0&CL=8&CR=8&CB=0&trw=576&dar=1&dar2=&mod=&padw=&padh=&css=&doit=true
i could fix the error by using custom PAR;
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.094&sar2=&ssmh=576&CT=0&CL=8&CR=8&CB=0&trw=576&dar=1&dar2=1.003&mod=&padw=&padh=&css=&doit=true
or maybe with some additional cropping, since my encoding method does not support custom PARs;
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.094&sar2=&ssmh=576&CT=0&CL=8&CR=10&CB=0&trw=576&dar=1&dar2=&mod=&padw=&padh=&css=&doit=true

PAR and DAR, basic formula is

DAR width
--- = ------
PAR height

Since the idea is to minimize the DAR error, how does one calculate the DAR from the source frame size. Would cropping affect the DAR? If so how would one calculate the actual DAR from the values.

[smok3]

source DAR is basically = sourcePAR * (width-widthCROP) / (height-heightCROP)

yes, cropping affects DAR.

Since the idea is to minimize the DAR error
the idea is different on a case by case basis... (or better on user by user basis), or with different words: this calc is just a tool, don't get any ideas from it :)

[krosswindz]

the idea is different on a case by case basis... (or better on user by user basis), or with different words: this calc is just a tool, don't get any ideas from it :)

when you are converting from source to target, assuming that PAR values cant be change, then the aim is to reduce the DAR maintaining the standards?

Like if we are converting say from NTSC Wide to PAL Wide, the PAR values are constant. If you want use minimal cropping then there would be a certain amount of error always associated. If you want to minimize this error then you would have to change the cropping right?


edit: For resizing (ignoring cropping)

source_DAR target_DAR
------------- = -------------
source_PAR target_PAR

[smok3]

yes, i guess that would be the case.

[krosswindz]

I wonder what the problem here is. If you read this article

http://forum.videohelp.com/topic174200.html

entering the crop values based on that gives a different DAR and resolutions too?

http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.215&sar2=&ssmh=480&CT=60&CL=0&CR=0&CB=60&trw=640&dar=1&dar2=&mod=16&padw=&padh=&css=&doit=true

edit: basically from the article the DAR is supposed to be 2.35 but using the resizecalc we get a DAR of 2.43 is there something I am missing?

[smok3]

if you think it is a bug, then suggest some numbers, so i can fix.
(p.s. i have compared the results with two different calcs, and they both spit out 640x256)

edit: example;
http://somestuff.org/example.png

quote from http://forum.videohelp.com/topic174200.html
if you have a theatrical movie that has an aspect ratio of 2.35:1 and you want to encode your AVI for playback on a PC, then you would simply resize it using a 2.35:1 aspect ratio
and one would know that by looking at what excatly?

[krosswindz]

if you think it is a bug, then suggest some numbers, so i can fix.
(p.s. i have compared the results with two different calcs, and they both spit out 640x256)

The output depends on the calculated DAR if I am not wrong. I tried another calculator with the crop values its spits out 640x256. But the question is what was the DVDs flagged DAR

I have a DVD9 with me, is it possible to find out what the flagged DAR would be. I guess once the image is cropped the calculated DAR should be somewhat close to flagged DAR.

edit: What is the video calculator used in the screen?

[krosswindz]

quote from http://forum.videohelp.com/topic174200.html

and one would know that by looking at what excatly?

I guess one way to figure out would be looking at the aspect ratio listed on IMDb. I am not sure if it lists the aspect ratio for every movie.

[smok3]

no, no, no, the DVD have no flaged DARs, there are basically only two common PARs, most of the commercial titles should be either using (i will use my calc terminology here)
a. ntsc wide PAR or
b. pal wide PAR

different DARs are then made by using padding with black borders.

p.s. the 'idea' to 'determine what DAR is used' is silly, as you allready know what PAR your DVD uses, so there is nothing to determine....

[krosswindz]

no, no, no, the DVD have no flaged DARs, there are basically only two common PARs, most of the commercial titles should be either using (i will use my calc terminology here)
a. ntsc wide or
b. pal wide

different DARs are then made by using padding with black borders.

The padding is done to convert them to one of the common PARs (NTSC wide/PAL wide). If you crop of the black borders then you should get the actual DAR of the source, I hope I am right about this. This DAR should be as close as possible to the theatrical DAR, if I am right.

[smok3]

yes, but one can't really know if the theatrical DAR is really what was transfered to DVD (there could be some cropping in the process, ect) when on the other hand PAR is always known to the end user.

[SeeMoreDigital]

If you crop of the black borders then you should get the actual DAR of the source, I hope I am right about this. This DAR should be as close as possible to the theatrical DAR, if I am right.True...

I prefer to refer to this as being the Movie Aspect Ratio (MAR). Others refer to it as being the Theatrical Aspect Ratio.

[smok3]

hmm, well, imho there is enough confusion allready about this 3 letter beasts, how about not inventing new ones?
(MAR actually stands for Modified aspect ratio)

[krosswindz]

yes, but one can't really know if the theatrical DAR is really what was transfered to DVD (there could be some cropping in the process, ect) when on the other hand PAR is always known to the end user.

Very true, during the transfer if they cropped the picture then you would be loosing the theatrical DAR. It would be nice if there was some way of determining the DAR that DVD was authored in. Would be really helpful when you re-encode.

[smok3]

uhmm, yes, you crop the blacks, use the correct PAR and there you have your correct source DAR (unless the production company f*** up in conversion somehow, but you can't really be sure about that, unless you know the movie really really well...)

---

anyway, lets go the other way, for example i have done some renderings in my favorite 3d package, this are 2048x866 frames (35mm Full Screen Super 4k cineon - preset) with PAR 1:1, and for some reason i would like to do wide PAL dvd out of the animation;
http://somestuff.org/resizeCalc.php?ssmw=2048&sar=1&sar2=&ssmh=866&CT=0&CL=0&CR=0&CB=4&trw=704&dar=1.459&dar2=&mod=&padw=720&padh=576&css=&doit=true
(i would crop some pixels in the bottom, so i get less error and there goes away my original DAR...)

[krosswindz]

Not only do you loose the original DAR, you also loose some part of the image. Wish things were so much easier with encoding. I think the only way one can really not have problems would be when creating the images based on what the final product would be.

[SeeMoreDigital]

hmm, well, imho there is enough confusion allready about this 3 letter beasts, how about not inventing new ones?
(MAR actually stands for Modified aspect ratio)As of December 2007!!!

I wonder who decided to place that new acronym on Wikipedia

[smok3]

oh, it wasn't me :)

I think the only way one can really not have problems would be when creating the images based on what the final product would be.

in this days it is quite usual that one must produce video for different aspect ratios/different media systems as well (well known example from tv world is 14:9, where you can shoot in 16:9 with 14:9 picture in mind or with 4:3 with 14:9 picture in mind..., cough), sometimes i do 4:3 version for TV and 16:9 version for web, ect.

(using loose conversation-purpose numbers here)

[krosswindz]

is the math for PAL <-> NTSC right. Because video frame height are different for both.

[smok3]

i think for D1 pal to D1 ntsc this should be simply good enough
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.094&sar2=&ssmh=576&CT=&CL=&CR=&CB=&trw=720&dar=0.911&dar2=&mod=&padw=&padh=&css=&doit=true (sampling matrix width in µs =53.33333 µs)
or maybe
http://somestuff.org/resizeCalc.php?ssmw=704&sar=1.094&sar2=&ssmh=576&CT=&CL=&CR=&CB=&trw=704&dar=0.911&dar2=&mod=&padw=&padh=&css=&doit=true (sampling matrix width in µs=52.14815 µs)
(makes sense that there is minimum DAR error, which needs not to be fixed, although as you may figure out the active area wont match perfectly in some cases, for this kind of conversions i would recommend a manual calc method which must start with collecting all the needed data - and you have to do it correctly just once anyway)

[krosswindz]

Quoting http://lipas.uwasa.fi/~f76998/video/conversion

If vertical_conversion_factor is anything other than 0.5, 1 or 2, you are probably trying to do a standards conversion between a 625/50 system and a 525/59.94 system. Standards conversion (when done right) is a highly demanding process and outside the scope of this document.


Here the vertical conversion factor would not be 1. Since the active picture heights vary. Would the resized image be fine?

[smok3]

i'am not sure what he meant with 'demanding' process? (maybe that one shouldn' do it at all...)

[krosswindz]

i'am not sure what he meant with 'demanding' process? (maybe that one shouldn' do it at all...)

I am not sure how demanding the process is but I have seen a lot of Indian movie DVDs which are PAL to NTSC transfers and are such pain to deinterlace. Apart from being a bad transfer they all have bad aspect ratio too.