There is more about cropping than meets the eye...

[Acaila]

I've followed this thread closely because some very interesting results have been showed so far. After reading it all I decided to do some tests of my own. Hence this post.

I've done a test to see what the effects of cropping the height are with certain MOD's. And what the effects of these different resolutions were when resized to a correct aspect ratio compatible resolution (704x288).
I didn't crop the width, because for most movies this isn't needed anytway.


Test conditions:
Movie: Pearl Harbor (500 frames somewhere in the middle)
Codec: Xvid 1-pass quality 100%
Original Resolution: 720x576 (PAL 16:9)

Crop Width Height H-MOD Size(MB) After Resize(MB)
0 720 576 32 25,4 16,5
4 720 568 8 29,4 16,9
8 720 560 16 26,5 17,3
12 720 552 8 29,4 17,7
16 720 544 32 25,3 17,8
20 720 536 8 29,4 18,0
24 720 528 16 26,5 18,2
28 720 520 8 29,4 18,4
32 720 512 32 25,3 18,8
36 720 504 8 29,4 19,0
40 720 496 16 26,4 19,4
44 720 488 8 29,4 19,8
48 720 480 32 25,3 20,0
52 720 472 8 29,4 20,3
56 720 464 16 26,4 20,6
60 720 456 8 29,4 20,9
64 720 448 32 25,3 21,3
68 720 440 8 29,4 21,5
72 720 432 16 26,2 21,5
Between these values the black bars end and the movie begins
76 720 424 8 28,9 21,7
80 720 416 32 24,3 21,6
84 720 408 8 27,8 21,6
88 720 400 16 24,4 21,7


Some things definately stand out:
While in the black area, size remains constant no matter how much you crop when you stay with equal H-MOD's. H-MOD 32 seems an absolute must to get the smallest file.
After you've cropped all the black bars, cropping further into the image (still talking about not resizing) starts to decrease filesize with equal H-MOD's.
When you resize, the original cropped resolution becomes irrelevant, except that the more black remains in the frame the smaller the file is. This seems logical because black can be compress much better than color. No relation to H-MOD is visible anymore.
When you resize, after all black bars have been cropped out of the frame the filesize remains constant no matter how much of the actual movie is cropped away. Filesize would probably depend on resize resolution at this point.

Based on the cropping-only results I would conclude to always crop to H-MOD 32 resolutions. However after I did the resizing it seemed that the cropping didn't matter anymore...

I'd love to hear some opinions/comments on this.

[sneeky]

@Acaila:

I find you results reaffirming. I note the exact period in
the compression sizes before resize is exactly what I have
seen. The difference in my samples up to now, if tested as you
test, MOD8 repeats as best size instead of worst size. Don't
fret over this as I have more data showing the pattern you
have seen as well. It seems to exist as a +/- syndrome. But
always aligned on grid of 8x8. I have preliminary results
indicating that bilinear resize destroys the pattern
sensitivity like you observe in your tests.

One question though. Did you use bilinear or bicubic resize?
Neutral or sharp if bicubic?

[sneeky]

Another Movie with Pattern Sensitivity...

The interesting thing about this sample is that it demonstrates an
opposite mode compared to the previous samples. This suggests a few
things.

1. A different matrix alignment mode in the encoding process. I find
this to be less probable due to the nature of encoding process.

2. Some pre-encoding process/filter that can influence the the
encoding process in a +/- fashion. I find this more probable. This
could also explain the wide variations in the Pattern Sensitivity.
(suspects.. sharpness?)

I note that the 3 movie samples exhibiting the same Direction
Pattern Sensitivity were all Warner Bros. releases. The BraveHeart
sample here, that shows the opposite direction Pattern Sensitivity, is
a Paramount release.

Test Procedure:

-Select DVD video sample for encoding.
-Create DVD2AVI (720x480) project without cropping and feed to VirtualDub 1.4.8.
-Use Null Transform filter to perform various crops.
-Encode using Xvid CVS 02-27-02 codec (source=Nic).
-Use "one pass - quantizer" mode.
-Record each encoding session file size.

-No resize or other filters allowed.

BraveHeart, chapter11 (region1, widescreen)
Active Picture size (720x360), remainder is black bars

Data:

Quantizer 3

move window vertical....................move window horizontal

-704x384 (08,08,48,48) 401.7MB..........-704x384 (08,08,44,52) 408.5MB
-704x384 (08,08,47,49) 404.4MB..........-704x384 (07,09,44,52) 410.3MB
-704x384 (08,08,46,50) 406.5MB..........-704x384 (06,10,44,52) 410.8MB
-704x384 (08,08,45,51) 406.5MB..........-704x384 (05,11,44,52) 410.5MB
-704x384 (08,08,44,52) 408.5MB..........-704x384 (04,12,44,52) 411.5MB
-704x384 (08,08,43,53) 406.5MB..........-704x384 (03,13,44,52) 410.2MB
-704x384 (08,08,42,54) 406.7MB..........-704x384 (02,14,44,52) 411.5MB
-704x384 (08,08,41,55) 405.3MB..........-704x384 (01,15,44,52) 410.5MB
-704x384 (08,08,40,56) 403.3MB..........-704x384 (00,16,44,52) 408.4MB

worst, best window

-704x384 (08,08,48,48) 401.7MB
-704x384 (04,12,44,52) 411.5MB

[Acaila]

@Sneeky:
I used Sharp Bicubic for the resize.

My guess is that resizing destroys any pattern that resulted from cropping. Any kind of resizing.
It's possible that the different resizing methods result in patterns of their own, which override the crop-pattern.

Have you tried different resizing methods on samples that were cropped the same, and did you see a pattern evolving?

[duartix]

What's funny about this is that in my tests, which were second generation rips, the Patrix (the Pattern Matrix :scared: ) has always given me bigger differences than yours:

.............Horiz. MODS..........
CODECS....M32.....M16......M8
divx3..........0%....+36%....+57%
DivX4........-1%....+23%....+35%
XVid.........-5%....+23%....+32%
Acaila Test
XVid...........0%.....+4%....+16%

So why is it far worse with second generation rips? Five minutes (yeah right) please, so I can test something...

I've just bloody wasted down about half a bloody hour and my post just because of this bloody board and my frustrated atempts to align the bloody text.:mad: :mad: :mad:

Well, to sum it up:
Source: Same Bruce Lee's Rip.
Codec: divx 3.11.
Keyframes every second. (With a purpose)
NO = 352 height (no crop)
M32 = 352-16-16
M16 = 352-8-8
M8 = 352-4-4
Results are filesizes in KB of Key frames and Delta frames.

KFrames:
NO......257
M32....258...(+0%)
M16....259...(+1%)
M8......270...(+5%)

DFrames:
NO......2639
M32....2648...(+0%)
M16....3678...(+39%)
M8......4554...(+73%)

Well it didn't turned out quite what I expected (KF size constant) but you can see that DF suffered big time. I can't begin to guess what to blame, if the textures or the motion vectors, but now that I think about it, I would sure put my money on the motion vectors because and just because the KF size didn't raise as much, and I suppose KF are nothing but texture data...

[avih]

i'm breathless. just read the thread from it's start :)

regarding 2nd generation encoding (encoding from dvd falls into this category, albeit with lesser effect - very high bitrate mpeg2)

the source (beeing already encoded) contains sharp edges on blocks (8x8) bounderies. hence deblocking is often needed for playback.
when re-encoding, deblocking isn't applied. i suspect that even if that artefact isn't extremely visible, it has a strong effect on compresability *** if these sharp edges are positioned INSIDE (instead of between) the blocks of the newly encoded clip. ***

this, since the mpeg-4 compresses each block (8x8) seperatelly, and if a block contains hi frequencies (=sharp edges) inside it, it uses considerably more bits.

naturally, when re-encoding an already highly compressed clip (from divx/xvid/other block based) the effect is amplified since this blocking is more noticable..

the black-bars, kinda falls into the same category. blocks which are entirely black, are VERY compressible, however, all blocks wich are partially black consume more bits because of the sharp edge (black->movie).


one posible sourse of trouble and inconsistant results might be the fact that <b>black border edges might not align with original mpeg-2 blocks or with eachother</b>

hence moving the crop window (with black border) vertically might align top-black-border, and misalign mpeg-blocks and/or bottom-black border or other similiar ways -> inconsistant results.

thus, when conducting these test, imho, black borders should be cropped completely (at least MOD8) (including the top-most movie line and bottom-most movie line, just to be on the safe side).

now moving the window will effect only the block allignment issue (of re-encoded clip).

same applies to horiz cropping (are there right/left black borders on a dvd??)

i hope there's some sence in what i'm saying here. just my 2 cents.

side note: yes, resizing does effect compressibility considerably, therefore, i think all tests should be done without resizing at all. that takes out one more factor from this mess :)



regards
avi

ps
fascinating thread :)

ps2
i would have done some testing myself, but i don't have dvd-rom :(

[FH2]

Originally posted by ChristianHJW

Next thing i'd like to know is what happens if you cut away the black bars from the original pic ( as precisely as possible ) and resize to a picture being multiples of 32 pixel in width and height, even if aspect ratio is screwed this way ? We could compare to another encoding with same width ( 32 ) but height being 8 or 16 pixels smaller. The number of total pixels is of course higher in 1st case but not much and its interesting to learn about filesizes.


I did something like that. I've taken a File which had full DVD resolution (720x576) and I cutted away the black bars. In the first test, I've set the horizontal resolution to 512 and the vertical resolution between 256 and 320. (first table). In the second test I've set the vertical resolution at 288 and the horizontal resolution between 480 and 544. (second table)

Both time I used XviD (Koepi's Build from 12.03.2002) and Virtual Dub using 1-Pass-Quality Mode set to 100%. Here the results:
http://mitglied.lycos.de/semonilion/xvid_32.jpg

Comment to the first test: I could see no difference between a resolution being a multiple of 16 or 32. But using a multiple of 8 (which is not a m. of 16 or 32) doesn't take much less space as if you give it another 8 pixels.

Comment to the second test: Also here no difference between 16 and 32. But in this case, i takes much more space if you don't any of these multipliers.

P.S. sorry for the bad english, i try my best to make it understandable for everyone.

[crAss]

Well one thing came into my mind after reading this thread. Let's take as granted that we are resizing the film.
What if we crop exactly where the black bars are so the pixel isn't MOD8, MOD16 or MOD32, and then resize the film at a resolution that is MOD32. Are we going to see the same results posted here???
I will do some testing

crAss

[trbarry]

the source (beeing already encoded) contains sharp edges on blocks (8x8) bounderies. hence deblocking is often needed for playback.
when re-encoding, deblocking isn't applied. i suspect that even if that artefact isn't extremely visible, it has a strong effect on compresability *** if these sharp edges are positioned INSIDE (instead of between) the blocks of the newly encoded clip.

Does this mean we should all be running some sort of deblocking filter in DVD2AVI or Avisynth or something?

For instance I wonder if recoding XviD files using deblocking in Nic's xvid.ax as a DirectShowSource input to Avisynth would correct this.

- Tom

[avih]

tom, i was marely suggestive.
i didn't say it IS the problem, just mentioned that by moving the clipping window, u MIGHT have 3 different minima alignments (per axis): i.e. on the vert axis:
one for top black border
one for bot black border
one for blocks of original encode

of course, as the clip is of higher quality (as dvd's are) the 3rd alignment problem is somewhat diminished.

also, if applying deblocking does reduce the size, it doesn't neccesarily mean that it's the blocks that caused the oversize. that, since the deblocking filter is not optimal, and filters anyway, regardless (with some respect actually) of actual blocking artefacts. and it's a known fact that filtered clips produce smaller sizes.

cheers
avi.

ps.
GREAT work on nic's ds filter. ;) !

[sneeky]

OK, so I am slow to getting the data out. I hate the task of doing the
matrix of testing. But I chose the Blade Runner movie sample because it
has black bars all around, both sides and top & bottom.

I tested looking for re-encoding (3rd generation) pattern sensitivity.
I find this to be the most interesting aspect of this issue. If you were
to use these types of codecs for capture, and subsequently wish to do
any "Non-Linear Editting" (NLE), than you can expect to encounter this
issue quite a bit. Some data indicates that resizing destroys this
sensitivity, and maybe other filters do too. But this substantiates
Duartix's original observation.

The data is composed of the ORIGINAL TEST on this movie sample as
transcoded from the DVD. Then, specific "worst/best" case samples were
selected for study. The worst/best samples were trancoded from the original
DVD source and this created the 2nd generation sample to be re-encoded,
creating a 3rd gen sample. To expose the pattern sensitivity, the crop
window was moved diagonally, pixel by pixel across an 8x8 matrix. I used
a diagonal crop movement since it exposes the same pattern sensitivity
with less data. In all cases, the active movie area is always the same
because all the cropping takes place in the black bar areas.

The results indicate a greater pattern sensitivity in the 3rd generation
encode (the re-encode) than the 2nd generation (the transcode).

The 1st generation is the DVD.
The 2nd generation showed "worst/best" of 32.9MB/28.2MB = 117%.
The 3rd generation showed "worst/best" of 26.0MB/19.3MB = 135%.

TEST PROCEDURE:

-Select DVD video sample for encoding.
-Create DVD2AVI (720x480) project without cropping and feed to VirtualDub 1.4.8.
-Use Null Transform filter to perform various crops.
-Encode using Xvid CVS 02-27-02 codec (source=Nic).
-Use "one pass - quantizer" mode.
-Record each encoding session file size.

-No resize or other filters allowed.
==================================================

DATA:
==================================================

Chapter5 of Blade Runner (region 1 - widescreen)
Active Picture size (654x348), remainder is black bars
Crop numbers are (##,##,##,##)=(left, right,top,bottom)
Quantizer 2 all samples.


==================================================

ORIGINAL TEST DATA showing pattern sensitivity...

move window vertical .................. move window horizontal

-704x384 (08,08,48,48) 32.8MB ......... -704x384 (08,08,48,48) 32.8MB
-704x384 (08,08,49,47) 29.7MB ......... -704x384 (09,07,48,48) 30.3MB
-704x384 (08,08,50,46) 29.7MB ......... -704x384 (10,06,48,48) 30.0MB
-704x384 (08,08,51,45) 29.2MB ......... -704x384 (11,05,48,48) 29.7MB
-704x384 (08,08,52,44) 29.3MB ......... -704x384 (12,04,48,48) 29.7MB
-704x384 (08,08,53,43) 29.1MB ......... -704x384 (13,03,48,48) 29.8MB
-704x384 (08,08,54,42) 29.5MB ......... -704x384 (14,02,48,48) 30.2MB
-704x384 (08,08,55,41) 29.6MB ......... -704x384 (15,01,48,48) 30.6MB
-704x384 (08,08,56,40) 32.5MB ......... -704x384 (16,00,48,48) 33.1MB

worst, best window

-704x384 (08,08,48,48) 32.8MB
-704x384 (12,04,52,44) 28.1MB
==================================================


RE-ENCODE TESTING ... 2nd generation ==>> 3rd generation ...
---------------------------------------------------------------

Transcode at worst sample matrix alignment... 2nd generation

Transcode (2nd gen) worst sample ...... -704x448 (08,08,16,16) 32.9MB

3rd gen Crop Numbers (##,##,##,##) refer to 2nd gen sample ...
Re-encode (3rd gen) matrix sample...... -688x416 (08,08,16,16) 26.0MB
....................................... -688x416 (09,07,17,15) 22.1MB
....................................... -688x416 (10,06,18,14) 22.3MB
....................................... -688x416 (11,05,19,13) 21.9MB
....................................... -688x416 (12,04,20,12) 22.3MB
....................................... -688x416 (13,03,21,11) 21.9MB
....................................... -688x416 (14,02,22,10) 22.4MB
....................................... -688x416 (15,01,23,09) 22.2MB
....................................... -688x416 (16,00,24,00) 26.1MB

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

Transcode at best sample matrix alignment... 2nd generation

Transcode (2nd gen) best sample ....... -704x448 (12,04,20,12) 28.2MB

3rd gen Crop Numbers (##,##,##,##) refer to 2nd gen sample ...
Re-encode (3rd gen) matrix sample...... -688x416 (08,08,16,16) 22.4MB
....................................... -688x416 (09,07,17,15) 19.7MB
....................................... -688x416 (10,06,18,14) 19.9MB
....................................... -688x416 (11,05,19,13) 19.3MB
....................................... -688x416 (12,04,20,12) 19.6MB
....................................... -688x416 (13,03,21,11) 19.3MB
....................................... -688x416 (14,02,22,10) 19.9MB
....................................... -688x416 (15,01,23,09) 19.7MB
....................................... -688x416 (16,00,24,08) 22.4MB

==================================================

[sneeky]

I didn't put this in the post above since that post contains
test info.

@Duartix

I note your previous test indicating that I-frames show less
pattern sensitivity, or at least thats what I conclude you are
trying to point to. I find this curious too. But now that means
alot more detail testing to corroborate. Thanks for making this
difficult.

It would be a nice follow-up to just do the worst/best case samples
from the above test using I-frames only. I'll see what I can do.

[sneeky]

Used the Blade Runner chapter5 DVD sample.
Tested several conditions looking for pattern sensitivity.
Used diagonal crop window scan technique on 8x8 matrix.

Summary:

=>@ Q=2, tested 2D Cleaner filter (1 dimension). Worst/Best = 24.5MB/23.4MB = 105%

=>@ Q=2, tested 2D Cleaner filter (2 dimension). Worst/Best = 21.2MB/21.1MB = 100%

=>@ Q=2, I-Frames only . Worst/Best = 77.8MB/74.4MB = 105%

=>Tested @ Q=5. Worst/Best = 6.67/6.07 = 110%



TEST SAMPLE:

Chapter5 of Blade Runner (region 1 - widescreen)
Active Picture size (654x348), remainder is black bars
Crop numbers are (##,##,##,##)=(left, right,top,bottom)


TEST PROCEDURE:

-Select DVD video sample for encoding.
-Create DVD2AVI (720x480) project without cropping and feed to VirtualDub 1.4.8.
-Use Null Transform filter to perform various crops.
-Encode using Xvid CVS 02-27-02 codec (source=Nic).
-Use "one pass - quantizer" mode.
-Record each encoding session file size.

-No resize or other filters allowed UNLESS NOTED!!!!
====================================================

DATA:
====================================================
Used Jim Casaburi's 2d Cleaner, settings one dimension x=1, y=0, T=10
Fixed Quantizer=2

-704x448 (08,08,16,16) 24.5MB
-704x448 (09,07,17,15) 23.5MB
-704x448 (10,06,18,14) 23.6MB
-704x448 (11,05,19,13) 23.4MB
-704x448 (12,04,20,12) 23.6MB
-704x448 (13,03,21,11) 23.4MB
-704x448 (14,02,22,10) 23.6MB
-704x448 (15,01,23,09) 23.5MB
-704x448 (16,00,24,08) 24.5MB

----------------------------------------------------------------------
Used Jim Casaburi's 2d Cleaner, settings two dimension x=1, y=1, T=10
Fixed Quantizer=2

-704x448 (08,08,16,16) 21.2MB
-704x448 (09,07,17,15) 21.1MB
-704x448 (10,06,18,14) 21.2MB
-704x448 (11,05,19,13) 21.1MB
-704x448 (12,04,20,12) 21.2MB
-704x448 (13,03,21,11) 21.1MB
-704x448 (14,02,22,10) 21.2MB
-704x448 (15,01,23,09) 21.1MB
-704x448 (16,00,24,08) 21.2MB

----------------------------------------------------------------------
Fixed Quantizer=2, I-Frames only

-704x448 (08,08,16,16) 77.8MB
-704x448 (09,07,17,15) 75.1MB
-704x448 (10,06,18,14) 75.2MB
-704x448 (11,05,19,13) 74.4MB
-704x448 (12,04,20,12) 75.2MB
-704x448 (13,03,21,11) 74.5MB
-704x448 (14,02,22,10) 75.2MB
-704x448 (15,01,23,09) 75.0MB
-704x448 (16,00,24,08) 77.8MB

----------------------------------------------------------------------
Fixed Quantizer=5

-704x448 (08,08,16,16) 6.67MB
-704x448 (12,04,20,12) 6.07MB