-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
CCTag not working at all [bug] #716
Comments
You need to use the latest 2019.2 version. |
Oh, I was unaware of an update. but what exactly do you mean by node A and node B? are you just referring to a node later down the line? |
@SugoiShades " are you just referring to a node later down the line?" |
Hi, First of all, thanks for making a GREAT photogrammetry program. Love the graph-based UI and the fact that it works on 4K screens :-) ) Encouraged by the exchange above, I also tried it using CCTag 3 and the latest MeshRoom (2019.2.0) I created a set of 38 photos with 5 markers in the scene, using a Galaxy Note 8 smartphone, resolution is 2880x2160. After dragging and dropping the pictures, I activate CCTag 3 in the FeatureExtraction node, so now both SIFT and this one are active. I save the project in the folder where the pictures are, then press Start. The system crunches for a while (fan blowing, CPU at about 40%) the program halts, which is mainly indicated by the Start butting becoming green again. There is no obvious error at the bottom of the Output log (pastebin, copied from the Command window, not possible from the UI <-- this could be convenient), but there is an "ERROR" string in the Status tab of the FeatureExtraction node (pastebin). Upon further inspection I see this message in the log "ERROR:root:Error during Graph execution Error on node "FeatureExtraction_1(0)" Any idea what could be causing this? Perhaps the camera intrinsics are required for this feature? Have you guys as authors done an end-to-end test of a reconstruction with CCTag markers in it? Any help would be appreciated. |
To partially self-answer.. I found this wonderful list of sensor information used in Samsung phones, among others https://en.wikipedia.org/wiki/Samsung_CMOS and added this line to cameraSensors.db samsung;SM-N950F;9.96; That seems to help a lot, the process now completes to the textured mesh stage. However, this is most likely not the right value for this entry: it is the "Optical Format" sensor size, not the width. Does anyone have an equation to do the conversion (given the aspect ratio of the sensor)? This may also explain that the current result is a garbled mess of triangles. Or would the system compute the correct Focal Length calibration of the camera automatically, during the reconstruction? Note that I later realized that CCTag 3 most likely also needs to be activated in the FeatureMatching and Structure From Motion nodes (does not change quality of result). Idea: perhaps the system can give a warning in the matching- or SfM-stage when there are certain features in the input dataset but the node has not been configured to use them? |
Thanks for the link! When I tried 5.75 I did not get a result yet, but when I calculated the sensor width using pixel size and horizonal resolution (using this link on the page you mentioned: https://www.vision-doctor.com/en/camera-calculations/sensor-diagonal-sensor-ratio.html) I arrived at 5.64, and with that value I get a 3D mesh that looks very sensible, even at the right scale! I don't really understand why the system is so sensitive to this value, as most MVG systems will estimate the FL as part of the process, since with simpler lenses this will depend on the focus distance, so from photo to photo. But at least the setup is working now :-) All right, I'm off to do more experiments! |
Hi natowi, I have created a dataset where there is a lot of internal self-similarity in the physical world, so this would be a good case to apply the CCTag technology. When I disable CCTag 3, the FeatureExtraction stage completes, but ultimately the mesher fails, which is very understandable given the extreme likelyhood of camera-pose errors due to feature mismatches. In other words, the error appears to be related to the CCTag subsystem. The log is here but does not look very useful: https://pastebin.com/n42rex6f Image resolution is 2880 x 2160 Edit: I now have three datasets which exhibit this problem:
Would you be interested in having a look at the dataset(s)? My mail address is my github username at gmail.com, if you would send me your address I can transfer the files via wetransfer.com. Or I can put them online somewhere, there is no privacy-sensitive information in there. |
Ok, I had a hunch and did some additional tests:
However why I put a dataset that hasn't worked yet into a folder with a shorter name, it still failed. Reducing the number of photos didn't make a difference either, neither did reducing the resolution. The only thing I could do to get a result from the troublesome dataset was to disable CCTag detection. Maybe the above gives an additional clue. By the way, having a look at the process using Microsoft Process Monitor (or alternatively, Process Explorer) might help as well. There are some error messages in there regarding use of the Registry, although these could be benign. |
Regarding large CCTag, there is a known issue that has been fixed after the 2019.2 release, see alicevision/CCTag#116. You have to make a conversion to set the focal length to 24mm as the unit used in Meshroom is in pixels. |
If you don't have focal metadata on your images, you can adjust the "Default Field Of View" on the CameraInit before dropping your images in Meshroom. So it will use this angle in degree as a default value to initialize the focal length. |
I thought it was the last official build, I'll wait for the next. About converting mm to pixel... I don't understand, doesn't it depend on resolution? Thank you |
Hello, |
I am very interested in that too! Have you found a solution yet? |
@miquelrosell99 @TR7 this is not yet supported. See #855 for details and workarounds |
Retrieve scene scale using CCTag markers is done in the development branch but not yet in a release. |
@fabiencastan is this included in alicevision/AliceVision#695 |
Is there a plan for a new release? |
@canonex You could try the AliceVision (CLI) snapshot build. |
@natowi Yes, it's included in alicevision/AliceVision#695. (The other one is not related). @canonex I don't have a date for the next release yet. |
@fabiencastan @natowi i Know it's OT but... After solving the issue with ImageMatching i get a similar one on DepthMap |
This is not related to the issue. |
I see. Thanks. |
No pbl. The only rule is to keep one problem per issue. So feel free to open another issue. |
Unfortunately, all my Cuda hardware are under Linux :( |
CCTag3 working on Meshroom 2020.1.1 🎉 |
I have Meshroom 2019.1.0
I recently printed out all of the CCTags from this repository and positioned them around my space, and if I check the box cctag3 (or cctag4 even though I'm not using it) in the FeatureExtraction node it will immediately "crash" meaning the node immediately turns red indicating an error. I set the verbose level to "Fatal" , "Error" , and "Trace" in an attempt to diagnose the issue, yet the logs showed nothing other than my device info and the node settings. This error occurs on any level of describer present and with any combination of Descriptor types as long as it includes one of the "cctag" descriptors. I'll include a screenshot of the Meshroom program and a few of the photos i used for the project (just to prove how easily visible the cctags are to the camera) I'm not sure if there's something funky with my install of meshroom or what, but I hope my report helps
Meshroom Screenshot:
Example Photo 1:
Example Photo 2:
Example Photo 3:
The text was updated successfully, but these errors were encountered: