Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ARGBScale use kFilterBilinear will cause 1-2 pixels shift to original picture #242

Open
GoogleCodeExporter opened this issue Dec 31, 2015 · 8 comments

Comments

@GoogleCodeExporter
Copy link


compare kFilterBilinear ARGBScale and kFilterNone ARGBScale.I found that there 
is about 1-2 pixels shift to original picture in kFilterBilinear.kFilterNone 
don't happen this situation.

Original issue reported on code.google.com by [email protected] on 3 Jun 2013 at 9:00

@GoogleCodeExporter
Copy link
Author

Are you scaling up or down?

Original comment by [email protected] on 4 Jun 2013 at 3:14

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

scaling up.
1.scaling up original image *4 bigger use kFilterBilinear .
2.fast changing-over two pictures in Windows photo viewer.
3.you can see the shift to original.

Original comment by [email protected] on 5 Jun 2013 at 8:05

@GoogleCodeExporter
Copy link
Author

in ScaleARGB is there can be edit to
if (filtering) {
    // Scale step for bilinear sampling renders last pixel once for upsample.
    if (dst_width <= Abs(src_width)) {
      dx = (Abs(src_width) << 16) / dst_width;
      x = (dx >> 1) - 32768;
    } else if (dst_width > 1) {
      dx = ((Abs(src_width) - 1) << 16) / (dst_width - 1);
    }
    if (dst_height <= src_height) {
      dy = (src_height << 16) / dst_height;
      y = (dy >> 1) - 32768;
    } else if (dst_height > 1) {
      dy = ((src_height ) << 16) / (dst_height); //here edited
    }
  } else {....}

Original comment by [email protected] on 5 Jun 2013 at 8:10

@GoogleCodeExporter
Copy link
Author

The line is intended to be
dy = ((src_height - 1) << 16) / (dst_height - 1);
which ensures the last pixel of the destination is exactly the last line of 
source.
if you do
dy = ((src_height ) << 16) / (dst_height); //here edited
and start at y = 0, it'll shift the image up 1/2 pixel and filter with the 
pixel off the bottom of the image.
What it should be is
dy = ((src_height ) << 16) / (dst_height);
but with y = -0.5 to start, filtering with the pixel just before the first row, 
and just after the last row.  But that requires clamping, which is slow on the 
horizontal, so Y is done the same as X, for consistency.
The step rate of
dy = ((src_height - 1) << 16) / (dst_height - 1);
will stretch from the first and last source pixel, to the first and last 
destination pixel.  The image will have an overall half pixel zoom on both 
edges, but equally and reversible.

Original comment by [email protected] on 8 Jun 2013 at 8:53

@GoogleCodeExporter
Copy link
Author

thanks.

Original comment by [email protected] on 9 Jun 2013 at 1:28

@GoogleCodeExporter
Copy link
Author

Original comment by [email protected] on 19 Jun 2013 at 8:40

  • Changed state: Fixed

@GoogleCodeExporter
Copy link
Author

Reopening, as another use case exhibites a 1 pixel shift.
The issue appears to be upsampling.

Original comment by [email protected] on 20 Sep 2013 at 4:10

  • Changed state: New

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant