https://bugs.kde.org/show_bug.cgi?id=497435
--- Comment #26 from Ron <kdenlive-b...@contact.dot-oz.net> --- (In reply to Jean-Baptiste Mardelle from comment #23) > We need to keep the nearest rescale ... in some cases users want such > scaling (when upscaling pixel art for example). Ok, that makes sense. I'm fine with "sacrificing" nearest for that use case. I'd pondered whether a 'none' option might be worth adding if there was a case for not using the QPainter smoothing - but in this light I don't think so - anyone who really cares about smooth is going to use one of the stronger interpolation methods. And with this patch, nearest isn't jittery, it's just stairsteppy, as you'd expect (and for that use case want). > I have also spent quite some time to figure out the issue there. My changes > that introduced the bug, changing b_width and b_height in filter_qtblend, > were part of an optimization. With this change, instead of always requesting > a full frame image from the source producer, we ask for an already scaled > from from the producer. But despite all my attempts, with this technique, it > doesn't seem possible to get smooth zoom, as the producer return images with > integer sizes. Yeah, I think that's the crux of it (and the classic gotya with floating point), there may be a class of transforms you could optimise that way, but in the general case and for continuous small subpixel motion, the loss of precision in the intermediate calculation can add up to much larger errors in the final result. If we're going from integer pixels to pixels, the whole transform has to be done in a single step. > The attached path seems to make it work correctly for me. Could you please > test ? I think we're looking good! Or at least I've run out of ways for now to make something look broken with this one. I'll attach my diff as applied to current mlt head (32abe16667). There's no substantive change to what you did, but has a couple of little extra things I saw along the way: - fixes the file name in the filter_qtblend.cpp header. - merges the tests for setting hasAlpha into a single statement. - drops an apparently vestigial "if (error) return error;" - because nothing changes the initialised value of error before that point. - merges setting hqPainting into a single statement, and adds a comment about why nearest is excluded, so people don't wonder if it can be 'optimised' like I did :) The janitoral stuff can be split into separate commits for pushing to mlt, but it's obvious enough that I've left it all one diff instead of making it a patch series. > And thanks for your patch, my solution is based on your results ! Thanks for the sanity checks and the clues along the way! I'd felt a little guilty about initially handwaving this away as "expected and normal" in the forum before I saw the tests that Roxane had posted and realised it was quite real - and there's only really one way to atone for that :) It's good to get to know this code better, I've been a happy user for quite a while now, and this lowers the bar for looking into some of the other glitches I've been noting on the forum which I keep promising Bernd I'll get around to filing real bug reports for :D -- You are receiving this mail because: You are watching all bug changes.
