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

Install browserify dependencies by default #9

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

ziahamza
Copy link

@ziahamza ziahamza commented Jan 1, 2015

In my application, I include all by browserify dependencies in package.json, and then run a build step to package the javascript into a browser bundle. But browserify fails to compile blockhash as the jpeg-js and png dependency are not found. The reason is that npm by default doesnt install devDependency when used by other modules.

@ziahamza
Copy link
Author

UPDATE: also pushed in code for removing PNGJS and JPEG decoder as dependencies for the browser. Now it uses html5 canvas to decode and get the hash. For NodeJS the developer need to use the PNGJS and JPEG modules.

@petli
Copy link
Member

petli commented Jan 22, 2015

There was a reason for not using canvas but going with the PNGJS and JPEG libraries - I think it had to do with security restrictions making that difficult in a browser extension. However, that might have been when trying to copy an HTMLImage into the canvas directly, rather than loading the file over the net. @artfwo, do you remember?

@artfwo
Copy link
Member

artfwo commented Jan 22, 2015

Exactly. It's not possible to access pixel values if the canvas has been tainted by cross-origin data.

@ziahamza
Copy link
Author

but, wont XHRRequest also hold the same restrictions for loading a URL if CORS is not enabled? because if the cross origin headers are not set then neither should work ... ?

@artfwo
Copy link
Member

artfwo commented Jan 22, 2015

Right, in case the server responds with appropriate headers, XHR works fine. And in case it doesn't, we worked around this problem in elogio.browser by opening the image in a separate tab (commonsmachinery/elogio.browser#16).

For JPEG images, jpeg-js gives an additional benefit of decoding images without using system color correction (at least on Linux), that resulted in slightly different hash.

An alternate solution to CORS problem might be using crossorigin attribute for elements, which I've just found[1]. Images with such an attribute shouldn't taint the canvas if CORS headers are present for src. This doesn't resolve an issue with mismatching colors in native decoders, but looks promising. I'll try putting that in elog.io browser and check if there's any difference.

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_enabled_image

@ziahamza
Copy link
Author

But I guess the dependencies should not be shipped being part of blockhash-js. Because it just adds extra overhead which could easily be avoided. I will look into the color difference in decoders, but got some of my hashes identical on a mac osx

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

Successfully merging this pull request may close these issues.

3 participants