Questions about image order and prior_* columns in database

[Beniko95J]

1. I found that the order of image ids in the database is sometimes the same as the order of their names(which are their timestamps), while sometimes not. like this case is not well ordered: this is well ordered: I hope the order of image ids in the database is always the same order as their names (which contain their timestamps). Is there any way to do this?

2. I am going to use relative poses estimated by visual-inertial odometry as initial image poses for better image registration. I found that there have been columns like prior_tx, prior_ty and etc. in the images table in the database, but it seems like that colmap never uses them in its reconstruction pipeline, isn't it? If not, I will need to be careful about change these values in the database without changing the current behavior of colmap. I would like to confirm it with you.

Thanks!

[silence401]

I also found the database sometimes is not ordered and maybe this link can solve the second problem for you ? https://github.com/colmap/colmap/issues/559#issuecomment-457926309

[Beniko95J]

@silence401

This link seems to be invalid. Could you please send it again?

[silence401]

https://github.com/colmap/colmap/issues/559#issuecomment-457926309

[Beniko95J]

@silence401

Thanks! This comment is very helpful. By the way, are the prior poses needed for spatial matcher the projection from world to the camera coordinate system or from camera to world?

[silence401]

@silence401

Thanks! This comment is very helpful. By the way, are the prior poses needed for spatial matcher the projection from world to the camera coordinate system or from camera to world?

I am not very clear about it, you can see the document about colmap ,there is a description about spatial matcher in tutorial

[ahojnnes]

1. The image_id in the database cannot be assumed to be ordered.
2. The prior_q* values are not used anywhere in the pipeline. Simple IMU rotation/translation constraints could be easily added to the bundle adjuster though.
3. The prior_t* values are used in the spatial matcher but this more intended for GPS like data to determine which images to match.

[silence401]

1. The image_id in the database cannot be assumed to be ordered.

2. The prior_q* values are not used anywhere in the pipeline. Simple IMU rotation/translation constraints could be easily added to the bundle adjuster though.

3. The prior_t* values are used in the spatial matcher but this more intended for GPS like data to determine which images to match.

Does the reconstruct sparse/dense model from known camera poses pipeline use the prior_q* and prior_t* values ? And where to use them.

[ahojnnes]

No, it doesn’t. It uses the images/cameras.txt/.bin. Please follow the instructions in the FAQ for this.

[silence401]

No, it doesn’t. It uses the images/cameras.txt/.bin. Please follow the instructions in the FAQ for this.

Thanks for your reply,I just use the GPS information as the camera pose and write it in the images.txt.But the reconstruct result absolutely wrong.Does the GPS information need some translations to be used in the pipeline ? Thanks.

[YasmineCupcake]

I wish this would be mentioned!! I spent hours on this to realize at the end that the pictures aren't ordered and that images_id isn't the real order of the images i put as input, a bit confusing ngl

[YasmineCupcake]

never mind sir it loaded them all in order, IM SO GLAD UGH