ronshnapp / MyPTV

MyPTV is an open source library designed for 3D particle Tracking (3D-PTV) measurements
MIT License
41 stars 15 forks source link

camera orientation initial guess files are missing in /example #7

Closed alexlib closed 2 years ago

alexlib commented 2 years ago

The manual suggests creating an empty file and starting iterations of 1-2 in the calibration, but this process does not converge to anything useful for the cam1 in /example. I suggest adding some explanation on how to create a reasonable initial guess or providing some file that a user can iterate 3-5 times and reach some result.

ronshnapp commented 2 years ago

That's strange. In my last commit there were three files, cam1, cam2 and cam3, which were somehow lost in our earlier commits from today. I had just added the camera files again, and they have decent calibration solutions. Can you make sure they are there, and that they work properly (including saving) on the windows machine?

alexlib commented 2 years ago

well, it's rather simple - you cannot call cam1 both the file (without extension) and a folder that contains images Cam1 on platforms that do not recognize Caps. so please use extensions :)

alexlib commented 2 years ago

cam1_ori or cam1.ori or cam1_orientation.txt or whater is clear for you. i think also YAML file would be nice:

cam_id : 1
filename: cam1.ori
calibration image : Cam1/cal1.tif
pos: [0,0,0]
angles: [0,0,0]
shift: [0,0]
R: [[1,0,0],[0,1,0],[0,0,1]]
alexlib commented 2 years ago

what is recommended to calibration cameras 2 and 3? to change the same YAML file or to create other YAML files?

ronshnapp commented 2 years ago

About the camera file names - I get the feeling that extensions might "confuse" Windows into searching an "appropriate" program to open the files. The name of the camera files are given automatically by the camera name property, so one chooses to, they can opt for a camera name with an extension. Therefore, I think changing the name of the Cam1 etc. folders in the example might be a better solution (I just did this).

About the YAML files suggestion - it is something to consider, however we first need to make sure that the correction matrix, which usually has values is configured ok. I will look at this soon.

About cameras 2 and 3 - they both have acceptable calibrations as can be seen from the low error values (try the workflow -> calibration which prints the calibration error), however they can allways be improved by trying to minimize their erorrs (again through the workflow -> calibration).

alexlib commented 2 years ago

About cameras 2 and 3 - they both have acceptable calibrations

but the manual does not explain what to do with the YAML file. At the moment this file has calibration and segmentation for cam1 but the rest is for other workflow parts, right? So if I have multi-camera system - what is the recommended approach? to create 3 YAML files per camera with calibration and segmentation only, and then tracking, etc. in another YAML file?

ronshnapp commented 2 years ago

The process I was thinking about is that every time a user wants to calibrate a camera, they should change the parameters in the parameter file (i.e. camera_name, calibration_points_file, segmented_points_file, and calibration_image are changed every time we calibrate a camera. The alternative would be to have all the cameras as a nested list, and to set it up that the workflow.py would ask the user what camera they wanted to calibrate every time the calibration sequence starts. I guess it could work, but I'm not sure which option would be better. What do you think?

alexlib commented 2 years ago

I think there is some lack of clarity in the tutorial: a) in the present YAML file, when I run the first calibration, I get the image of all the segmented points, so it's now confusing me if I had to change the file name to something else? I'm confused with the terms cal_points1_full, cal_points1, cal_blobs1 - what I mean is that the name is not explaining what it contains, and they're all similar and repeat themselves in some sense.

b) I'm not sure if it's a good idea or not - to have target_file numbered, i.e. has a unique ID for every point - thus, when we click on 6 points, we can give their IDs and also when we try to compare match_target visually - we can try to see if the numbers are in some order. That was working well for openptv.

c) I think that YAML files need to be split. There are too many things in one file, calibration of one camera, segmentation of one camera (that should be probably different for calibration images and the authentic particle images so that we might want a different set of parameters), then matching, etc. I do not think that a nested large YAML file is a good idea - cause if it gets corrupted, it might destroy many things. In OpenPTV, we have a set of parameter files .par that you can make .yaml files, but the principle is the same - it's then straightforward to modify each (give them direct names, e.g. calibration_cam1.yaml, segmentation_cal1.yaml and so on.

ronshnapp commented 2 years ago

I just updated a bit the workflow and the user manual to try and explain better the calibration process (there'se some information tht might be usefull also fr the OpenPTV users, explanining the camera system of reference).

About splitting the YAML file - it is possible to have the different sections of the parameters (i.e. calibration, segmentation, etc.) each in a different file. However, I think this is a matter of taste - would you perfer to have the experiment folder cluttered or the file. I personally, this that having the file cluttered but the directory clean is more convenient, so I'll keep the example in this format. Then, if any user wishes to do so, they may split it into several files.

Would you like to use the OpenPTV test_cavity example and see that if it works good for you?

alexlib commented 2 years ago

test_cavity would be great. I already started here https://github.com/alexlib/test_cavity_myptv let's meet online to get things going faster.