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

isAntialiased() accessing non-sibling pixels/negative offsets on image boundaries #90

Open
radomik opened this issue Dec 28, 2016 · 1 comment
Labels

Comments

@radomik
Copy link

radomik commented Dec 28, 2016

In function isAntialiased() there are read pixels which are direct siblings of sourcePix:

offset = ((verticalPos+j)*width + (horizontalPos+i)) * 4;
if(!getPixelInfo(targetPix , data, offset, cacheSet)){
    continue;
}

Pixel sourcePix has coordinates (horizontalPos,verticalPos) and i, j can be either -1 or 1. Using that values there is computed offset used in getPixelInfo():

function getPixelInfo(dst, data, offset, cacheSet) {
    if (data.length > offset) {
        dst.r = data[offset];
        dst.g = data[offset + 1];
        dst.b = data[offset + 2];
        dst.a = data[offset + 3];
        return true;
    }
    return false;
}

Function getPixelInfo() access pixel data stored row-wise.

When (for example) isAntialiased() takes sourcePix positioned on the end of a row then, with i=1 a sibling pixel is taken from the beginning of following image row which is not correct.
Similar problem will occur when sourcePix is placed on the row beginning, then siblings are taken from the end of previous row.
There may be also needed to add a check for negative offsets i.e. when sourcePix is positioned on the first image row (now there is only a check for too big offsets - in getPixelInfo()).

@jamescryer
Copy link
Member

I think you're right, and it is solvable by breaking out of the loop in isAntialiased(). Unfortunately the same check seems to affect performance, I had mixed results on testing. For that reason I'm not going to fix this issue, unless it's causing any problems?

@jamescryer jamescryer added the Bug label Feb 15, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants