Conservative Cropping not working correctly

[FCrane]

Problem Description

"Conservative Cropping" is my preferred auto cropping mode. Works fine, but very often it will crop 1 line of image data (not black) from either the top or bottom of the video (respectively left or right for the other axis). E.g. it selects 138 for top (correctly leaving 1 black line because video starts at 139) and 140 for bottom (incorrectly cropping 1 line of the actual video, which starts at 139). Sometimes it's cropping a line from the top, sometimes from the bottom.

Why does it do that? It clearly crops 1 line of actual video data from either side, when it should "conservatively" better leave a black line on both sides. I really prefer having some black lines around the video instead of losing video lines...

Activity Log, Crash Log or any other details

None

What Operating System are you running?

Windows 11

What version of HandBrake are you running?

Nightly 20231029154939-38876492f-master (2023103001)

Where did you download HandBrake from?

https://handbrake.fr/

[sr55]

Conservative crop won't prevent scenarios where there is consistent triggers of crop values across previews.

We'd need an extended log (enabled via preferences) to confirm nothing is wrong but it may just be that you need to manually crop such sources.

[FCrane]

Can't you make "conservative" really conservative? So that it only crops black lines? Or call it "preservative" or whatever - in my opinion this is the only reasonable way to crop if you want to preserve all video information!

When encoding BluRays, nobody would really want to discard any video lines, but the black bars only, of course.

[sr55]

I'd still like to see a log of an encode, with extended logging turned on via preferences just to see what it did.

[FCrane]

Here's a log of a test video, that has 1 black line at the top and at the bottom. Handbrake correctly sets the top cropping to 0 but incorrectly uses 2 for the bottom, cutting 1 line of valid video data... activity_log_main.18196.txt

[FCrane]

Here's another example: activity_log_main.19848.txt The video has 21 pixels of black bars at the top and at the bottom. Checking the log, Handbrake seems to correctly detect this, but then sets the cropping to 22 pixels in both directions, incorrectly discarding 1 line from the top of the video and 1 line from the bottom of the video! It should have selected 20 for both cropping values...

I'd really prefer it to preserve ALL video information and leaving a few lines of black pixels if necessary. The way it currently works is not "conservative" and essentially useless for me, because I always need to check the video and the cropping values manually anyway...

[FCrane]

Unfortunately, v1.7 does still not crop correctly... I tried a test video with 21 pixels black at top and bottom, and both "Automatic" and "Conservative" modes incorrectly cropped 22 pixels of both sides. Can't this be fixed?

[galad87]

Well, nothing was changed yet. Can you provide a short 10 second video we can use to test?

[FCrane]

You can use any mkv for example, that has an uneven (or unsymmetrical) number of black lines above and below (or left and right) the video. See my logs above: HB correclty detects the black bars but then incorrectly sets the cropping...

[FCrane]

Test.zip

This is a good example: the video has 131 black lines at the top and the bottom. Handbreak incorrectly sets 130 and 132 for the cropping values - it should use 130 for both so that no video information is lost!

[FCrane]

Test-177.zip

Another example: the video has 64 black lines at the left side and 63 at the right side. Handbreak incorrectly sets a cropping value of 64 to both sides - it should use 62 for the right side to not discard video info!

Maybe you should add a "Preservative" cropping mode that preserves all video lines?

Anyway, this is a bug that should easily (and urgently) be fixed...

[sr55]

Cropping is always mod2 and thus if you have an uneven source, you are likely to lose a line as a result irrespective of what crop algorithm is used.

Automatic / Conservative cropping don't change how crop detection works. Simply the set index used for the values chosen. It's goal is to better handled Mixed Aspect content.

I'd consider it a bug if it was deliberately leaving black lines in place, even if it that means loosing a line of content,

If we decide to do anything about we'd need to look at exposing advanced settings for the crop algorithm internals. I'm not sure this is something we'll do anytime soon I'm afraid.

[FCrane]

You could add an "Undercrop" option, for example. Undercropping is always preferrable to overcropping, because almost all display devices are 16:9 or 1:85:1 nowadays, so if a video needs to be cropped for conversion (e.g. to 2.35:1), you'll always have black bars on your display anyway! And I'd rather not loose any video lines to overcropping if I have black bars anyway...