Resize calculator PHP

[krosswindz]

I noticed that there were black bars on the top and bottom. If I cropped 62 pixels off of both the top and bottom, I got rid of all remnants of black bars.

# resizeCalc
# pixels = 207360, DAR error = 0.023
# Crop(Left, top, -right, -Bottom)
Crop(0,65,-0,-65) # 720x350(-2px)
LanczosResize(720,288) # (mod16)



What I quite dont understand is what is your final crop value? is it 62 or 65 (which could be mean either 64/66 for mod2).

[Adub]

Okay, so that script that I posted above was calculated by smok3's resize calculator.

I entered in that I cropped off 62 pixels from the top and the bottom. I set my source to NTSC Wide and my desired to Square. I then clicked calculate. By reading the comments on the bottom of the calculator, below the script, I arrived at the script I posted.

You can do it yourself if you are still confused.

Edit: Okay, so I looked at the MKVMerge documentation, and it looks like I will be putting in the MAR into the gui box. Or I could specify the exact dimensions if I wanted to. In the cli version there are 3 flags dealing with aspect ratio:



−−display−dimensions <TID:widthxheight>


Matroska files contain two values that set the display properties that a player should scale the image on playback to: display width and display height. These values can be set with this option, e.g. ’1:640x480’.
Another way to specify the values is to use the −−aspect−ratio or the −−aspect−ratio−factor option (see below). These options are mutually exclusive.


−−aspect−ratio <TID:ar|w/h>


Matroska files contain two values that set the display properties that a player should scale the image on playback to: display width and display height. With this option mkvmerge will automatically calculate the display width and display height based on the image’s original width and height and the aspect ratio given with this option. The ratio can be given either as a floating point number or as ´width/height’, e.g. 16/9.


−−aspect−ratio−factor <TID:ar|w/h>


Another way to set the aspect ratio is to specify a factor. The original aspect ratio is first multiplied with this factor and used as the target aspect ratio afterwards.
Another way to specify the values is to use the −−aspect−ratio option (see above). These options are mutually exclusive.


It looks like I would put in my ARS into the aspect ratio factor, or my MAR (or is it DAR?) into the aspect ratio, or my desired hight and width into the display dimensions.

Is this right?


Edit2: Also, SeeMoreDigital, your encodes kept saying a "non-square" pixel width of "foo". But I thought I wanted square pixels. Don't I encode using non-square pixels and then set the display size in mkvmerge so that I actually have square pixels. I thought that was the whole point in the beginning.

[smok3]

square pixels and anamorphic encoding are two different poles: you need non-square pixels for something to be called anamorphic (so what you end up, hopefully is something with correct display aspect ratio, but with non-square pixels).

MAR is something invented by SeeMoreDigital as it seems :)

p.s. the calc is linkable, so instead of providing what was printed out, just paste the url next time.

[Adub]

Oh, okay. And I will post a link to the calc next time.

[krosswindz]

MAR is something invented by SeeMoreDigital as it seems :)


Are'nt we back to who edited Wikipedia to change it :p

[SeeMoreDigital]

Are'nt we back to who edited Wikipedia to change it :pLol...

This is why hate three-letter acronyms. And why I especially don't like using the terms DAR, PAR and SAR and prefer to use the phrase Aspect Ratio Signalling instead.

When I concieved my own little application (ie: Aspect Ratio Signalling Calculator, way back in Xmas 2005) I did indeed elect to use the following terms: -

MAR = Movie Aspect Ratio - Refers to the aspect ratio of the movie. After cropping away all the black mattes. Which (as we all know) often does not match the aspect ratio of the movie stated on the back of the DVD cover.

PFS = Pixel Frame Size - Refers to the resolution of your encode in width pixels and height pixels.

ARS = Aspect Ratio Signalling - Refers to the aspect ratio signalling level that's needed to change (or distort) the shape of a "square pixel" to a "non-square" pixel.

[unskinnyboy]

MAR = Movie Aspect Ratio - Refers to the aspect ratio of the movie. After cropping away all the black mattes. Which (as we all know) often does not match the aspect ratio of the movie stated on the back of the DVD cover.I think we do need a term called MAR, because in between all the SAR-PAR-DAR malarkey, we never actually defined a term which would refer to the actual AR of the movie on the DVD! Which, like you said, can sometimes differ from what's on the box and what's on Amazon.com. In the olden days, due to the lack of a better word, I've tried to refer to MAR by using words like theatrical AR, source AR etc., but I've realized that they could cause confusion and because strictly speaking, they are probably incorrect. Theatrical AR is X.YY:1 doesn't mean that the MAR would be the same, thanks to the not-so-uncommon DVD transfer flaws. Not to mention that the MAR of the theatrical version of the movie could be different from the MAR of the DC, which in turn could be different from the Ultimate Edition DVD release, and so on :rolleyes:. Source AR could cause confusion in that it sounds like I am referring to the DVD DAR.

SMD, since I concur with you on MAR, if we could go and throw it around in the future AR related threads (there will be many more, I'm sure), sooner or later, we can make this part of the standard encoder's lexicon. :p

PFS = Pixel Frame Size - Refers to the resolution of your encode in width pixels and height pixels.This, I don't think we need. Storage Aspect Ratio (SAR) sounds just fine to me, although, deep inside, I've always wished it had been called FAR (Frame Aspect Ratio) instead. Oh well...

ARS = Aspect Ratio Signalling - Refers to the aspect ratio signalling level that's needed to change (or distort) the shape of a "square pixel" to a "non-square" pixel.Hmm, you referring to DAR here? See, how confusing this can be? If you insist on using the word anyway, I demand that it be changed to "Aspect Ratio Signaling" instead - the American way.





J/K :devil:

[krosswindz]

MAR = Modified Aspect Ratio as defined here http://en.wikipedia.org/wiki/Aspect_ratio_(image)

now what do we call this as :p

We should probably have some form of terminology that we should come up with and sticky it somewhere.

[unskinnyboy]

From an encoder's perspective, the term Modified Aspect Ratio (MAR) has little or no bearing. If a WS movie was modified by Pan & Scan to FS, I wouldn't buy the DVD, let alone attempt to encode it. Open Matte DVDs aren't that common, and if available would take preference over a WS DVD of the same movie, for me.

[smok3]

instead of MAR, how about MORDAR? (movie original release DAR)? :p (at least it will be clear that the aspect ratio type is DAR), anyway, fix the wikipedia first.
p.s. anyway, since there seem to be no interest in simplifying and unifying the acronyms, i will invent few of mine as well, just to add to the confusion.

-----------------------
09a
.more PAR presets, changed the naming scheme to be more exact (and to add to the naming confusion)
.the result textarea is now editable
.small fixes here and there
.examples removed since they didn't follow the new naming scheme
.this version may break URL compatibility with older ones
.in IE it does look pretty damn borken, can't be bothered...

[krosswindz]

09a
.more PAR presets, changed the naming scheme to be more exact (and to add to the naming confusion)
.the result textarea is now editable
.small fixes here and there
.examples removed since they didn't follow the new naming scheme
.this version may break URL compatibility with older ones
.in IE it does look pretty damn borken, can't be bothered...

Probably a typo, I am not sure shouldnt PAL be 704 instead of 702 :confused:

[krosswindz]

@smok3 a suggestion, if we choose PAL (704/720) or PAL Wide (704/720), cant the source matrix size be fixed to 704x576 or 720x576. Similarly for NTSC too.

[smok3]

702 is a bit closer to the truth, but one can easily use 704 (basically 704 is the closest mod16 number) with very small error for the same standard.

edit2: at least, thats what i figured yesterday, not so sure today :)

edit: note that the math done by the calc is a bit simplified.

---
edit3:
cant the source matrix size be fixed
what if you have cropped anamorphic encode as input? (but yes, i see that some other calcs are doing it that way for some reason..., here you would just do some bookmarks for the numbers you use often instead.)
p.s. actually crappy flexibility displayed in other calcs is the main reason i started this 'project'.

example: say you encoded something from PAL source and croped off the black borders; 576-64-64 = 448 (mod16) and now you would want to recode that into square pixels, then you would just start thinkering with something like;
http://somestuff.org/resizeCalc.php?ssmw=702&sar=1.094&sar2=&ssmh=448&CT=0&CL=0&CR=0&CB=0&trw=640&dar=1&dar2=&mod=16&padw=&padh=&css=&doit=true

example bookmark for PAL 702;
http://somestuff.org/resizeCalc.php?ssmw=702&sar=1.094&sar2=&ssmh=576&CT=0&CL=0&CR=0&CB=0&trw=&dar=1&dar2=&mod=&padw=&padh=&css=&doit=false
(change doit=true to doit=false in the url, and you would have just the input field defined)

[SeeMoreDigital]

702 is a bit closer to the truth, but one can easily use 704 with very small error for the same standard.Agreed :)

[smok3]

@smok3 a suggestion, if we choose PAL (704/720) or PAL Wide (704/720), cant the source matrix size be fixed to 704x576 or 720x576. Similarly for NTSC too.

on the 2nd thought, presets system could be implemented as (similar thing as presets in adobe after FX):
1st. select input preset which will populate PAR, width, height
2nd. let the user decide which part to keep by allowing to change each individual

but that would just blow up the GUI.

[krosswindz]

702 is a bit closer to the truth, but one can easily use 704 (basically 704 is the closest mod16 number) with very small error for the same standard.

edit2: at least, thats what i figured yesterday, not so sure today :)



does this mean for NTSC it is 710/711 or whatever it is :confused:

edit: links would be useful to educate the uneducated like myself.

[smok3]

no, you would take the 'sampling matrix width';
http://lipas.uwasa.fi/~f76998/video/conversion/#conversion_table
(link is also on the calc)
---
edit:
demos for new versions will be @
http://resizecalc.somestuff.org
(edit2: redirection from old to new url is now active)
---
edit3:
cunning plan for a preset system without gui blowup (javascript-ish)
SOURCE
- If width&height are both empty when the PAR preset is choosen in pulldown, then javascript will fill in the width&height
- if only one of them is allready filled, then no changes are done
TARGET
- same, only applies to width, mod is independant anyway

comments?

[krosswindz]

no, you would take the 'sampling matrix width';
http://lipas.uwasa.fi/~f76998/video/conversion/#conversion_table
(link is also on the calc)


Reading the table we have the following.

NTSC : 704x480 or 720x480 actual picture is 711x486
PAL: 704x576 or 720x576 actual picture is 702x576

Now the question is we want to use the source sampling matrix and not the actual active picture matrix in the calculation, am I right about this?

[smok3]

i meant this one for PAL
702 576 13.5 128/117 52.00000 702 576 Y Active picture frame for 625/50 systems in ITU-R BT.601-4 pixels.

however there is only small difference if you take the 704 version (remember i'am trying to keep things simple, to actually implement entire ITU crap, there would be a lot more of this input fields - which no-one would know how to fill up anyway (including me)).

[krosswindz]

i meant this one for PAL
702 576 13.5 128/117 52.00000 702 576 Y Active picture frame for 625/50 systems in ITU-R BT.601-4 pixels.

however there is only small difference if you take the 704 version (remember i'am trying to keep things simple, to actually implement entire ITU crap, there would be a lot more of this input fields - which no-one would know how to fill up anyway (including me)).

This one is for NTSC

711 486 13.5 4320/4739 52.66667 710.85 486 Y Active picture frame for 525/59.94 systems in ITU-R BT.601-4 pixels.

Does this mean for NTSC we should use 711x486 instead of 704/720x480. Unlike PAL, NTSC is neither here nor there.

Everything seems to get more confusing the more I read :(

[smok3]

just take (start with) sampling matrix width and PAR that goes with that, everything else is in 'analog' domain, at least that way you will have things simplified (you can safely ignore my naming convention if it is confusing, or suggest a better one....).

[krosswindz]

just take (start with) sampling matrix width and PAR that goes with that, everything else is in 'analog' domain, at least that way you will have things simplified (you can safely ignore my naming convention if it is confusing, or suggest a better one....).

I just use what the frame size of the source, I have seen only NTSC source, not PAL

for NTSC I just use NTSC (704), NTSC (720), NTSC Wide (704) and NTSC Wide (720), I guess it would be similar for PAL to as PAL (704), PAL (720), PAL Wide (704) and PAL Wide (720).

These are what one sees in softwares like dgindex etc.

[smok3]

and the calc got 500 'unique' hits just now, seems to be quite usefull :)

[smok3]

These are what one sees in softwares like dgindex etc
really? from dgindex docs;

MPEG2:
(1:1)
(4:3)
(16:9)
(2.21:1)
http://neuron2.net/dgmpgdec/DGIndexManual.html

[krosswindz]

really? from dgindex docs;


http://neuron2.net/dgmpgdec/DGIndexManual.html

http://neuron2.net/dgmpgdec/DGIndexManual.html#InformationPanel

Frame size is displayed here which is either 704x480/720x480/704x576/720x576

Aspect ratio tells you if it is 4:3/16:9

This is when using a DVD vob files.

Video type shows you if its NTSC/PAL

[smok3]

krosswindz; will go thought it (again) when i find some time...

edit: 704x480 and 711x486 are pretty close thought, so you can pick any as your starting point
http://resizecalc.somestuff.org/index.php?ssmw=704&sar=0.911&sar2=&ssmh=480&CT=&CL=&CR=&CB=&trw=712&dar=0.911&dar2=&mod=2&padw=&padh=&css=&doit=true

edit2: again, 704 is popular, since it is mod16 and in ntsc case seems to be very close to the truth.

[krosswindz]

krosswindz; will go thought it (again) when i find some time...

edit: 704x480 and 711x486 are pretty close thought, so you can pick any as your starting point
http://resizecalc.somestuff.org/index.php?ssmw=704&sar=0.911&sar2=&ssmh=480&CT=&CL=&CR=&CB=&trw=712&dar=0.911&dar2=&mod=2&padw=&padh=&css=&doit=true

edit2: again, 704 is popular, since it is mod16 and in ntsc case seems to be very close to the truth.

Off late I have been seeing a lot of 720 than 704. Not sure why this change.

[smok3]

1000 unique hits and no beer? wow, hard life as OS 'developer' :p

09b
.changed default.css to overcome new ff3 behavior where input boxes don't have priority anymore when overlapped with textual elements

[mikeytown2]

todo
- 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


I have a function that uses sub pixel accurate resize, as is described in that thread (V2), with the added benefit of setting the Source DAR & target DAR, and choosing to crop or add borders.
http://forum.doom9.org/showthread.php?p=1111789#post1111789.

Thought you guys would be interested in this.

Edit:
Example

a = AVISource("dvNTSC.avi").SeparateFields().SelectEven() #Load DV, Fast Deinterlace

ZoomBox(a, 720,480, SourceDAR=720.0/528.0, TargetDAR=16.0/9.0, Align=-5)#add borders
last + ZoomBox(a, 720,480, SourceDAR=720.0/528.0, TargetDAR=16.0/9.0, Align=5)#crop

NTSC DV source 15/11, going to anamorphic widescreen DVD 16/9

[smok3]

mikeytown2, interesting yes, what are the pros/cons as compared to non-subpixel method? (speed?, complexity?, ect)

[mikeytown2]

Short answer
Speed: slightly slower then doing it "by hand". (very minor)
Complexity: less complex then doing it "by hand".
Quality: when adding borders to a clip, there will no be hard edges, on the other hand there is no AR error. When cropping, this is the best way to go.
Interlaced: haven't played around with this since my projects so far have been for the web.

Long Answer
There is a slight speed hit, since it does a lot of arithmetic. When Cropping to fit, only a single resize function touches the clip. When adding borders I have to use AddBorders() and then do the single resize function. In both cases the resizer is dealing with more pixels then doing it "by hand", thus the resize is slightly slower.
I'm assuming complexity is referring to the scripts complexity, and the math involved. My code makes it much easier to change input sizes and output sizes. In the above example we are dealing with 4 different AR ratios. I changed the PixelAR of the DV clip without having to change the ZoomBox code, which is nice. If I want the target to be 4/3 DVD all i need to do is set TargetDAR=4.0/3.0. If the Source/Target DAR is not set then it assumes square pixels, so in this case 3/2 (720x480).

[smok3]

do 'we' have an autocrop (removal of black borders) feature hidden somewhere as well?

[mikeytown2]

do 'we' have an autocrop (removal of black borders) feature hidden somewhere as well?

no, there is no edge detection, but if you know the clips original dimension, it will act like it knows. So yeah you could say it's a hidden feature...

a = ColorBars().Trim(0,-1).AddBorders(100, 0, 100, 0)
ZoomBox(a, 640,480, align=5)
b = ColorBars().Trim(0,-1).AddBorders(0, 100, 0, 100)
last + ZoomBox(b, 640,480, align=5)
last + ColorBars().Trim(0,-1)

[smok3]

09f
.slight default.css changes
(looks almost good in IE now as well, remaining IE-only problems:
- pulldown selectors are still cliped
- resolution labels are non-responsive, sometimes double-clicking will work, sometimes not, this could be fixed with some better js i guess) fixed!, (thanks to people on dalnet/#javascript)

Other browsers retested
- FF 3
- opera
- safari
- lynx nix
- lynx win

Analog browser pie for jul08
http://blog.somestuff.org/images/browsers_resizecalc.png
(obviously msnbot should not be there)

----------

10
.echo mplayer command line

10b
.mplayer style cropping (width:height:left:top) - This is pretty dumb right now, will need some better input checking. Also if Left and Top are undefined then it should center the crop automagically.

10c
.favicon.png

[smok3]

4000 hits and i'am still thirsty :)

[krosswindz]

^ does the thirst ever end :p

[smok3]

i guess not, still thirsty with 5000 hits :P

[krosswindz]

@smok3 just a suggestion, how about having different mod values for width and height. Both defaulting to 16 if nothing is specified.

[smok3]

i'am totally bad with time, can you do it?

[krosswindz]

i'am totally bad with time, can you do it?

I made some modifications to index.php with what I think should work. You might want to code review it before updating it. You would have to look at the aesthetics as well :p

I am attaching a patch file with the differences. Hope the changes I did are the correct one.

[smok3]

i think this patch is reverse of what it should be?

-$modw = $_GET['modw'];
-$modh = $_GET['modh'];
+$mod = $_GET['mod'];

just post the new index.php.

[krosswindz]

i think this patch is reverse of what it should be?

-$modw = $_GET['modw'];
-$modh = $_GET['modh'];
+$mod = $_GET['mod'];

just post the new index.php.

I used diff to create the patch file, basically gives the differences between the two files - ->lines in new file and + -> lines in old file. I should created the diff file swapping the. I am attaching the index.php itself.

You might have to work a bit on the aesthetics of the page ;) I am sure my modification breaks it.

[smok3]

what i think is missing is:

- compatibility with old mod system (old urls must still work, so there need to be some sort of patching from old mod to modw and modh), like

if mod = somevalueotherthanNull then
modw = mod
modh = mod

here is a diff right now:

http://resizecalc.pastebin.com/pastebin.php?diff=f7779fc5b

alpha demo: current state, krosswindz edition, for testing only;
http://resizecalc.somestuff.org/alpha/
(I will fix html later when all the logic is ok)

[krosswindz]

^ very true, I do understand the compatibility with previous urls.

I think the following changes should help. Not sure about the php syntax though

replace lines 311-312 with

if (!empty($mod)) { $modw = $mod; $modh = $mod; }
if (empty($modw)) { $modw = 16; }
if (empty($modh)) { $modh = 16; }


I updated the pastebin (which I figured after making a new post :o). I also added a line to ask people to update their bookmarks (if mod = somevalueotherthanNULL)

the diff is here: http://resizecalc.pastebin.com/pastebin.php?diff=f50b678e4

[smok3]

ok, pastebin is giving me some problems, so next alpha sources are here;
http://somestuff.org/downloads/resizeCalc_php/alpha/
demo, same link
http://resizecalc.somestuff.org/alpha/

changes:
- urls should be backward compatible (hopefully) - also this should be transparent for the user, no need to echo warnings imho.
- some html for the new modh, modw

[krosswindz]

^ I just clicked on the example on PAL (702) to square mod(1) resizing it seems to work without any problems :). There is only one issue being that we need to get 1 printed for mod w & h like before.

[smok3]

yes, i will change the example (if you mean that?), any other issues?

[krosswindz]

yes, i will change the example (if you mean that?), any other issues?

I wasnt suggesting changing the example. It was more like when you click on the link which only suppors mod and now mod w & mod h you can see the value of mod being displayed. It would be nice if we could some thing similar to it is what I meant to display the values of modw and modh which we have taken from the value of mod.

[smok3]

that would mean the rewrite of the whole 1st part, so no.
New 'release' is now on the default url.

11
.krosswindz's modh, modw
.fixed the example and add one more :P

11a
.changelog will be from now on included with sources as neat little - changelog.txt

p.s. i never use the mplayer code, so this will be removed in next release (complain here if you do mind).

[krosswindz]

:thanks: html does look much better.