po5 / thumbfast

High-performance on-the-fly thumbnailer script for mpv
Mozilla Public License 2.0
861 stars 35 forks source link

Fix odd thumbnail size #29

Closed christoph-heinrich closed 2 years ago

christoph-heinrich commented 2 years ago

Apparently scaling filters don't like odd resolutions, but always choosing even numbers leads to black borders. The solution is to generate thumbnails with a different resolution then they are being rendered in.

The idea is that we can cut off thing from the bottom when rendering, but we can't cut off things from the right side, so use the highest width we are allowed to, and then use the appropriate height for that width + whatever is needed to fill up to % 2 == 0. That might result in a black border at the bottom of the generated image, but we can simply cut that off when displaying it, resulting in no visible black borders while still adhering to the "no odd numbers" rule.

Currently it's using resolutions for generating that are % 2 == 0, but according to @Natural-Harmonia-Gropius it might be necessary to increase it to % 4 == 0. We'll see if it causes problems for anyone.

christoph-heinrich commented 2 years ago

Don't merge this... it might make things work for everyone, but it doesn't really solve the underlying problem. I have definitely had thumbnails work no problem with odd sizes before, which means odd numbers are not inherently the problem. But then I add or subtract an odd number from one dimension and it doesn't work anymore. Add or subtract an even number? No problem.

And it's not like there isn't an output file. it does write a file and even updates it. We just can't see it for some reason.

christoph-heinrich commented 2 years ago

":force_original_aspect_ratio=decrease" keeps screwing us. It "randomly" decreases the output resolution, and then thumb_size ~= info.size and nothing gets drawn.

I have observed it reducing the output height by 1 and I have also observed it reducing the output width by 2. It does not do that when width/height == effective_w/effective_h or when they are similar enough, but I don't know how we can properly account for that.

For anyone trying to tackle his, set the thumbnail size very small, then the aspect ratios are less likely to be the same.

christoph-heinrich commented 2 years ago

I've managed to get the real thumbnail resolution, so with that we should be able to reliably draw what's being put out. The remaining question is how to do that without black borders...

christoph-heinrich commented 2 years ago

I'm closing this, because the real solution will be fundamentally different and should thus be a separate PR.