@afdrus , just to be safe, you should put the absolute path of the .pgm file staticMaskFileName, otherwise the qvio executable will probably try to load from the path that is being executed from. Absolute path would look like /etc/modalai/vio_mask.pgm or similar.
Regarding feature allocation, I don't think that there is an option to tweak this directly. FYI here is a documentation for the all the parameters that qvio algorithm accepts:
https://developer.qualcomm.com/sites/default/files/docs/machine-vision-sdk/api/v1.2.13/group__mvvislam.html#ga6f8af5b410006a44dbcf59f7bc6a6b38
Keep in mind that there are two types of features, what we typically call in-state and not in-state. in-state are the features that are used in the pose solution directly. not in-state features are the features that are tracked but not used in the pose solution. If your vehicle is stationary and performs a yaw, you can detect new features, but it is impossible to figure out how far they are - you need to actually move around. So it is possible, that you are looking at the in-state features only, so after a yaw maneuver, there will be no new in-state features due to lack of motion. So the worst case scenario is if you do a 180 degree yaw without any motion, so you will pick up a lot of new features but would not know how far they are. Luckily, flying vehicles usually do not turn precisely in place, so even a bit of x-y-z motion will help localize the features right away.
If you really wanted to have better tracking during turns, you could consider having a turns with non-zero radius, so that there is a bit of translation in addition to rotation, so that new features can be instantly localized.
You can find more information about feature point quality here : https://developer.qualcomm.com/sites/default/files/docs/machine-vision-sdk/api/v1.2.13/structmv_v_i_s_l_a_m_map_point.html.
Looking at qvio overlay function, it draws both in-state and not in-state features, so you can observe more closely what happens to the features as you rotate..