ECMAScript resize increments on canvas with requestAnimationFrame

I question inconsistent output from cv.resize. I animate particles and blur to simulate depth. Blur seemed too coarse, so I resized at 0.999 or 0.99 percent and then resized back to original. My intention was to use smooth canvas subpixels. The LINEAR output revealed a quadrant grid.

My edge-case question is what is the method to sanitize a transform tween? That may not be within the scope of this forum. I am exceeding 10-bit fixed point arithmetic. A practical example is a Ken Burns background effect with an animation overlay. Is that not a problem because the difference is more pronounced?

Excessive thanks!

your post sounds confusing to me. is this due to language barrier? I would suggest trying again in your native language. native language + machine translation (both) might convey the meaning better.

I convey my confusion to gain insight through your experience and wealth of resources. For my purpose resize is inappropriate, and blur (which incorporates resize) is advised. I have read that blur adds blur as compared to an image pyramid. I am reminded that precision has a limit. These are practical reasons and the extent of my foundation when asking.

The concept which I personally encountered was small differences at quadrant boundaries. I realize this may be avoided by adhering to properly structured code. It’s trivial, but is there a term or resource for this topic? It occurred to me to ask a professional’s direction and share a use case. Perhaps these results are on the canvas side for me personally.

  1. is something better than INTER_LINEAR? _CUBIC and _AREA have the same effect.
  2. does a wrapper function or method exist which you would suggest?
  3. what determines the grid? It changes with dsize, canvas size and browser zoom.
  4. is there any relevant general overview page?

I don’t really care to dwell on these specific questions, but this is an attempt to rephrase my approach. Thanks again!

those “quadrant boundaries” you seem to describe are a result of sampling.

when you resize something to be 99%, an original 100 pixel distance results in a 99 pixel distance… and the pixels LINE UP every 100 (or 99) pixels. when they line up, the picture looks clear. when they don’t line up (in the middle of every span), interpolation takes roughly equal portions of two neighboring pixels, which causes blurring as an unavoidable side-effect.

the issue is NOT precision or rounding. this would happen with infinite precision.

the “issue” is not actually an issue. it’s just how the math works.

if you want to introduce some blur, use blur functions. resizing is not for blurring. resize unavoidably introduces blurring; the blurring comes from interpolation.

Apologies, my original point was that resize did not consistently distribute interpolation at different scales, i.e. 0.999% vs 0.99%. A window at 0.999% may have 10 square tiles, or with browser zoomed out 40 square tiles – all factors the same but browser zoom (including canvas size). Furthermore, at 0.99% there are no longer tiles, but lines bunched to the canvas edges like a pillow emboss. I wouldn’t notice, except it’s very noticable.

I will attribute unavoidable segments to OS, browser implementation of canvas, etc. and NOT OpenCV. I like OpenCV.