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. |
11th April 2009, 06:22 | #41 | Link | |
Banned
Join Date: Feb 2009
Posts: 136
|
Quote:
|
|
11th April 2009, 19:09 | #42 | Link |
The Crazy Idahoan
Join Date: Jun 2007
Location: Idaho
Posts: 249
|
Well, use 2000 kbps instead of 1400 kbps on the video then. Heck use 3500 kbps on the source rather then upscaling the image, and you'll get a better quality video then if you where to use 3500 kbps on the upscaled image.
I don't see why a bitrate higher then 1400 is unreasonable for a non HD source, Very often I will use somewhere around 2000 on non-hd material (CRF is awesome that way). If getting rid of jitters and better sharpening is the goal, I would suggest this. Upscale the image, do whatever processing you are doing now, and then downscale the image to its original resolution. Just make sure that when you upscale it you do it by an evenly divisible number (preferably a power of 2) to keep it from loosing data from the scaling. (this technique is somewhat the same as what your video cards do when they do anti-aliasing) For example, your 704x396 image could go up to 1408x792, and shouldn't loose any data from the scaling. |
11th April 2009, 20:38 | #43 | Link | |
Banned
Join Date: Feb 2009
Posts: 136
|
Quote:
|
|
11th April 2009, 21:02 | #44 | Link |
x264aholic
Join Date: Jul 2007
Location: New York
Posts: 1,752
|
@cogman: When you're working with real life type content, there's no real point in trying to upscale content (Unless you're doing something like combining HD and SD content). In Typhoon's case, where he's working with animated video, you can take advantage of nice resizers like NNEDI and get very good results.
I've done a few SD -> HD conversions on animated video, and it can come out very nicely, especially when displayed on a high res screen. Since I have the advantage of using high quality (but slow) filters to produce that HD output, I don't have to deal with the lower quality resizer built into many software players.
__________________
You can't call your encoding speed slow until you start measuring in seconds per frame. |
11th April 2009, 21:08 | #45 | Link | |
Banned
Join Date: Feb 2009
Posts: 136
|
Quote:
|
|
12th April 2009, 03:28 | #46 | Link |
Didée Fan
Join Date: Feb 2006
Location: Canada
Posts: 1,079
|
[QUOTE=Typhoon859;1253463]Believe it or not, I'm actually asking a question... More specifically though, what are the real differences between Spline16Resize for example vs. LanczosResize? QUOTE]
Play my test disks with either resizer and see which result you like better: http://forum.doom9.org/showthread.php?t=140747
__________________
When I get tired during work with dvd stuff i think of River Tamm (Summer Glau's character). And the beauty that is Serenity. |
12th April 2009, 03:57 | #47 | Link | |
Banned
Join Date: Feb 2009
Posts: 136
|
[QUOTE=Jeremy Duncan;1272748]
Quote:
|
|
12th April 2009, 09:08 | #48 | Link | |
Registered User
Join Date: Feb 2004
Posts: 1,348
|
Quote:
Interpolation with anything other then an integer power upscale with pixel duplication IE pointresize is lossy. Downscaling is always lossy, unless you are downsizing a previously pixel duplicated/pointresized image, by a factor of the original upscale integer, using either box or pointresize/pixel decimation. For all practical purposes interpolation is always lossy, but the loss is of managable size and very rarely easily noticible after only one or two interpolation operations with good linear interpolation. |
|
12th April 2009, 11:41 | #49 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
(If we number the original pixels 0, 1, 2, ..., then the output pixels correspond to positions -0.25, 0.25, 0.75, 1.25, ...) Interestingly (or maybe not ), it turns out that upscaling by an odd integer factor actually does preserve the original pixels amongst the interpolated ones. For example, for x3, we get pixels corresponding to -1/3, 0, 1/3, 2/3, 1, ... |
|
13th April 2009, 03:56 | #50 | Link |
Registered User
Join Date: Feb 2004
Posts: 1,348
|
iirc, even for 3x, 5x, etc. upscales, the center pixel is stil processed by some of the taps of the filter, IE, for 3x, the center pixel does not get processed by the main blurring lobe, but it gets hit by the following sharpening, and bluring lobes (assuming 3 tap interpolation), I'm not sure how the internals of the functions work, so the center pixels may be bypassed, but otherwise, it is as good as impossible to preserve any of the original pixels. Furthermore, even for 3x, etc. upscaling, you would have to use pointresize downscaling, selecting only the unprocessed pixel positions to get back to where you started, and If you do that instead of at least using box downsizing, their isn't any point in upscaling at all.
|
13th April 2009, 22:15 | #51 | Link |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
You're right that even for 3x, 5x, etc, it does depend on the filter kernel of the specific resizer used.
But actually, most of the resizers (when upsizing) do act as pure interpolators (their kernels have zero crossings at integer distances from the center), so source pixels are preserved where the resampling points coincide. The exceptions are BilinearResize with b/=0, and GaussResize (except for large values of p, >80 or so). You can demonstrate this with a script like this: Code:
function UpDown(clip c, int scale) { w = c.width h = c.height up = c.LanczosResize(w, h*scale) # or most other resizers up.PointResize(w, h, 0, (scale-1)/2.0) IsYV12(c) ? MergeChroma(up.PointResize(w, h, 0, scale-1.0)) : last } ... # set source orig = last UpDown(5) # or any odd number Compare(orig) (If source is YV12, an extra step is required because of differing chroma placement.) Of course, all this is of mainly academic interest, since I agree that the exercise is fairly pointless. |
16th April 2009, 06:58 | #54 | Link |
Registered User
Join Date: Aug 2007
Posts: 374
|
How YV12 chroma is processed that exact reverse require scale-1.0 offset? Also, can anyone explain what is the point of adding 0.001 to src_width and src_height that can be seen sometimes in the scripts, like this line:
TurnLeft().EEDI2().TurnRight().EEDI2().spline64resize(last.width,last.height,0.5,-0.5,2*last.width+.001,2*last.height+.001) |
16th April 2009, 13:26 | #55 | Link | ||
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
For chroma, we still need to pick out pixels 2, 7, 12, etc, but because in YV12 the chroma pixels are spaced twice as far apart, we need to double the offset, hence scale-1. Note: The UpDown function I posted above only does vertical resizing. For horizontal resizing, the same issue arises with YUY2 chroma. Also, I've since realised that for RGB the vertical offset should be negative since Avisynth processes RGB from the bottom up. For completeness, here's an extended version: Code:
function UpDown(clip c, int scale) { w = c.width h = c.height pixel = (scale-1)/2 up = c.LanczosResize(w*scale, h*scale) up.PointResize(w, h, pixel, IsRGB(c) ? -pixel : pixel) IsYV12(c) ? MergeChroma(up.PointResize(w, h, 2*pixel, 2*pixel)) : \ IsYUY2(c) ? MergeChroma(up.PointResize(w, h, 2*pixel, pixel)) : last } Quote:
|
||
16th April 2009, 17:52 | #56 | Link |
Registered User
Join Date: Aug 2007
Posts: 374
|
It doesn't make any sense to me why resizer won't internally account for different quantity of YV12 chroma samples. And in test case i get correct resizing with
PointResize(width/2,(height-128)/2,0,128,width,height-128) not with PointResize(width/2,(height-128)/2,0,128,width,height-128).MergeChroma(PointResize(width/2,(height-128)/2,0,256,width,height-128)) |
17th April 2009, 01:12 | #57 | Link |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
SEt, I think you and I are talking about different things here.
For 'normal' resizing (such as your example), you don't need to treat the chroma separately as the resizers handle everything for you, including the offsets (if any). I am talking about using PointResize in a special way to recover specific pixels from a 3x (or 5x, 7x, ...) upsized image, and here the chroma does need to be handled differently, for the reasons I have tried to explain. I am not saying that you need a different offset for chroma with PointResize in other situations. |
19th April 2009, 11:06 | #58 | Link | |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Quote:
|
|
|
|