OAK-D FOV

gregflurry

I admit to being a novice in computer vision and AI. I am beginning experimentation with my OAK-D and reading any documentation I can find to get a deeper understanding. While investigating field of view I found differing values for the FOV for the stereo cameras. I am not sure the difference is important, but it is a bit confusing. Can anyone tell me which source is the most correct?

In the DepthAI FAQ (link), I find "HFOV of the the grayscale global shutter cameras is 73.5 degrees".

In the DepthAI FAQ (link), I find "For DepthAI HFOV = 73.5(+/-0.5) degrees, and HPixels = 1280.". This one and the first one seem to mostly agree.

And here), I find "DFOV = 83 degrees". The reference says nothing about the HFOV.

And here I find "81 DFOV° - 71.8 HFOV°".

So, I really don't know if the stereo cameras have a HFOV or 73.5° or 71.8° and a DFOV of 81° or 83°. And I'm not sure it matters much, but I think it might. For example, based on the first link above, the focal is calculated from the HFOV. Thus if the HFOV changes the focal length changes and the minimum depth changes!

Help!

erik

Hello gregflurry, from my understanding there's quite some deviation of the FOV (eg. +- 1°) even for the same camera module from a different batch. I would use calibration data values as the ground truth. You can get them with

import depthai as dai
with dai.Device() as device:
    calibData = device.readCalibration()
    print(f"RGB FOV {calibData.getFov(dai.CameraBoardSocket.RGB)}, Mono FOV {calibData.getFov(dai.CameraBoardSocket.LEFT)}")

My output was RGB FOV 68.7938003540039, Mono FOV 71.86000061035156
Just curious, in which application is knowing the exact FOV so crucial?
Thanks, Erik

gregflurry

Thanks for the response!

I ran the script, and received output identical to yours. I'm not sure if that should make me feel good or not....

As I tried to hint in my initial post, as a novice in the field, I'm not sure having the exact FOV is important. I worried that it might be because initially I'm very interested in depth. From what I can tell, depth is derived from disparity and the calculation of disparity depends on focal length, which in turn depends on FOV. So, if the FOV is inaccurate, the estimated depth would be inaccurate. I must assume that the FOVs are somehow determined during calibration and then used internally in the OAK-D in the disparity/depth calculation. So, I think my programs don't need to know the FOV.

Just to elaborate, I am experimenting (as a hobby I admit) in using the stereoscopic camera to assist in localization. I hope to replace, or at least enhance, the LIDAR system I've been using.

erik

Hello gregflurry , I'm glad I could help! You are correct with all your assumptions (fov/disparity/calibration)🙂 If you won't be able to replace, do you plan on fusing the two depth estimations together?
Thanks, Erik

gregflurry

At least I've got something right!:

To address your question ... truthfully I have not given fusion much thought, as I still have hope of replacement. But I am getting hints from my OAK-D experiments that fusion of the two sources may be necessary. After many months of characterization and use of the LIDAR unit, I'm quite familiar with its abilities and limitations. I've been using the OAK-D and DepthAI (and of course OpenCV) for a little over a week, so I am still very early in the learning curve. For example, just today I discovered the example program rgb_depth_aligned.py. Studying it was enlightening, but there are mysteries (e.g., I understand how the rgb frame gets it shape (1280x720), but I am still a bit puzzled how the StereoDepth node produces the same shape for disparity with the inputs are 640x400). Some fun!

erik

Hello gregflurry, there's tons of useful info in StereoDepth docs and we are constantly improving our docs. There are also some really useful resources in FAQ (we are slowly copying this info into separate docs where this info belongs, so it's more intuitive to find). For disparity - yes, it has the same resolution as the left/right mono frames.

gregflurry

It is very clear you are willing to be very helpful, and I appreciate that. I realize, however, that I did not make my last question clear (I'm blaming it on a glass of wine). I will try again (this time after coffee).

In the example rgb_depth_aligned.py I've set downscaleColor = True. Based on the code, the comments, and live results, the color camera is set to output 1080P (1920x1080), but it gets downscaled, via camRgb.setIspScale(2, 3), to 1280x720. And thus the shape of the displayed rgb frame is 1280x720.

The mono cameras get set to resolution 400P (640x400), and based on some scripts I've created, and your confirmation, the expected output of the StereoDepth node disparity or depth would also be 400P. However, the statement stereo.setDepthAlign(dai.CameraBoardSocket.RGB) appears to automatically scale the disparity/depth to the resolution of the color/RGB camera (1280x720).

The question I meant to ask is whether stereo.setDepthAlign(dai.CameraBoardSocket.RGB) implies scaling as part of alignment? I think I confirmed this by commenting that statement and checking the disparity shape (it was the expected 640x400).

I could find nothing describing "alignment" in any of the documentation, though I may have just missed it.

Once again, thanks for the help.

erik

Sorry for not understanding the question earlier gregflurry. You are correct, when alignment is used and depth & rgb shapes don't match, depth will get upscaled to match color frames. I will be adding this info - together with other relevant info about rgb-depth alignment - to our documentation. Thanks!

gregflurry

Thank you! This sort of support makes life much better!