Same hires cam part number but different FOV?
-
Are you sure they both have M0025-2? M0025-1 has a wider FOV, but did not work well for longer distances. Consequently we changed over to M0025-2 for a longer focal length on newer products
-
@Chad-Sweet said in Same hires cam part number but different FOV?:
Are you sure they both have M0025-2? M0025-1 has a wider FOV, but did not work well for longer distances. Consequently we changed over to M0025-2 for a longer focal length on newer products
Yes im quite certain both have M0025-2 as shown:
I also have M0025-1 (the area around the lens is silver unlike the M0025-2 is entirely black in color), but it is not used in this case.
Do you not observe any change in FOV when swapping your M0025-2 from VOXL1 to VOXL2?
-
@Chad-Sweet said in Same hires cam part number but different FOV?:
Are you sure they both have M0025-2? M0025-1 has a wider FOV, but did not work well for longer distances. Consequently we changed over to M0025-2 for a longer focal length on newer products
I made some comparison against the VOXL1 setup that im familiar with.
On VOXL1, voxl-camera-server -l shows the following for the hires (M0025-2):
Stats for camera: 0: ANDROID_SCALER_AVAILABLE_RAW_SIZES: 4208x3120, 4096x2160, 2104x1560, 1920x1080, 1280x720, 2104x1506, ANDROID_SCALER_AVAILABLE_PROCESSED_SIZES: 4160x3120, 4056x3040, 4000x3000, 3040x3040, 3016x3016, 3840x2160, 3648x2736, 3264x2448, 3200x2400, 2976x2976, 3044x1720, 2704x2028, 2704x1520, 2592x1944, 2688x1512, 2028x1144, 2160x2160, 1920x2160, 1920x1920, 1880x1880, 2048x1536, 1920x1440, 1920x1080, 1600x1600, 1600x1200, 1520x1520, 1440x1080, 1080x1080, 1280x 960, 1340x 760, 2560x 800, 1280x 800, 1280x 400, 1280x 768, 1280x 720, 1200x1200, 1280x 640, 1280x 480, 1040x 780, 1024x 768, 960x 960, 720x 720, 800x 600, 960x 720, 848x 480, 858x 480, 864x 480, 800x 480, 720x 480, 640x 480, 640x 240, 640x 360, 480x 640, 480x 480, 480x 360, 480x 320, ANDROID_SENSOR_INFO_SENSITIVITY_RANGE min = 41 max = 3987 ANDROID_SENSOR_MAX_ANALOG_SENSITIVITY 332 ANDROID_SENSOR_INFO_EXPOSURE_TIME_RANGE min = 20678ns max = 683881516ns
On VOXL2, voxl-camera-server -l shows the following for the hires (M0025-2):
Stats for camera: 2: ANDROID_SCALER_AVAILABLE_RAW_SIZES: 4208x3120, 4096x2160, 2104x1560, 1920x1080, 1280x720, ANDROID_SCALER_AVAILABLE_PROCESSED_SIZES: 4208x3120, 4096x2160, 2104x1560, 1920x1080, 1280x 720, ANDROID_SENSOR_INFO_SENSITIVITY_RANGE min = 54 max = 431 ANDROID_SENSOR_MAX_ANALOG_SENSITIVITY 431 ANDROID_SENSOR_INFO_EXPOSURE_TIME_RANGE min = 15723ns max = 683714540ns
On both VOXL1 and VOXL2 setups i have the ToF, hires and tracking.
Both runs voxl suite 0.9 -
@Chad-Sweet would appreciate it if you could take a second look at this pls
-
i investigated deeper. Im somewhat certain that the "loss of FOV" is a software/driver issue - nothing to do with the actual hardware.
Picture tells a thousand words - pls refer to the various resolutions used on VOXL2 and VOXL1.
On VOXL2 It seems that i am able to get the full HFOV if the aspect ratio is 1.777 (1280 divide by 720) although the VFOV is still "missing".
But with aspect ratio of 1.333 (640 x 480 and 1280 x 960), i lose both HFOV and VFOV.
This is in contrast to the full H and VFOV that i can get on VOXL1 even when the aspect ratio is 1.333 (640 x 480)
Could it be related to the "missing" ANDROID_SCALER_AVAILABLE observation in the earlier post above? Im running SDK 0.9
-
The ISP is configured differently between the two chipsets. There's no right or wrong way to do cropping. It seems you could use an aspect ratio that works well for what hat you are trying to achieve and crop in software to what you would like
-
Yes i could crop in software to get what i need, but i believe that the camera server first has to output the "full FOV" without cropping away the vertical FOV?
If you could refer to the bottom two pictures - the HFOV are the same but the VFOV for the VOXL2 is narrower - possibly cropped away.
I am unable to find a resolution/aspect ratio that outputs the full FOV the way VOXL1 did. Could you advise how to?
-
And to highlight the downstream impact:
If i were to still go ahead with 1280x720 (despite missing VFOV), due another issue on voxl-streamer that incorrectly flattens the output (you can read about this bug HERE, what voxl-streamer eventually outputs look like this extremely elongated/flattened monstrosity :
I would greatly appreciate it if the devs could look into this issue as it affects the entire hires streaming functionality.
-
The latest software on dev supports an updated streaming capability with h264 encoding performed in the hardware using OMX inside of voxl-camera-server
see this doc on voxl-streamer config
this doc on hires_stream output -
@Chad-Sweet said in Same hires cam part number but different FOV?:
The latest software on dev supports an updated streaming capability with h264 encoding performed in the hardware using OMX inside of voxl-camera-server
see this doc on voxl-streamer config
this doc on hires_stream outputThis is great news!
Appreciate the update! -
@Chad-Sweet how can I update just the voxl-camera-server and voxl-streamer and their dependencies to obtain this fix without having to update the entire sdk from the dev branch?
-
That is not really possible, there are too many interdependencies