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

Bounding Box Visualization #7

Open
taeyeopl opened this issue Dec 13, 2023 · 3 comments
Open

Bounding Box Visualization #7

taeyeopl opened this issue Dec 13, 2023 · 3 comments

Comments

@taeyeopl
Copy link

I saw that you mentioned visualization in the paper, "It is important to note that the visualization of object boxes incorporates ground-truth translation to address scale ambiguity."

Q. Does it also need the 3D size of the object to visualize like below? Or do you not need the 3D size of the matched CAD Model to estimate the bounding box with the pose?

POPE/visual_3dbbox.py

Lines 31 to 41 in 92c5cdb

x, y , z = 3.793429999999999719e-02, 3.879959999999999659e-02 ,4.588450000000000167e-02
_3d_bbox = np.array([
[-x, -y , -z],
[-x, -y , z],
[-x, y , z],
[-x, y , -z],
[x, -y , -z],
[x, -y , z],
[x, y , z],
[x, y , -z],
])

@zhiwenfan
Copy link

The size information (length, width and height) of the 3D CAD model of the object is needed for visualization, but this information will not be used during reasoning. (Use the PNP algorithm to estimate the 6DoF Pose of the object)

@taeyeopl
Copy link
Author

Thanks for your replies. I understood that 3D CAD size information is only for bounding box visualization.
I have a related question related to the PnP process.

I understood that Perspective-n-Point(PnP) usually utilizes 3D-2D matching to estimate pose (https://docs.opencv.org/4.x/d5/d1f/calib3d_solvePnP.html).

For my understanding, your provided estimate_pose code uses 2D-2D matching (2D keypoint correspondences -> findEssentialMat -> recoverPose), which is not called PnP. Did you say this process is PnP? Did I miss something?

@werdnabae
Copy link

I'm also curious on how the bounding box visualization works.

I see that the box3d_corners.txt file for LM dataset is all in the form:

 [-x, -y , -z]
 [-x, -y , z]
 [-x, y , z]
 [-x, y , -z]
 [x, -y , -z]
 [x, -y , z]
 [x, y , z]
 [x, y , -z]

However, why is this not the case for onepose? Ex:


  -1.183792717996364624e-01 -1.108238279983774499e-01 -1.051027637805763137e-01
  -1.160704331224012703e-01 -1.122539152042195676e-01 6.795285679492273079e-02
  -1.148781447018224072e-01 1.001698067314842899e-01 6.969236484636120998e-02
  -1.171869833790575993e-01 1.015998939373264076e-01 -1.033632557291378345e-01
  8.578463329921544311e-02 -1.119473744086841305e-01 -1.078359214114075204e-01
  8.809347197645063521e-02 -1.133774616145262482e-01 6.521969916409152412e-02
  8.928576039702949829e-02 9.904626032117760936e-02 6.695920721553000332e-02
  8.697692171979430620e-02 1.004763475270197270e-01 -1.060964133599690412e-01

Also, is there no box3d_corners.txt file available for ycbv?

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

3 participants