Implications of cropping

[Konstantin Prinz]

It's my priority to get the best available quality from the DVD into my appleTV. I've found that on my setup I cannpt tell the difference on bandwidth beyond 2500 so I stick with that (2100 for TV). So far, so good.

BUT, what are the implications of cropping?

Example: Let's say I rip movie X. It's anamorphic. In needs cropping of 16 at bottom and 16 on top. Picture size need multiples of 16, so this is ok.
But I'd also like to crop 2px from each side. However, when I do that, the movie gets stretched and the output ist still 720 wide and not 716, which is really what is left from my input.

So, when I encode movie X with cropping 2px from each side, what happens transcoding wise? Are all the pixels now stretched and I'm loosing image quality due to this?

I'm trying to grasp the technology behind it and by this it's implication on the resulting output quality.

Looking forward to a technical drill down

[jbrjake]

Example: Let's say I rip movie X. It's anamorphic. In needs cropping of 16 at bottom and 16 on top. Picture size need multiples of 16, so this is ok.
But I'd also like to crop 2px from each side. However, when I do that, the movie gets stretched and the output ist still 720 wide and not 716, which is really what is left from my input.

Uh, I don't understand.

If you're using anamorphic, there is no possible way your output is still 720 wide after cropping 4 pixels. The very first thing the anamorphic part of work.c does is hard-set the width to title-width (720) minus left croping minus right cropping.

You are, however, still resampling -- just to the same size. So yes, there is minimal quality loss whenever you crop.

[Konstantin Prinz]

Sorry if I'm not making myself clear, I'm in the midst of grasping the whole concept, so my terminology might not be consistent.

here is what the GUI says:
Source = 720 x 576 (I understand that, regular PAL)
Output = 720 x 544 (720 cropped 2/2=720 ??? There are only 716px left... 576 cropped 16/16=544 ok)
Anamorphic Output = 1024 x 544

So I do see my 16 cropping top/bottom reflected, but not my 2/2 on the side. You say there is no stretching and the code is hard setting the picture width. Is that just the GUI telling me wrong, then?

uhm, resampling?

Please explain some more.

[jbrjake]

Is that just the GUI telling me wrong, then?

Exactly. I just fixed this in revision 745.

uhm, resampling?

From wikipedia:

A digital image is known as a bitmap, it being a literal map of which pixels are what value, to construct an image. (This is not to be confused with the BMP image file format, which is a method of storing bitmaps in file data. PNG, JPEG and GIF are other equally valid methods of storing bitmaps.)

A bitmap is said to be sampled on each pixel, rather than being supersampled (more than one point of data per pixel) or subsampled (less than one point of data per pixel). Resampling this bitmap involves creating a sample grid, which is overlaid on the pixels. According to how far each grid point is away from the original centre of each pixel, and according to whatever resampling algorithm is in use, the new sample point is given a colour value.
...
The simplest method is known as nearest neighbour or point sampling. The closest pixel center to each sample grid point is used, with no input from other surrounding pixels.

So scaling is resampling to different dimensions. When you crop, you resample to the same dimensions. Now, HandBrake does a lot better than "nearest neighbor" sampling but any resampling introduces quality loss, because you're really getting that grid overlay's reproduction of the bitmap, not the original bitmap with the cropped parts shaved off.

Superdump is working on getting us a much, much better scaling/resampling system.

[Konstantin Prinz]

Thanks jbrjake!
Now my thirst for knowledge is quenched. However I hate to hear that I need to hold off from ripping my DVDs just yet, because HB will be getting soo much better in the near future