PDA

View Full Version : Thoughts on cropping and borders


FredThompson
8th September 2003, 01:06
Caveat: This applies to interlaced source to be viewed, primarily, on televisions and NO change of resolution.

After chatting with DDogg, I've come to realize there's no good reason to crop and add borders. Sure, the edges are a little cleaner and the image might be more properly centered but it takes time and also makes sharp edges with black borders, something encoders don't particularly like.

Also, cropping and adding borders takes time, why bother?

IJM
8th September 2003, 12:36
Fred,

I suppose it all depends what your target format is. If your target format is for computer use, then you'd want to trim off the overscan areas along with any distortion. This would result in a slightly smaller file that would appear cleaner on playback.

If your target format is, for instance, DVD, then I suppose the only reason would be to save a little space. But you'd only achieve this if you trim to a macroblock boundary (otherwise, your encoder has a helluva time trying to encode you a nice straight edge and using up bitrate in the process). For a 720x576(480) capture, this means trimming 16 pixels from each side, leaving you with a 688x544(448) picture with a 16 pixel border on each side. I guess that this is pretty much all the overscanned information, and the chances are that you would then see some of the borders on a TV.

I don't know how much space you would save doing this. Unfortunately, I'm not currently in a position to test this. Maybe, someone else has this answer.

Now that you've made me think about it, for DVD, I guess that its easier just to leave it alone.

Ian.

ppera2
8th September 2003, 14:23
Best possible solution is to capture it borderless in standard resolution for DVD - 704 width. It depends much from capture card (chip) and particular TV program or video how big borders we have at left and right. Setting res. to 720 and cropping some pixels left and right (total 16) may be good solution - it's easy possible with V Dub. Virtual VCR has cropping by capture too. Sacrificing some 10 pixels per line and couple % of A/R is impercebtible in praxis.

Even best is adjusting with BT Tweaker, but it's only for cards with BT 8x8, plus some trouble with software installation.

ronnylov
8th September 2003, 15:22
Normally I capture at 704x576 (PAL) crop and then resize to 672x544 and then add black borders back to 704x576 (16 pixels on each side). I can't see any black borders on my TV after this when playing it in my standalone DVD player. If you don't like resizing you can as well just crop to 672x544 and add borders to 704x576 (or crop to 672x448 and add 16 pixel borders to 704x480 if you use NTSC). This can allow a lower bitrate with the same quality, but as said above it is important to use macroblock optimized resolutions (16x16) or at least block optimized (8x8). When going to half D1 I use 336x544 with 8 pixels black on left and right and 16 pixels top and bottom. If I use 16 pixels left and right border at half D1 I can see the black border on my TV.

I use FitCD when calculating macroblock optimized overscan resizing without destroying aspect ratio.

But maybe in the future when you buy a new TV the overscan may get smaller and you will see the borders again. Still this can save some bitrate when making low bitrate encodings like SVCD. Its up to you to decide if it's worth it. Remember to use interlaced resizing if your source and destnation is interlaced, or deinterlace before the resizing, or just crop and add borders.

FredThompson
8th September 2003, 18:36
@ppera2, how do you propose to capture borderless when the transmissions include borders.

I've also realized my initial statment only works if the source is very, very clean. If the source is from analog videotape it will have the head switching noise at the bottom which should be cropped. If you don't want CC, the top should be cropped. Once that is done, the AR is all wrong to may as well add borders ont he top and bottom...

ppera2
8th September 2003, 18:47
Originally posted by FredThompson
@ppera2, how do you propose to capture borderless when the transmissions include borders.


I thought that I explained it - capture at 720 and crop black borders by capture. Target res is 704, what is DVD compliant. Other way is with help of BT Tweaker. It's not theory, I capture so often.

I agree with part about cropping VCR junk...

FredThompson
8th September 2003, 23:24
Take a look at the first line of your earlier post. Perhaps what you typed and what you meant to communicate are slightly different. That's probably what happened in the DV->DVD thread. The reason I prefer to keep 720x480 is to keep the same AR (because it's never changed and yes, I know 704x480 is valid) and to have a little more of the source show on a TV.

Hmmm...come to think of it, I just realized I'm not leaving it at 704 when I'm making CVD. Darn it, I know better than that.

I just realized that just as we (everyone here on doom9) tend to forget to mention if the discussion is PAL or NTSC, we do the same thingw ith destination use. The comment above about viewing on a PC is valid but not my application.

ppera2
8th September 2003, 23:55
Fred:

What means 'capture' ? It should mean that we catch something and keep it. So, it's not about what res. we set by video format of capture card driver, but what res. goes to be stored. When I said borderless, it meant after cropping by capture.
I don't think that I formuled it bad, although I'm not too good with English - it's matter of logic. And it's explained later - cropping.

In case of horizontal res, it's same for PAL and NTSC.
And keep in mind that many TV stations doesn't comply ITU specs.

Ronnylov:
If target is watching on TV (via standalone), I think that avoid vertical resize, especially by interlaced video. It's almost impossible to correct resize vertically interlaced video, deinterlace is also inperfect. Also, I don't see why go to 544 vert? Usually there is max. 1-2 black line at top and bottom. With ATI TV out you will sure see all 576 lines (it has black 1 cm at top and bottom).

FredThompson
9th September 2003, 01:31
I see what you mean by "capture" but the more common usage, I think, is just the act of digitizing the analog source. Processing is another step.

To make an analogy, there is a difference between scanning a photograph and processing it into the final format.

You are correct that the word "capture" can, indeed, mean the entire process. It's not the most common usage, though.

Yes, English is full of multiple meanings and differences which makes it difficult for non-natives. It's the bastard language of the Western World.

You are absolutely correct about vertically resizing interlaced video. That is a horrible idea. Donald Graft's kernal deinterlacer is good but still, why change the format?

ronnylov
9th September 2003, 15:48
Originally posted by ppera2
Ronnylov:
If target is watching on TV (via standalone), I think that avoid vertical resize, especially by interlaced video. It's almost impossible to correct resize vertically interlaced video, deinterlace is also inperfect. Also, I don't see why go to 544 vert? Usually there is max. 1-2 black line at top and bottom. With ATI TV out you will sure see all 576 lines (it has black 1 cm at top and bottom).

Vertically macroblock optimized overscan cropping, PAL: 576-2x16=544
Horisontal macroblock optimized overscan cropping: 704-2x16=672
Since each macroblock is 16x16 pixels I choose to crop to 672x544 to make it easier for the mpeg2 encoder. All the black 16x16 pixel macroblocks needs almost no bitrate at all. I still can't see any of the borders on my TV because they are hidden in the overscan area. This is a method to save some bitrate. If I crop only 2 pixels then I get an edge within the macroblock and also within 8x8 blocks so this need a lot of bitrate to encode. But if the edge is exactly between macroblocks then this is like nothing for the encoder.

To resize interlaced video instead of only cropping you can use separatefields in avisynth and resize the half pictures and then weave them back together.
Here's an example of 704x576 interlaced video source with actual film pixel of 702x572 (at least 1 pixel left and right and 2 pixels top and bottom needs to be cropped). FitCD calculates following macroblock optimized interlaced resizing script for avisynth:

SeparateFields()
LanczosResize(672,272,1,2,702,284).Weave()
AddBorders(16,16,16,16)

To maintain aspect ratio it crops to 702x568 and then resize it to 672x544 by resizing each fied separately and weaves it back to interlaced afterwards. Then add the black borders. This works great for me.

When using ATI TV out I always enable overscan to avoid the black borders. This can be done with Rage3DTweak which enables an overscan button in the TV settings and activating overscan removes the borders on the TV. But normally I don't use ATI TV-out. I either play it on my standalone player or from the computer with a Hollywood+ mpeg2 decoder. I don't trust the interlacing of the ATI TV-out so I prefer my Hollywood+.

By the way, if you are capturing with ATI All in Wonder and ATI MMC there is a setting something like "capture cropped video" and this will crop black borders and enlarge the picture to full size. This is not a good method if you capture interlaced for TV playback but if you want real time capture for computer playback (deinterlacing enabled) without borders it may be worth a try.

ppera2
9th September 2003, 16:35
ronnylov:

Thnx for detailed reply. But you didn't get my point. I know about macroblock encoding stuff (I try always to do it dividable with 32).

But you loose almost 32 lines of video by reducing height. Maybe you don't see it with your TV settings. I always go that it must be watchable on computer too.

I know how to resize interlaced video ('by book' :) ). But it's far from correct resize. It reduces details etc. Resize can't be good when is made only at half of details. Better is with Smoothdeinterlace, doublerate=true, but it's slow, and still not perfect.
Point is that couple black line at top and bottom will cause much less errors than incorrect resize or deinterlace. Not to mention faster postprocessing.

ronnylov
9th September 2003, 17:49
Originally posted by ppera2
ronnylov:

Thnx for detailed reply. But you didn't get my point. I know about macroblock encoding stuff (I try always to do it dividable with 32).

But you loose almost 32 lines of video by reducing height. Maybe you don't see it with your TV settings. I always go that it must be watchable on computer too.

I know how to resize interlaced video ('by book' :) ). But it's far from correct resize. It reduces details etc. Resize can't be good when is made only at half of details. Better is with Smoothdeinterlace, doublerate=true, but it's slow, and still not perfect.
Point is that couple black line at top and bottom will cause much less errors than incorrect resize or deinterlace. Not to mention faster postprocessing.

I agree, this method is only good for watching it on TV only and when you want a low bitrate (and loosing details is also good when encoding to lower bitrates, that's why half D1 is OK at lower bitrates than full D1). You loose some details but you also see more of the picture (whats hidden by overscan) by overscan rezising. And if you want it dividable with 32 then 720 is not a good value.

Another thing worth to mention is that 720x576/480 and 704x576/480 both use the same aspect ratio (according to ITU-R BT.601-4) so you won't destroy the aspect ratio by only cropping the sides from 720 width to 704 width. But all capture cards are not according to ITU-R BT.601-4. For instance when capturing to avi with ATI AIW and virtualdub you get a more correct aspect ratio with 704x576/480 than 720x576/480. But in theory both resolution should use the same aspect ratio. Theory and reality does not always mix.

Boulder
9th September 2003, 20:05
Originally posted by IJM

I don't know how much space you would save doing this. Unfortunately, I'm not currently in a position to test this. Maybe, someone else has this answer.


I did a small test on a clip from Monty Python's Meaning of Life DVD some time ago, trying overscans of 0, 8, 16 and 24 pixels. I resized the clip to get the AR error less than 2% in every case.

Here's the script:


MPEG2Source("e:\temp\dvd-rip\python.d2v",idct=5)
Crop(10,82,-10,-86)

SimpleResize(480,416)
AddBorders(0,80,0,80)

#SimpleResize(464,416)
#AddBorders(8,80,8,80)

#SimpleResize(448,384)
#AddBorders(16,96,16,96)

#SimpleResize(432,384)
#AddBorders(24,96,24,96)


The results:

0 pixels: 19 979 667 bytes
8 pixels: 19 809 823 bytes
16 pixels: 18 646 548 bytes
24 pixels: 18 418 530 bytes

Here we can see that even 8-pixel borders increase the compression. When the borders fill one complete macroblock (16 pixels), the compression is quite big, as would be expected. My TV crops about 24 pixels off the sides and about 20 at the top and bottom at resolutions 480x576 and higher so I use 3 overscan blocks. At smaller resolutions, 2 overscan blocks do the trick. I suspect that I could create DVDs with 3 overscan blocks and wouldn't see the borders on the left and right sides. I don't mind having them on the top and bottom;)

Some food for thought here..