ramkunchur Hi, i have also been working for quite some time on getting a GUI interface working for my project.
It definitly seems hard to get it working without having too much of a video lag happening. What i found was that @Mojo 's idea/concept with TKinter is the best way i have found so far. I do agree QT5 is very nice to use but makes it much more difficult to get it working
best of luck
Hi @Mojo I just received the Poe injector you linked and happy to say that the Oak D finally could turn on!
It has a green-yellowish blink on the right side.
I also went to run a sample code on my mac from the docs and could see the camera feed on my computer screen.
I'm quite stoked as this is my first kickstarter I backed, and also my first cv hardware I've ever worked with!
Now I'm thinking what to do with it in a home setting. I stay in a safe place so maybe not a security feature, maybe something to do with pose...I once had a yoga pose idea so I have some image data ready for simple poses.
Any ideas/ interesting things being done with it on this forum? Nice to see what others have done.
Hey erik, thanks for the offer,I bought before I saw your message so it's ok 
Love. the support here. This is why I like the programming community. 
Now that is interesting! I am going to have to ponder that for a while. I've assumed that there would be a band on the depth map on both sides.
However, I've been pondering about the question you asked about "an equation". I am usually happy with empirical results, but figured that since all of this stuff is basically geometry, there should be an equation. I think I derived it, but it is so ridiculously simple, I'll show you the work, to extent the somewhat limited forum tool allows.
Consider the figure below, which shows the HFOV of the stereo cameras. The yellow cone represents the left camera view and the blue cone represents the right camera view. The greenish cone represents where the views overlap and thus accurate disparity/depth calculation is possible.
The cameras are separated by a distance (in cm) ‘BL’; for the OAK-D, BL=7.5 cm. ‘B’ is the width of the area where the camera views do not overlap and thus accurate disparity/depth calculation is not possible. B units can be in cm or pixels. It seems intuitive from the picture that in cm, B=BL, always.
‘W’ is the width of an image in pixels, which is constant for a given resolution. ‘F’ is the width of an image in cm at a distance ‘D’ cm from the cameras; F varies with D.
‘DV’ represents the minimum distance in cm at which both cameras can view an object and thus accurate disparity/range calculation is possible. DV depends on BL and HFOV. Further, one can intuit that at DV, B in pixels equals W. That means, in effect, no depth is accurate!
The next figure aids in deriving the needed equations.
Simple trigonometry shows that
F = 2 * D * tan(HFOV/2) [cm]
The figure also show that one can calculate DV as using
DV = (BL/2) * tan((90 - HFOV/2)
HFOV for the OAK-D mono cameras is roughly 72°, so, with BL=7.5 cm,
Dv=5.16 cm
As a check, can calculate B based on DV.
B = 2 * DV * tan(HFOV/2) = 7.44 [cm]
Not a bad agreement.
W/F describes the pixels/cm at any given F. So the width of B in pixels is
B = 2 * DV * tan(HFOV/2) * (W/F) [pixel]
B = 2 * DV * tan(HFOV/2) * (W/(2 * D * tan(HFOV/2))) [pixel]
B = W * (DV / D) [pixel]
That is the "magic" equation! Consider my experimental situation, where W=640. I measured B for an object about 210 cm from the cameras and one about 90 cm from the cameras. I measured B=16 at 210 and 40 at 90. Using the equation, at 210, B=16; at 90, B=37. Not too bad!
This gives me some confidence that the equation is correct.
I also set up a bit more controlled experiment with an object at 35 cm from the OAK-D, and a tape measure across the entire area. B measured 7.5 cm as expected. Using the equation for pixels, B=94. I measured B=93. Satisfying!
Hope you enjoyed the diatribe.
