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

cuda_image_processing.c:192 #33

Open
sitesite opened this issue Nov 28, 2019 · 4 comments
Open

cuda_image_processing.c:192 #33

sitesite opened this issue Nov 28, 2019 · 4 comments

Comments

@sitesite
Copy link

sitesite commented Nov 28, 2019

Thank you very much. I was suspecting the compute capability as well but I thought I had a 5.3. I will try doing that.

@puzzlepaint
Copy link
Collaborator

This is expected, since the application requires CUDA compute capability 5.3 to run (as documented in the Readme), but the Quadro M6000 seems to support only compute capability 5.2 (according to this page). However, it should be very easy to make the application run with 5.2 as well in case you are willing to change the source code a bit and compile it yourself (unless there are other things requiring a high compute capability that I am not aware of). The reason for requiring it is that point radii are stored as 'half' numbers in a memory buffer to save space, and the corresponding conversion functions require 5.3 according to this table. The alternative would be to store them as floats, which will have no negative consequences except requiring more GPU memory. To change this, one would need to look for all occurrences of the radius_buffer which is stored in the keyframes (keyframe.h header) and change its type from u16 to float. Then drop all of the conversions that happen when reading from or writing to this buffer. For example, in cuda_depth_processing.cu#L355, simply drop the __half_as_ushort(__float2half_rn()) around the value.

@sitesite sitesite changed the title cuda_image_processing.c:192 FATL| Cuda Error: no kernel image is available for execution on the device cuda_image_processing.c:192 Nov 29, 2019
@sitesite
Copy link
Author

Hello @puzzlepaint, I have a follow up question.
I have ran the program on my own data but I am now running into an issue about the scale of my recorded path as it does not match the ground truth.

It is either to way smaller or way larger than than ground truth and I think it may have to do with the parameters labeled:
Maximum depth to use, Baseline*fx, Raw to metric depth conversion factor.

Because I am new to this,I was wondering:

1)what is the meaning of this parameters

2)how do I input them to get the correct path scale (same scale as ground truth).

3)what is meant by Baseline and,

4)which fx should be used for the multiplication with the baseline value(RGB or Depth)?

Thank you very much

@puzzlepaint
Copy link
Collaborator

Please see here for the parameter explanation:
https://github.com/ETH3D/badslam/blob/master/applications/badslam/doc/command_line.md

Only the raw to metric depth conversion factor should be relevant for scaling.

@sitesite
Copy link
Author

@puzzlepaint , Thank you very much for you reply. I have read it and I am still getting a path that is smaller than the ground truth. I recorded my data using the intel realsense D435i and calculated that the scale factor should be 1/1000 = 0.001 but the resulting path is sill way smaller than the ground truth.

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

No branches or pull requests

2 participants