Export COLMAP in standard

[PLAN8]

Regarding .dng, we will fix it in 2.2.0. Thanks for telling about the problem!

That's great thank you!

If we could chose which pointcloud to export, that would be the highest request from me! Thanks!

[Uygar]

Hello solosails,


Please check if you are able to get the desired export result from Metashape Standard 2.1.3 pre-release via File Menu -> Export Cameras dialog -> Colmap (*.txt) type.


The links to the pre-release are below:
https://download.agisoft.com/metashape_2_1_3_x64.msi
https://download.agisoft.com/metashape_2_1_3.dmg
https://download.agisoft.com/metashape_2_1_3_amd64.tar.gz

If you have any feedback related to this new feature, please let us know.

Hi. We need dense cloud export Colmap standart. Can you release this feature .

[PolarNick]

can you add the option to export a dense cloud as well as or instead of the sparse cloud?

In Colmap format's points3D.txt - points need to have their projections (named 'Track') in cameras - see https://colmap.github.io/format.html#points3d-txt . Such tracks exists for Tie Points because Sparse Cloud was created from 2D keypoints detected in images and then - those 2D keypoints were matched between images and were transformed into 3D Tie Points.

Dense Cloud can be exported in such format because points in Dense Cloud doesn't have tracks - it is unknown what cameras observe which points (and what points were occluded), moreover - such information is too heavy to be represented in text-based points3D.txt+images.txt efficently, because these files formats were not supposed to be used in such way.

So, it makes sense to export Dense Cloud only if some GS implementation can use it AS IS - without tracks - i.e. without projections in cameras, because Dense Cloud doesn't have it by its nature. Do you know such GS implementations? May be they support plain and simple .ply-file import? If so - you can just Export+Import+Use Dense Cloud via .ply-binary format.

[PLAN8]

can you add the option to export a dense cloud as well as or instead of the sparse cloud?

In Colmap format's points3D.txt - points need to have their projections (named 'Track') in cameras - see https://colmap.github.io/format.html#points3d-txt . Such tracks exists for Tie Points because Sparse Cloud was created from 2D keypoints detected in images and then - those 2D keypoints were matched between images and were transformed into 3D Tie Points.

Dense Cloud can be exported in such format because points in Dense Cloud doesn't have tracks - it is unknown what cameras observe which points (and what points were occluded), moreover - such information is too heavy to be represented in text-based points3D.txt+images.txt efficently, because these files formats were not supposed to be used in such way.

So, it makes sense to export Dense Cloud only if some GS implementation can use it AS IS - without tracks - i.e. without projections in cameras, because Dense Cloud doesn't have it by its nature. Do you know such GS implementations? May be they support plain and simple .ply-file import? If so - you can just Export+Import+Use Dense Cloud via .ply-binary format.

Hi, Thank you for taking the time to come back with the detailed response on this.

I have been experimenting with replacing the points3D.txt with a dense pointcloud exported from Metashape, then reduced using cloudcompare, then converting to the correct colmap points3D.txt format and replacing the original sparse/tie points file exported by Metashape.

This altered Colmap points3D.txt file (without projections data) imports into Jawset Postshot for Gaussian Splatting processing with no issue and produces far greater accuracy than using just the tie points alone.

So, I guess that even if it may not work with all GS processing software (I havent tried with Nerfstudio (can someone please?)) It does appear to work with Postshot using the dense pointcloud -

So.. if it is possible to add the option for which pointcloud to use in the export anyway, this would be very handy, as it means that all Colmap file compilation can be made all inside of Metashape with no further conversion stages after the export.


Also, just to request it again, can you also add the option to choose whether to export the undistorted images as well, so that repeat processing is not required for this stage of export, which would save a lot of time.

Many thanks! I really appreciate your effort on this topic!

[PolarNick]

This altered Colmap points3D.txt file (without projections data) imports into Jawset Postshot for Gaussian Splatting processing with no issue and produces far greater accuracy than using just the tie points alone.

Nice. Have you tried to directly use Dense Cloud .ply file in Postshot (without mimicking points3D.txt)? It seems that it should also work - https://www.jawset.com/docs/d/Postshot+User+Guide/Importing+Images

[PLAN8]

This altered Colmap points3D.txt file (without projections data) imports into Jawset Postshot for Gaussian Splatting processing with no issue and produces far greater accuracy than using just the tie points alone.

Nice. Have you tried to directly use Dense Cloud .ply file in Postshot (without mimicking points3D.txt)? It seems that it should also work - https://www.jawset.com/docs/d/Postshot+User+Guide/Importing+Images

Hi, No, I haven't yet, but I suspect that the mixing of Colmap import alongside of ply might not work - I shall try and report back

[PLAN8]

Having tried adding the ply file to the colmap sparse folder, the import works, but it is unclear as to which cloud is being used, I suspect that the ply is being ignored.
Furthermore, I tried importing the ply separately, but PS complains that two image sets cannot be processed at once.

So, I think to conclude, this is not possible to mix dataset formats.

[PolarNick]

So, I think to conclude, this is not possible to mix dataset formats.

It seems that in terms of export formats - Metashape allows to export Colmap format with information about cameras + tie points, also it supports export of dense point cloud.

Postshot supports Colmap format with information about cameras and tie points, it also supports import of dense point clouds in .ply format, but unfortunately it is not possible to import such dense clouds after importing Colmap project (to replace tie points with dense cloud).

IMHO it is more reasonable to add such an import function on the Postshot side than to add a workaround in Metashape in the Colmap format export, because a dense point cloud cannot fully mimic tie points (dense cloud doesn't have projections), and so - this is a workaround (with all related problems like 'what if somebody will use it to export into another app which relies on projections', and so on).

[PLAN8]

Hi, Yep, I get what yore saying, but I think the ability to have the option to choose "true" colmap export or altered export using the dense cloud should still cover both options? But if its not possible to add that option, then I guess thats the end of that request.

Which does leave the other quite important option to add is the ability to not export the images every time, saving a lot of export processing time for repeat exports with minor non image altering exports... if that could be scheduled to be added, that would be a really useful option to speed work flows.

I do suspect that there will be a lot of interest in purchases of your standard edition for gaussian mapping users, so making it as user friendly as possible would be a good thing for all I suspect!

Many thanks!!

[3create]

I'd like to chime in here:

1. dense point clouds exported from Metashape as points3d work fine in both Nerfstudio and Postshot.
I have a customized version of the gaussian export script which does exactly this. A friend programmed this for me, but it's a kind of a workaround which we therefore couldn't offer Open Source (unlike the Masks implementation we added to the script).
But @ PolarNick, I can of course provide you this script version for internal examination.
One has to install open3d for Metashape manually, and the script internally creates a tmp ply version, reads it back in an then exports it as points3d. A hack which Metashape developers can probably solve in a cleaner fashion, with direct access to the dense cloud points via Python API.
The script chooses the currently active Dense Point cloud in Metashape for export (which I find is a neat solution if the project contains multiple dense point clouds).

I guess replacing the points3d.txt is still compatible with colmap, unlike changing the images.txt with its matching points (although that 2d-matching information isn't needed for Gaussian Splatting reonstructions).
And I personally favour such a points3d approach, rather than mixing this with a ply file or similar.

2. Yes, it would be _extremely_ useful to be able to disable the export of images (like in the script version), due to the long time undistorting takes.
There are many use cases for this (as also mentioned in post above).

3. Looking ahead, it's only a matter of time until fisheye camera models are fully supported for Gaussian Splatting.
The first steps were already made in Nerfstudio's latest GSplat version (1.4).
That's why I think an option to:
a) create idealized fisheye images on export, with the cameras.txt parameters following the OpenCV Fisheye convention, or
b) leave the images as-is, but adapt the cameras.txt  (p1/2, b1/2 intrinsics get lost in this case, but something which is acceptable for OpenCV compatibility?!)

Point 3) should probably be in an advanced section of the export dialog, as users will need to know what they are doing. Maybe also point 2)?

For any discussions of this closer to the 3dGS applications, I'm on the Nerfstudio and Postshot Discord servers as @pics23d

Thanks!

[PLAN8]

I'd like to chime in here:

1. dense point clouds exported from Metashape as points3d work fine in both Nerfstudio and Postshot.
I have a customized version of the gaussian export script which does exactly this. A friend programmed this for me, but it's a kind of a workaround which we therefore couldn't offer Open Source (unlike the Masks implementation we added to the script).
But @ PolarNick, I can of course provide you this script version for internal examination.
One has to install open3d for Metashape manually, and the script internally creates a tmp ply version, reads it back in an then exports it as points3d. A hack which Metashape developers can probably solve in a cleaner fashion, with direct access to the dense cloud points via Python API.
The script chooses the currently active Dense Point cloud in Metashape for export (which I find is a neat solution if the project contains multiple dense point clouds).

I guess replacing the points3d.txt is still compatible with colmap, unlike changing the images.txt with its matching points (although that 2d-matching information isn't needed for Gaussian Splatting reonstructions).
And I personally favour such a points3d approach, rather than mixing this with a ply file or similar.

2. Yes, it would be _extremely_ useful to be able to disable the export of images (like in the script version), due to the long time undistorting takes.
There are many use cases for this (as also mentioned in post above).

3. Looking ahead, it's only a matter of time until fisheye camera models are fully supported for Gaussian Splatting.
The first steps were already made in Nerfstudio's latest GSplat version (1.4).
That's why I think an option to:
a) create idealized fisheye images on export, with the cameras.txt parameters following the OpenCV Fisheye convention, or
b) leave the images as-is, but adapt the cameras.txt  (p1/2, b1/2 intrinsics get lost in this case, but something which is acceptable for OpenCV compatibility?!)

Point 3) should probably be in an advanced section of the export dialog, as users will need to know what they are doing. Maybe also point 2)?

For any discussions of this closer to the 3dGS applications, I'm on the Nerfstudio and Postshot Discord servers as @pics23d

Thanks!

Really great points - I agree with all of these!