-
Notifications
You must be signed in to change notification settings - Fork 233
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
Neural-Assisted Disparity Depth Estimation #173
Comments
As a DepthAI user, I want to emphasize the importance of having clean/accurate/precise depth maps - it's clear that deep learning is the key to achieving this. It's definitely possible to clean up depth maps with more traditional filtering, with something like the Bilateral Solver: https://drive.google.com/file/d/1zFzCaFwkGK1EGmJ_KEqb-ZsRJhfUKN2S/view However there has been much more work recently to apply deep learning to 3d image generation, and more work is coming all the time. Stereo Magnification introduced Multi Plane Images, and used differentiable rendering to learn to generate them from stereo images: https://people.eecs.berkeley.edu/~tinghuiz/projects/mpi/ Many have extended on this idea, but much of the latest work uses dozens of input images, instead of just two: DeepView: https://augmentedperception.github.io/deepview/ (Not all of these output MPIs, but all are fairly similar) There's also plenty of recent work around monocular depth estimation, like MiDaS from Intel: https://github.com/intel-isl/MiDaS Some take existing 3d photos, and try to inpaint disocclusions, so that inaccuracies are less noticeable: https://shihmengli.github.io/3D-Photo-Inpainting/ |
Thanks @2emoore4 ! Super appreciate it. Will review all these shortly. And also sharing with the team! |
I am adding the paper by Skydio which carries out end to end learning for stereo. |
Thanks! |
This looks quite interesting (Martin brought up internally): |
Check out the datasets referenced near the end of this paper: |
PatchmatchNet: Learned Multi-View Patchmatch Stereo |
Some additional resources from Discord: |
This seems to be pretty accurate. Achieved results on TFlite HITNET Stereo Depth Estimation - |
Looks great - thanks for sharing! |
https://github.com/cogsys-tuebingen/mobilestereonet - From @PINTO0309 in Discord. |
The first results are starting to come. Here's MIT Fast Depth (https://github.com/dwofk/fast-depth) running on OAK-D-(anything): |
Hey @Luxonis-Brandon, this looks like a great starting point for neural network assisted depth estimation. I wonder how precise it can get if we added the depth ground truth in a self-supervised training. Is the inference part running on host and if this is the case, what would it look like to try to optimize the network run on the OAK-D onboard? |
This is running on OAK-D directly, not on the host. Matija will be making a pull request soon so you'll be able to try it. (He may have already and I missed it - unsure... he just got it working this weekend.) |
Due to a problem with OpenVINO's conversion to Myriad Blob, I submitted an issue to Intel's engineers (OpenVINO). So far, Intel engineers seem to be concerned that the structure of the model is wrong, but we are able to infer it successfully in ONNX runtime and TFLite runtime.
|
Also, HITNET looks nice, but it is quite slow. Currently, monocular depth estimation models (fastnet, Midas 2.1 small...) seem to be faster than the stereo ones (current ones are too complex with 3D convolutions and the cost aggregation). But, I still have hope that there is somewhere some fast stereo model 🧐 |
It looks like the issue I posted has been triaged and escalated to the development team. I can somewhat predict that it will run faster if I reason with OpenVINO, so I will be patient and interact with it. |
Awesome - thanks! |
Can Sb submit algorithm results to benchmark? https://vision.middlebury.edu/stereo/eval3/ |
Hey, Sorry for the spam but I am trying to reproduce the same example that you showed @nickjrz (stereo depth estimation on the host with an oak-d and hitnet) and I can't get as good results as you show. I actually started from the same project (https://github.com/ibaiGorordo/HITNET-Stereo-Depth-estimation) but it looks like my results are much worse than yours (maybe the pre-processing?). Could you maybe provide a link to your code, it would be really interesting. Thank you! |
@Luxonis-Brandon Did you made some progress with this one? I did not find anything about speed of this? And would it be possible to make it smaller (replacing backbone)? |
We did some extensive experiments on that one @cyberbeat . We replicated the code before it was released actually, but just replacing the backbone isn't enough. The 2 MLP heads at the end are pretty big, so the final model doesn't fit on device. So we've tried experimenting a bit with the two heads, but unfortunately they don't perform well enough when constrained as much as we needed them to be. We are constantly looking at different approaches and how to combine them. |
Have you guys looked at RAFT-Stereo (https://github.com/princeton-vl/RAFT-Stereo)? I was looking at implementing a lite variant of this myself (like how the og RAFT optical flow model has RAFT-S). It appears to have good results. |
@justin-larking-pk I don't think we tried exporting it, CREStereo mentioned above seems to get better results. But if you give it a try, do keep us updated! :) |
Tried adapting the method from [1] using their code (https://github.com/kevinleestone/mmstereo) to run onboard the device. As such, at 720P resolution, I was not able to fit it in memory and ran into some issues with model export. With a few changes to the model, I was able to export it and run it on the device. Took a bit of tweaking to get the compute to a reasonable level (640x400 resolution, 8x downsampling factor), which runs on the device at ~4 FPS, although the lower resolution and heavy downsampling does come at the cost of accuracy and considerable artifacts are starting to be visible. Trained it on FlyingThings, Middlebury and ETH3D. Might give it a couple more shots to see if I can find a setting that would work a little bit better. Anyone know of any tools or general resources that could help figure out the bottlenecks on the embedded hardware? [1] Krishna Shankar, Mark Tjersland, Jeremy Ma, Kevin Stone, and Max Bajracharya. A Learned Stereo Depth System for Robotic Manipulation in Homes. ICRA 2022 |
Nice @kekeblom! Do you mind sharing the repository/describing all the changes you've made in the repo? I think this definitely shows some promise and I believe the artifacts could be removed by further tweaking the architecture. As for figuring out the bottlenecks on the embedded hardware - you can try and install openvino-dev. There should be a benchmark_app which you can use to benchmark the model on the device. Simply add You can also inspect the FLOPs and parameters of your architecture using fvcore or something similar beforehand. While more FLOPs in certain module does not always mean there could be a bottleneck, it's a good start and it's usually worth investigating those modules. |
Here is the code I used https://github.com/kekeblom/mmstereo. @tersekmatija Currently training one with 640x400 resolution, 4x downsampling and 128 disparities computed. This seems to yield quite a bit cleaner output. The settings can be found in the example config This one hasn't yet fully converged, but using an intermediate checkpoint, I get slightly better output: Admittedly some artifacts are still visible. It seems most of the compute is spent in computing and processing the cost volume. Trimming the convolutional network doesn't seem to change throughput, but reducing the size of the cost volume has a considerable impact. Can't think of any easy ways around that besides using lower resolution images. Maybe there exists a more efficient way to match features on this specific hardware. I think the sweet spot for this type of network might be running at a lower resolution, but might require some tuning to get rid of the artifacts, as the network is kind of designed for very high resolutions and close range scenes with the large dilations in the convolutions. |
Nice! @tersekmatija @kekeblom thoughts on perhaps having a network that "validates / augments" depth instead of computing it from scratch? Maybe a L + R + Depth(or Disp) + Confidence Map -> Depth. It'd either recalculate low confidence points, or observe known areas/patterns which should be "filled" (eg flat surfaces, etc...). Mostly thinking from performance standpoint, running on existing hardware, where the Stereo HW already does a lot of compute and to see if that can be further utilized, without having the network do it. (the whole matching again) |
Nice @kekeblom! And yeah, cost volumes are expensive. Currently I am not sure if there exist some fast way to compute/process them at arbitrary scales. This is why CREStereo and similar methods usually tackle the problem with RNNs rather than cost volumes. Re depth/disparity filling - I think approaching this with CNNs might be hard, especially since the holes have dynamic shape and any conditional predictions are hard to do on edge accelerators. I think a more suitable approach would be something along the lines of NDR, but from my experience the MLPs there are the reason for a good performance. Making them lighter massively decreases the performance, but without doing this it's impossible to deploy them. |
I don't want to discount the awesome work going on with end to end disparity estimation, those results are really cool!! But I am also curious about the depth completion rather than full neural network estimation of the disparity. SGBM is already there, gives valid but sparse depth estimates, and runs at a high fps. It seems like inpainting a sparse depth map to a dense depth map given a reference image (e.g. the aligned gray scale camera) would be easier than going from image+image to dense disparity map. But It could be much harder in practice 😅 Also crestereo makes the myriad processor on my oakdlite run so hot 🥵 not complaining, just FYI for others that try this. |
Here is a TinyHITNet implementation that is much less computationally intensive. But the model conversion looks a bit problematic. |
Nice @borongyuan Gave this a quick try - does seem to work fairly well, but has issues recognizing certain objects every now and then. Looking forward how far you'll be able to bring this! |
Hi @themarpe |
Our new stereo depth solution, running on OAK-D Lite neural_depth.mp4 |
Nice @borongyuan ! Curious how you are approaching this? |
We use a more clever way to construct the cost volume, which solves the bottleneck that @kekeblom mentioned earlier. Lightweight architectures are used for feature extraction and cost matching. This seems to be the best we can get with RVC2’s computing power. This model can theoretically run on RVC4, and it should be able to achieve good real-time performance at that time. |
Hi. Here is an example of how to set stereoRectify() and warpMesh on OAK-D-PRO device
The needed informations are leftSocket, rightSocket, calibration data and resolution of camera. |
Thank you @MaticTonin. I'll try it later. Does OAK have any limits on wrap mesh? I see that the mesh used internally has a step of 16 as well. In addition, I need to start the device first to obtain calibration params. Then I need to restart once to reconfigure the pipeline, like in the warp_mesh_interactive.py example. |
The minimal limit is 9. To obtain parameters, you dont need to start the pipeline, which boots the device, but extract them before starting the pipeline. |
Due to Camera Node related issue, I can't use it for stereo rectification yet. But I still managed to improve performance a little bit. Here is my outdoor test using OAK-D W, and it looks good. Kazam_screencast_00006.mp4 |
Factor_Perception_Lite_Neural_Depth.mp4 |
Initial test on OAK-D LR Neural_Depth_LR_test1.mp4 |
Start with the
why
:The
why
of this effort (and initial research) is that any many applications depth cameras (and even sometimes LIDAR) are not sufficient to successfully detect objects in varied conditions. Specifically, for Luxonis’ potential customers, this is directly limiting their business success:Autonomous wheelchairs. The functionality above it would be HUGE for this application as existing solutions are struggling with the output of D435 depth. It gets tricked too easily and misses objects even w/ aggressive host-side filtering and other detection techniques.
Autonomous lawn mowing. This use-case is also struggling with object detection using D435. The system can't identify soccer-ball sized things reliably even with significant host-side post-processing and then need to be able to identify down to baseball sized things.
Volumetric estimation of low-visual-interest objects. Disparity depth struggles significantly with objects (particularly large objects) of low visual interest as it lacks features to match. Neural networks can leverage latent information from training that overcomes this limitation - allowing volumetric estimation where traditional algorithmic-based disparity-depth solutions cannot adequately perform.
The original idea of DepthAI is to not solve this sort of problem, but it is well suited to solving it.
Background:
As of now, the core use of DepthAI is to run 2D Object Detectors (e.g. MobileNetSSDv2) and fuse them with stereo depth to be able to get real-time 3D position of objects that the neural network identifies. See here for it finding my son's XYZ position for example. This solution is not applicable to the above two customers because the type of object must be known to the neural network. Their needs are to avoid any object, not just known ones, and specifically objects which are hard to pick up, which are lost/missed by traditional stereo depth vision.
New Modality of Use
So one idea we had recently was to leverage the neural compute engines (and SHAVES) of the Myriad X to make better depth - so that such difficult objects which traditional stereo depth misses - could be detected with the depth that’s improved by the neural network.
Implementing this capability, the capability to run neural inference to produce the depth map directly, or to improve the results of the disparity-produced depth map, is hugely enabling for the use-cases mentioned above, and likely many others.
Move to the
how
:The majority of the work of how to make this happen will be in researching what research has been done, and what techniques are sufficiently light-weight to be run on DepthAI directly. Below is some initial research to that end:
Google Mannequin Challenge:
Blog Explaining it: https://ai.googleblog.com/2019/05/moving-camera-moving-people-deep.html
Dataset: https://google.github.io/mannequinchallenge/www/index.html
Github: https://github.com/google/mannequinchallenge
Notice in a lot of caes this is actually quite good looking depth just from a single camera. Imagine how amazing it could look with 2 or 3 cameras.
Could produce just insanely good depth maps.
KITTI DataSet:
http://www.cvlibs.net/datasets/kitti/eval_scene_flow.php?benchmark=stereo
So check this out. A whole bunch of ground truth data, with calibration pictures, etc. So this could be used to train a neural network for sure on this sort of processing.
And then there's a leaderboard downbelow of those who have.
PapersWithCode:
PapersWithCode is generally awesome. They have a slack even.
https://paperswithcode.com/task/stereo-depth-estimation
Others and Random Notes:
So have a dig through there. This one from there seems pretty neat:
https://github.com/CVLAB-Unibo/Real-time-self-adaptive-deep-stereo
These guys seem like they're getting decent results too:
https://arxiv.org/pdf/1803.09719v3.pdf
So on a lot of these it's a matter of figuring out which ones are light enough weight and so on to see about porting.
Notice this one uses KITTI dataset as well:
https://www.cs.toronto.edu/~urtasun/publications/luo_etal_cvpr16.pdf
SparseNN depth completion
https://www.youtube.com/watch?v=rN6D3QmMNuU&feature=youtu.be
ROXANNE Consistent video depth estimation
https://roxanneluo.github.io/Consistent-Video-Depth-Estimation/
https://github.com/kelkelcheng/GC-Net-Tensorflow/blob/master/README.md
The text was updated successfully, but these errors were encountered: