Describe the bug
I tried to create a marker on the AR.JS marker training page using 2 different browsers:
Browser used (on MacOS High Sierra):
As you can see in the above result, the created .patt is different whether I create it on Chrome or Safari. Furthermore, the Safari one doesn't seem to work on a ARJS project 馃
Am I the only one to experience these? My Chrome version is pretty old, so it could be the reason but... it's working on Chrome!, so...
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Same .patt file should be created.
Note: I tried with this grey scale 16x16px marker and... it doesn't give me the same .patt neither..!
Hi, you shuould use grey scale images. The one you linked on the second post has too low resolution. Can you try with a grey scale image of the heart on both browsers and share the results?
ps. your chrome version is not old, is the latest :)
Nicolo, thanks for your answer :)
I鈥檓 away from my Mac for 4days so I can鈥檛 test the gray scale heart.
That being said, the marker I use in my app are black and white and the problem occur anyway...
So if you have another test idea or feedback in the meantime, don鈥檛 hesitate to share. :) I will test the grayscale heart as soon as I鈥檓 back to the civilization !
no idea, it is a very strange thing. Can you try with other browser also, like firefox and opera? it could be curious to see results and compare to investigate further
@nicolocarpignoli after digging into the code, the pattern difference happens most likely when we get the uploaded image data in threex-arpatternfile.js
context.drawImage(image, -canvas.width/2,-canvas.height/2, canvas.width, canvas.height);
context.restore();
// get imageData
var imageData = context.getImageData(0, 0, canvas.width, canvas.height)
As explained in this post, getImageData result is browser dependent (depends on the browser algorithm).
And it looks like ARjs most recognized pattern is the one produced by Chrome getImageData algorithm...
So, if my analysis is correct, as long as we use getImageData we can't have a too detailed marker (typically a qr code as a marker) because it would screw up its recognition.
It makes me pretty sad tho ;P
Thanks for your analysis, makes pretty sense.
It would be nice to try to refactor with a different algorithm the marker generator. A PR is welcome. I will add 'need help' label.
@nicolocarpignoli ImageData could be loaded with Image() instead of canvas?
@kalwalt it looks like it's hard to getImageData without a canvas
I was thinking of using the below WebGL trick explained in one of the answers of this post to avoid the browsers image color correction.
gl.pixelStorei(gl.UNPACK_COLORSPACE_CONVERSION_WEBGL, gl.NONE);
Now, the problem is that we cannot create a getContext('2d') and a getContext('webgl') on the same canvas...
@yannklein understood. I think you can create another canvas and fill with the data of the first.
artoolkit.three.js should use a similar approach. It fill the renderer (a WebGLRenderer) with the videotexture from the getUserMediaARController. I hope that this may help ...
@kalwalt for my usecase, I ended up doing a terrible workaround: generate automatically a big amount of pattern with Chrome in advance for Firefox/Safari users to don't be stuck when they create AR holograms in my app (holobooth.dev).
I will work on the WebGLRenderer filling approach later on, I feel it would be beneficial for many ARJS devs.
Another option Is to use the app from ArtoolkitX you can download the already compiled app or compile It by yourself.
http://www.artoolkitx.org/docs/downloads/
It Is a no gui app, but i think you will not encounter the browser issue.
Most helpful comment
Thanks for your analysis, makes pretty sense.
It would be nice to try to refactor with a different algorithm the marker generator. A PR is welcome. I will add 'need help' label.