The importance of correct cropping

[theReal]

I knew that not cropping away some black bars at the top or bottom of a video does make it less compressible, but I didn't know by what amount, until now...
I made a compress test in Gordian Knot with a movie resized to 640x272 from 712x272 (non-anamorphic DVD, NTSC).
The cropping to 712x272 had left a thin black line at the top of the picture - I would have cropped it away if the resolution had not already been at 272, and I did not want to enlarge the picture.

So, a compress test without any filters (except ivtc, cropping and resizing), using VDub's precise bilinear resize gave a compress test value of 56.2%

Because I was interested in how much I would gain from cropping away the black line, I cropped it, so the resolution now was 712x271 before resizing, only one line less.
I repeated the compress test, expecting to get 1 or 2% higher, but the result was an amazing 64.1% !!!!

Cropping this one black line had improved the compress test by almost 8% - I couldn't believe it (that's why I wanted to share this).

[Emp3r0r]

I'm not surprised, thats 712 less pixels to compress ;)

[TheXung]

I'm not surprised, thats 712 less pixels to compress
You skipped over where he said he resized it afterwards. You can't have an odd number resolution.

[theReal]

I think he knows because he put a ;) behind it :D

But however, just for clarification in case anybody got it wrong:
The encoded resolution was 640x272 both times, only the first time there was a tiny black line at the top while the second time the video was stretched a bit so the line wasn't there anymore.


btw. in the meantime I changed the final resolution to 640x264 but this only improved the compress test by less than one percent!

[bb]

It's not the 712 pixels that make the difference. It's the sharp edge between the black line and the picture which eats up the bits. All DCT codecs are sensitive to sharp edges (therefore anime is hard to encode, too).

bb

[trbarry]

Sometimes it is desirable to have size multiples of 8, 16, etc. for various codecs. And sometimes you just don't want the possible softening or image alteration of a resize. So you would be tempted to leave in a little border.

But if that border either contained garbage or hard to compress black edges then maybe it would be possible to write a filter that replaced that border with whatever pixel values were on the edge of the real image. This would probaby look better and also compress better.

Say you had a 3 pixel border on all sides that was either black or full of static. You could replace this on the left for instance with the a value filled in from the 4th pixel. And the top 3 lines would be filled in from the 4th line, etc. All this would run up against the edges of the display anyway and would not be not be too noticeable. It almost certainly would look better than static. And it would compress better than the same size image with borders.

Just an idea, maybe a dumb one.

- Tom

[bb]

@trbarry:
That sounds interesting, and I have thought of that a few months ago (but I didn't tell anybody: shame on me!). You could find some source in the DeLogo filter, I guess.

bb

[-h]

But if that border either contained garbage or hard to compress black edges then maybe it would be possible to write a filter that replaced that border with whatever pixel values were on the edge of the real image. This would probaby look better and also compress better.

The MPEG family already does this with the right/bottom borders when an odd-shaped image is sent, to pad it out to a multiple of 16 (see image_setedges() in image.c). XviD is supposed to be able to encode resolutions like 642 x 273, but last time I checked it was still broken.

-h

[Emp3r0r]

oh, i missed the resizing part afterwards :eek:

I think that filter idea would be very useful for those who wish to avoid resizing alltogether.

Is there lots of people who keep DVD resolution or do they resize to 640 like I do?