Should high quality alignment be the default when aspect ratios of sources match?

[jimalad]

Thank you for developing this tool.

I'm using 20241124 on Windows, trying it with 1080p to 720p downscale re-encodes (i.e. evaluating downscaling algorithm choice, codecs and compression settings etc.).
With default command line usage, I noticed what I thought was a subtle colour error and a 1-pixel or sub-pixel lateral shift on the re-encoded (right hand) side, but couldn't initially pin it down as the issue only jumped out with certain video content.
Adding "-r scale=1920:1080:flags={algorithm}" fixed it (presumably because video-compare no longer tries any alignment strategies when sources have exactly matching resolutions?), but I later realised "--hq-alignment" also fixed it.
I initially thought it might be tied-up somehow in the new 'T' key feature (should this have a command line option BTW?), but I now don't think that's related.
I wonder could the tool be improved to correctly align sources with the same aspect ratio (i.e. a common use-case) by default.

Here's minimal steps to reproduce...

# save ground.jpg (512px x 512px) from the page below as ground.jpg
# (I found the image via google image search, constraining to github.com)
# https://github.com/BabylonJS/Documentation/blob/master/content/toolsAndResources/assetLibraries/availableTextures.md
# SHA256: e3637cbd17d1f086f32ebdf21c8399b0bac9d6dccecae1bd2207482895e17678

# create a downscaled version of the reference image (512px x 512px > 384px x 384px)
ffmpeg -hide_banner -i ground.jpg -vf scale=384:384:flags=lanczos -frames:v 1 -update 1 ground_384.png

# test video-compare with default commandline usage.
# zoom in with '8' key and rapidly move the comparison wiper left to right to see the blurry sub-pixel shift more clearly.
video-compare ground.jpg ground_384.png

# fixed with "--hq-alignment"
video-compare --hq-alignment ground.jpg ground_384.png

# alternatively fixed by pre-upscaling the downscaled image
video-compare -r scale=512:512:flags=lanczos ground.jpg ground_384.png

[jonfryd]

Hi @jimalad,

I'm glad to hear you find the tool useful, and thank you for providing a detailed description of how to reproduce the issue.

I agree that, for your use case, the aliasing caused by bilinear scaling - resulting from only computing a weighted average of the 4 neighboring pixels - is very noticeable compared to bicubic interpolation, which utilizes 16 samples.

Perhaps we should drop --hq-alignment and replace it with --fast-alignment, which would prioritize speed instead. I'll give it some thought.