search

webarkit / jsartoolkitNFT

jsartolkitNFT is a smaller version of jsartoolkit5 with only NFT support
GNU Lesser General Public License v3.0
131 stars 25 forks source link

Marker Detection problem in new versions #344

Closed MasoudShah closed 10 months ago

MasoudShah commented 11 months ago

There is a difference between two versions that I checked. In first version (0.9.7) the marker gets detected from more far distance. Distance is more than 30 cm. the image height is about 20 cm; but in newer version (1.6.0) the image doesn't get detected in 30 cm but somewhere less than 20 cm. In this distance, the image borders are out of the camera boundaries and it's not very pleasant. The users might think that the AR doesn't work at all because you have to place the camera too close to the marker. Are there any parameters to take care of, to set the distance range? (in both versions I tested the main example inside the project)

MasoudShah commented 11 months ago

I uploaded 2 videos to show the versions difference clearly. Although in the newer version, the performance is better when the video gets tracked, but the start of tracking itself, is much worse. In the older version the image, starts to track very faster in a more far distance, but in the newer one, you have to place the camera much closer to the marker, or it doesn't track at all. 0.9.7 version: Link 1.6.0 version: Link

kalwalt commented 11 months ago

@MasoudShah Thank you for this, comparing the code of 0.9.7 and 1.6.0 the changes in the code that could affect this, i think the Eigen upgrade in WebARKitLib, and maybe the OneEuroFilter (OEF) routine. Have you tried to disbale the OEF?

MasoudShah commented 11 months ago

Thanks for your response @kalwalt . I will check them tomorrow. I thought the start of tracking markers, happen in kpmMatching function, but I had no luck to find the difference that caused this problem.

MasoudShah commented 11 months ago

I checked it out @kalwalt . Disabling OEF only increases the noise of the video plane, but no effect on start of tracking. I don't know if I'm correct or not, but I feel that the position of the marker has some effect. For example when the marker is at the top of the camera frame, the tracking starts easier; but when it is at the bottom, you have to place the camera too close to the marker to get tracked.

MasoudShah commented 10 months ago

I built the WebARKitLib project with the previous Eigen library and still no luck. The behavior is same as before, so the Eigen lib update cannot be the cause of problem. The point that I mentioned before, that the marker gets detected easier at the top of the video frame, gives some guides, and also getting camera closer to marker, causes that a part of marker be placed at the top of the frame. With this reasoning, I think the this issue is due to memory allocation. The comparison of video frame and the markers, just happen at the top of frame, that means the process of comparison only takes place at the beginning part of the frame vector. I still haven't verified the size or allocation of arrays, or compared this in the older and newer versions.

MasoudShah commented 10 months ago

@kalwalt I think I found the main problem. The definition of videoLuma size in ARControllerNFT file (and the similar ones) had an extra 1/4 division. I omitted the division and the behavior got back to normal. I also made a PR on this one.

kalwalt commented 10 months ago

@kalwalt I think I found the main problem. The definition of videoLuma size in ARControllerNFT file (and the similar ones) had an extra 1/4 division. I omitted the division and the behavior got back to normal. I also made a PR on this one.

@MasoudShah i will review you PR thank you for this!

kalwalt commented 10 months ago

closing because solved with #352 and #353