Forum

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - matt07lx

Pages: [1] 2
1
Hi Paul,

Thanks again - I appreciate your ideas. Unfortunately, while that resolved the issue with the size, it didn't change the final result. There was clearly something wrong with the chunk transform matrix, but I couldn't figure it out. In the end, I found this script for copying the region from one chunk to another: https://github.com/agisoft-llc/metashape-scripts/blob/master/src/copy_bounding_box_dialog.py. I was able to adapt it to my needs. It takes a different approach and doesn't require converting the coordinates at all.

2
Hi Paulo,

Thanks for the suggestion. I tried this and now the region disappears entirely when I apply to the same project or a new one. Any other ideas?

3
Hi All,

I'm attempting to create a python script that will copy the reconstruction region from one project and export it to a new script that will then apply the same region to other projects. My projects all use the same projected coordinate system, and are located in the same geographic space, so this should work in theory. I'm aware from other posts that the region's coordinates use the chunk's internal system, and that these need to be converted to geocentric, then projected to the proper CRS. When applying them to a new project, this process needs to be done in reverse. When I run the script within the same project it works perfectly. I can save the new script, change the region, then reset it using the new script. However, when I try to apply the new script to a different project in the same location, using the same CRS, it creates a region that is incorrect. Does anyone know where I'm going wrong?

Script to capture the original region:
Code: [Select]
import Metashape, os, glob

doc = Metashape.app.document
chunk = doc.chunk
region = chunk.region
center = chunk.region.center
rot = chunk.region.rot
size = chunk.region.size
crs = chunk.crs
T = chunk.transform.matrix

#File name must include *.py extension
file = Metashape.app.getSaveFileName("Save Script as")

print("Local Bounding Region Coordinates:")
print("Center: ",center)
print("Rotation: ",rot)
print("Size: ",size)

#Now convert them to the project CRS
#center and size are Metashape.Vector
#rotation is Metashape.Matrix - this needs to be broken into three vectors to be converted
#All are changed to strings to write to the new script file
center_CRS = chunk.crs.project(T.mulp(center)) # vector with point coordinates in CRS
center_CRS = str([center_CRS[0],center_CRS[1],center_CRS[2]])
size_CRS = chunk.crs.project(T.mulp(size)) # vector with point coordinates in CRS
size_CRS = str([size_CRS[0],size_CRS[1],size_CRS[2]])
rot1_CRS = chunk.crs.project(T.mulp(Metashape.Vector([rot[0,0], rot[0,1], rot[0,2]]))) # vector with point coordinates in CRS
rot1_CRS = str([rot1_CRS[0],rot1_CRS[1],rot1_CRS[2]])
rot2_CRS = chunk.crs.project(T.mulp(Metashape.Vector([rot[1,0], rot[1,1], rot[1,2]]))) # vector with point coordinates in CRS
rot2_CRS = str([rot2_CRS[0],rot2_CRS[1],rot2_CRS[2]])
rot3_CRS = chunk.crs.project(T.mulp(Metashape.Vector([rot[2,0], rot[2,1], rot[2,2]]))) # vector with point coordinates in CRS
rot3_CRS = str([rot3_CRS[0],rot3_CRS[1],rot3_CRS[2]])
#rot_CRS = Metashape.Matrix([rot1_CRS,rot2_CRS,rot3_CRS])
#the three elements to create region are now in the CRS
print("Bounding Region Coordinates in CRS")
print("Center: ",center_CRS)
print("Rotation: ",rot1_CRS,"\n",rot2_CRS,"\n",rot3_CRS)
print("Size: ",size_CRS)

content = ("import Metashape, os, glob\ndoc = Metashape.app.document\nchunk = doc.chunk\nregion = chunk.region\nT = chunk.transform.matrix\n\n#import the region coordinates in CRS\ncenter_CRS = Metashape.Vector(%s)\nsize_CRS = Metashape.Vector(%s)\nrot1_CRS = Metashape.Vector(%s)\nrot2_CRS = Metashape.Vector(%s)\nrot3_CRS = Metashape.Vector(%s)\n\n#But now we'd have to convert these back to the local chunk coordinates\ncrs = chunk.crs\nbb_center = T.inv().mulp(crs.unproject(center_CRS))\nbb_size = T.inv().mulp(crs.unproject(size_CRS))\nbb_rot1 = T.inv().mulp(crs.unproject(rot1_CRS))\nbb_rot2 = T.inv().mulp(crs.unproject(rot2_CRS))\nbb_rot3 = T.inv().mulp(crs.unproject(rot3_CRS))\nbb_rot = Metashape.Matrix([bb_rot1,bb_rot2,bb_rot3])\n\n#assign the new coordinates to the bounding box in other projects\nchunk.region.center = bb_center\nchunk.region.rot = bb_rot\nchunk.region.size = bb_size\n" % (center_CRS, size_CRS, rot1_CRS,rot2_CRS, rot3_CRS))

with open(path, 'w') as file:
  file.writelines(content)

print("Script exported to: ",path)

Example of a new script output by the above:
Code: [Select]
import Metashape, os, glob
doc = Metashape.app.document
chunk = doc.chunk
region = chunk.region
T = chunk.transform.matrix
crs = chunk.crs

#import the region coordinates in CRS
center_CRS = Metashape.Vector([2326260.9766565366, 4694783.921291048, 383.9612362860649])
size_CRS = Metashape.Vector([2326255.3612297955, 4694784.090214137, 381.2784408229167])
rot1_CRS = Metashape.Vector([2326260.9183688844, 4694785.530955884, 385.6499192495625])
rot2_CRS = Metashape.Vector([2326260.3992965193, 4694785.620727421, 385.6765585270715])
rot3_CRS = Metashape.Vector([2326260.636379602, 4694785.3316533305, 386.04862309706607])

#But now we'd have to convert these back to the local chunk coordinates
bb_center = T.inv().mulp(crs.unproject(center_CRS))
bb_size = T.inv().mulp(crs.unproject(size_CRS))
bb_rot1 = T.inv().mulp(crs.unproject(rot1_CRS))
bb_rot2 = T.inv().mulp(crs.unproject(rot2_CRS))
bb_rot3 = T.inv().mulp(crs.unproject(rot3_CRS))
bb_rot = Metashape.Matrix([bb_rot1,bb_rot2,bb_rot3])

#assign the new coordinates to the bounding box in other projects
chunk.region.center = bb_center
chunk.region.rot = bb_rot
chunk.region.size = bb_size

4
General / GCPs vs Scale Bars
« on: April 18, 2023, 10:08:29 PM »
I was wondering if somebody could explain the relationship of ground control points and scale bars within a model. If you use both, are scale bars considered to be "more accurate" in scaling, and hence prioritized? In my typical use, GCPs are set with a total station, in which error typically is around a cm, whereas I can use target based scale bars with errors lower than a mm. Do the scale bars simply as a control to check the GCP errors, or do they improve the accuracy of the model scale?

5
General / Characterize Model Accuracy in Real World Units?
« on: April 06, 2023, 07:35:06 PM »
Hi All - I was wondering if anyone can suggest the best method for characterizing a model's accuracy in terms of real units (e.g. meters)? Thinking through this problem, it seems to be that using a calibrated scale bar (with targets) might offer the best reading of overall model accuracy since the target centers can be located with high precision. GCPs set with a total station or GPS will likely have errors larger than a cm or more, so these can't be used to understand model accuracy below this level. I don't know how well the scale bar error characterizes the accuracy across the whole model though, since they will only be a small part of the overall model.

I've wondered if the reprojection RMS error (pixels) can somehow can be converted to real world units? If I were to take the average RMS reprojection pixel error and multiply it by the ground resolution, would that give an approximation of the average error in real units?

6
Python and Java API / Re: Batch processing of numerous PSZ files
« on: August 07, 2019, 07:45:07 PM »
Hi Alexey,

Thank you so much for your very quick response! This works perfectly, and I was able to adapt it for my needs. Can I also ask if you plan to add a Python function to enable select dense cloud points by shape? I would like to batch process a number of projects with a single shape to produce models with the exact same extents.

7
Python and Java API / Re: Batch processing of numerous PSZ files
« on: August 07, 2019, 05:12:48 PM »
Sorry for restarting an old post, but is there any way to change this script to include psz files in all subdirectories, too? I have all of my projects organized in this way and want to batch process a number of different psz files in multiple subdirectories. I tried to make this work, but with my limited knowledge of Python I couldn't make it work.

Thanks so much!

8
Bug Reports / Re: Sketchfab Upload: "OpenSSL Library Not Found"
« on: July 22, 2019, 08:11:26 PM »
Yes, I've tried 1.0.2.s, which is the only 1.0.x version currently available: https://slproweb.com/products/Win32OpenSSL.html


9
Bug Reports / Sketchfab Upload: "OpenSSL Library Not Found"
« on: July 22, 2019, 07:41:10 PM »
I get the following message when I try to upload to Sketchfab directly from Metashape: "OpenSSL Library Not Found: Please Install OpenSSL 1.0 for Data". I've installed several versions of OpenSSL (64 and 32 bit), restarted Metashape and my computer, and nothing seems to work. Any ideas? I've never had this issue before.

10
Florian,

Thanks so much for sharing the latest version of the script. When I run it now I get the following error: "UnboundLocalError: local variable 'a' referenced before assignment". Do you have any thoughts as to why I am getting this error?

11
Can anyone confirm if this works in 1.5? I've tried running it and it just freezes upon trying to build the orthomosaic.

12
General / Palaeo3D Scale Bars?
« on: June 06, 2019, 11:58:44 PM »
Just curious if anyone has purchased scale bars from Palaeo3D (http://palaeo3d.de/WP/?page_id=23). They are much more affordable than the ones made by Cultural Heritage Imaging (http://culturalheritageimaging.org/What_We_Offer/Gear/Scale_Bars/index.html), but I'm wondering how durable they are. If anyone out there has a set, would you say they are appropriate for archaeological fieldwork? Will they break easily since they are foam?

13
General / Identify Coordinates of Object Center?
« on: January 24, 2019, 06:58:19 PM »
Is there currently a way to identify the coordinates (in a projected coordinate system) of a 3D model's center point? Alternatively, is there a way to create a target or point on the center of the model that will help me get these coordinates? Perhaps a python script can be written to do this? I need the coordinates of the center in order to correctly locate the model when imported to ArcGIS (there are known issues with locating georeferenced models in ArcGIS. I think this may help me develop a workflow to get around these issues).

Thanks!

14
General / Re: Model Location shift after import to ArcScene
« on: September 18, 2017, 12:43:06 AM »
Just in case anyone else ever finds this, I thought I would share the that I was able to figure this out. It had to do with the length of the UTM coordinates. I found this old threat that describes how to trim the number of digits using the "Shift" parameters in the Export Model dialogue: http://www.agisoft.com/forum/index.php?topic=452.msg26554#msg26554

After shortening the UTM coordinates, I'm now able to import the COLLADA models into ArcScene and they are aligned perfectly. They also display the texture correctly after the first step! I don't have to use the awkward process where you have to do "Replace With Model" from a model in Local Coordinates, as there are numerous tutorials out there explaining. The problem is the length of the UTM coordinates.

15
General / Model Location shift after import to ArcScene [Solved]
« on: September 16, 2017, 06:29:01 AM »
This is more of a GIS question than Photoscan, I suppose, but I figure someone here might know the answer. I created a series of models in Photoscan of archaeological layers that are all georeferenced using the same markers shot with a total station one time. Therefore I am able to stack them in several programs (CloudCompare and Photoscan, too, by appending the various models into the same project), and they align perfectly since they use the exact same markers with the same exact UTM coordinates. However, when I import the Collada files into ArcScene as multipatch layers, each model ends up slightly shifted (perhaps a few centimeters). Nothing aligns perfectly, even when if I import the UTM coordinates of the markers as a shapefile.

The odd thing is that I've even checked the orthomosaic files from the same models, and they align in ArcMap perfectly, and the UTM markers are precisely located on the targets, etc. What's the difference between orthomosaics in ArcMap and multipatch files in ArcScene that I'm missing? Is it something to do with the UTM coordinates getting rounded down or something in the conversion from Collada to multipatch?

Pages: [1] 2