1
General / Re: Export initial camera positions PRIOR to alignment
« on: August 19, 2019, 11:57:27 AM »
Thanks for the prompt response Paulo, that was exactly what I was looking for. I had just been looking in the wrong locations..
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.
2
General / Export initial camera positions PRIOR to alignment
« on: August 16, 2019, 10:53:30 AM »
I reckon this may be somewhat of a silly question, but is there a way to export the initial camera positions/orientations (as stored and imported by Agisoft from the image's metadata) prior to alignment? I understand there's an option to 'Export Cameras' in order to do so (and to export the calculated positions), but this is only available after alignment and provided a georeferenced chunk is available. I'm not interested in the computed positions though. All I want is to import my images into Agisoft, use the built-in converter to convert the WGS84 information to another CRS and subsequenly export the resultant converted coordinates to a text/csv file.
Thanks in advance!
Thanks in advance!
3
General / Resize Bounding Box: Fit-to-shape
« on: April 08, 2019, 03:39:29 PM »
Dear all,
I'm sure we can all agree that resizing the Bounding Box accordingly can be somewhat of a cumbersome process. Although this might (perhaps) be relatively straightforward for smaller datasets it can be a real pain to size it correctly when working with larger datasets. On the one hand this requires one to zoom in sufficiently in order to pinpoint the exact location of each corner with respect to the model. At the same time, however, it is deemed necessary to be zoomed out completely in order to keep track of the other three corners moving as one is relocated. The fact that the blue dots and white lines (indicating the corners and connecting lines respectively) can be really tricky to discern, especially when displaying a sparse/dense cloud in the background, make this proces even harder. Not to mention it can be rather troublesome to rotate the box to correctly align with linear elements within the scene at times too.
This got me thinking there must be an easier (automated) way. More specifically, would it be possible to resize the bounding box to represent the minimum bounding rectangle based on the spatial extent or envelope of one or more selected features, such as markers or shape(s). See the attached figure for a simple demonstration of how such an automated resizing could look like. In fact such 'Minimum Bounding Geometry' operations are rather common within most GIS packages. This would also ensure the correct rotation of the bounding box with respect to the area one wishes to proces further.
I'm sure we can all agree that resizing the Bounding Box accordingly can be somewhat of a cumbersome process. Although this might (perhaps) be relatively straightforward for smaller datasets it can be a real pain to size it correctly when working with larger datasets. On the one hand this requires one to zoom in sufficiently in order to pinpoint the exact location of each corner with respect to the model. At the same time, however, it is deemed necessary to be zoomed out completely in order to keep track of the other three corners moving as one is relocated. The fact that the blue dots and white lines (indicating the corners and connecting lines respectively) can be really tricky to discern, especially when displaying a sparse/dense cloud in the background, make this proces even harder. Not to mention it can be rather troublesome to rotate the box to correctly align with linear elements within the scene at times too.
This got me thinking there must be an easier (automated) way. More specifically, would it be possible to resize the bounding box to represent the minimum bounding rectangle based on the spatial extent or envelope of one or more selected features, such as markers or shape(s). See the attached figure for a simple demonstration of how such an automated resizing could look like. In fact such 'Minimum Bounding Geometry' operations are rather common within most GIS packages. This would also ensure the correct rotation of the bounding box with respect to the area one wishes to proces further.
4
General / Re: Workflow to process the Photography of "PHANTOM 4 RTK"
« on: March 08, 2019, 10:54:29 AM »I have been doing some testing with the new P4R and getting some good results. I can't seem to enter the DJI dewarp Xmp data so that it means anything to Metashape, has anyone else yet? The auto adjusted camera parameters seem to been getting pretty good accuracy without GCP and even better just using 1 GCP.
Was flown with D-RTK2 base over known point shot with Trimble R10, lens correction turned off in RTK app. Ground control also shot with R10.
Coordinates converted to OSGB1936 in metashape before alignment and loading GCP.
I have tried to do a lens calibration with the chessboard in metashape but get very different parameters than what I see after a flight and optimisation. Anyone else been able to calibrate the P4R lens successfully with metashape?
Without running the optimisation the Z error is over 21cm but down to 6cm after. Using just one GCP tightens things up further to less than 3cm.
See reports https://drive.google.com/drive/folders/1LekTi82gf9Vq4cYkg_4s79YTnccYmgrr?usp=sharing
Let me know your thoughts.
Cheers
Have you verified the correctness of the transformation parameters in Photoscan/Metashape for transforming coordinates from WGS84 to OSGB1936. We've found that the parameters in Photoscan for going from WGS84 to our Dutch National CRS are incomplete and partly outdated, resulting in a couple cm of deviations in all axis. Hence we're transforming the data outside of Photoscan first before importing into it for further processing.
5
General / Re: Import CSV file - Camera orientation data is lost
« on: March 01, 2019, 05:43:35 PM »Hello BobvdMeij,
When the information is imported from CSV file the data for the corresponding instance in the Reference pane is completely re-written. So it doesn't just update a few selected fields.
Maybe you can export complete information from the Reference pane, then perform XYZ modification and import the data back?
Dear Alexey,
Thanks for the swift reply.
We've already tried the method you suggested, but we stumpled on a couple of things that need to be taken account. First of all the image's EXIF Yaw information is expressed within a -180/+180 range, whereas Photoscan defines Yaw along a 360 degree compass. The same goes for the Pitch metadata, where a perfectly nadir orientation in the image's own EXIF data states -90 degrees whereas Photoscan considers this as 0 degrees. Both these issues don't have to be a problem as these can be compensated for with simple algebra by adding 360 to the EXIF's Yaw value in case this is negative (<0) and subtracting 90 from the EXIF's Pitch.
The thing that struck us, however, is that something fishy goes on when the camera's Pitch angle is off-nadir facing slightly backwards (probably due to a sudden gust of wind). We've one instance where the EXIF metadata for that particular images reads a Pitch angle of -91.8 degrees, equaling a value of -1.8 degrees in Photoscan's referencing pane. In these instances, however, the addition/subtraction procedures described above are no longer applicable. See the attached screenshot. Even more interesting is that we've now found out that for these instances, when we add the EXIF's Roll value to the EXIF's Yaw value we are getting pretty close to the seemingly strange value that Photoscan procedures.
What's going on here?
6
General / Import CSV file - Camera orientation data is lost
« on: March 01, 2019, 01:59:43 PM »
Dear all,
We are dealing with an issue that results in the columns with camera orientation being lost upon importing a new CSV file containing adjusted camera position and accuracy data.
In short this is what we do:
- Import camera's+EXIF in Photoscan including position (lon, lat, GPSheight) accuracy (for lon, lat, GPSheight) and orientation (yaw,pitch,roll) information;
- Using external software we transform the original image position data stored in the EXIF/metadata to a local coordinate system (easting, northing, altitude)
- From the latter results a CSV file with 7 colums (ID, easting, northing, altitude, easting accuracy, northing accuracy, altitude accuracy)
- We then import the resultant CSV into Photoscan
As the camera-IDs in the CSV match with the Camera-IDs already present in Agisoft the imported data does correctly overwrite Long/Lat/GPSheight columns in the Reference pane. The same goes for the column storing the camera accuracy information. However, the data in the yaw/pitch/roll columns that WAS still present prior to importing the CSV is lost when the import is complete. See the attached screendump for a clarification.
Question: How can we preserve the original camera orientation data for Yaw/Pitch/Roll when importing a CSV file? We've already unchecked the 'Rotation' box in the ImportCSV window, hoping it would leave the orientation data as it is, but it does get rid of the orientation nonetheless.
Thanks in advance!
We are dealing with an issue that results in the columns with camera orientation being lost upon importing a new CSV file containing adjusted camera position and accuracy data.
In short this is what we do:
- Import camera's+EXIF in Photoscan including position (lon, lat, GPSheight) accuracy (for lon, lat, GPSheight) and orientation (yaw,pitch,roll) information;
- Using external software we transform the original image position data stored in the EXIF/metadata to a local coordinate system (easting, northing, altitude)
- From the latter results a CSV file with 7 colums (ID, easting, northing, altitude, easting accuracy, northing accuracy, altitude accuracy)
- We then import the resultant CSV into Photoscan
As the camera-IDs in the CSV match with the Camera-IDs already present in Agisoft the imported data does correctly overwrite Long/Lat/GPSheight columns in the Reference pane. The same goes for the column storing the camera accuracy information. However, the data in the yaw/pitch/roll columns that WAS still present prior to importing the CSV is lost when the import is complete. See the attached screendump for a clarification.
Question: How can we preserve the original camera orientation data for Yaw/Pitch/Roll when importing a CSV file? We've already unchecked the 'Rotation' box in the ImportCSV window, hoping it would leave the orientation data as it is, but it does get rid of the orientation nonetheless.
Thanks in advance!
7
General / Re: GCPs Have High Error Values
« on: January 24, 2019, 11:19:32 AM »
Assuming you've strictly followed SAV's workflow I reckon you've already done so, but just to be sure: can you please verify you've selected the correct coordinate system during import of the GCPs?
8
General / Re: Workflow to process the Photography of "PHANTOM 4 RTK"
« on: January 18, 2019, 10:26:00 AM »Hello Steve,
The accuracy values for the coordinates should be properly read from XMP, providing that you have enabled "Load camera location accuracy from XMP meta data" in the Advanced preferences tab.
If it doesn't happen, please provide any example of the image that you are using (either via forum or via email to support@agisoft.com).
What about camera calibration information Alexey? We have enabled 'Load camera calibration from XMP meta data' but the Initial tab within the Camera Calibration pane remains empty, except for f which is set to 3648 by default. Strangely enough this number is nowhere to be found in either the metadata or the XMP file. On the contrary all other fields (cx, xy, k1-k3, p1-p2, etc.) remain empty/are set to 0.
The XMP data, however, does contain values for most of these parameters stored within a parameter called 'drone-dji:DewarpData='. It seems that the image's Northing/Easting/Altitude are correctly imported from the XMP file, but the camera calibration parameters are not (although both options are enabled under preferences).
Ps. I'm well aware of your doubts on the accuracy, applicability and environment-independent calibration parameters provided by DJI for a consumer grade camera. But as we're witnessing a structural shift in our outputted models, particularly in the z-axis, we are willing to give these a priori calibration parameters a try to see if this fixes the problem.
9
General / Re: Extraction of XMP/EXIF data for editing outside Metashape
« on: January 07, 2019, 04:14:28 PM »
In the meantime we've managed to extract the image-ID, GPSlongtitude, GPSlatitude and GPSaltitude values from all images within a folder and writing this to a single .txt or .csv file using ExifTool.
However, when reimporting the .txt file with the transformed coordinates this also causes the Accuracy field in the Reference Pane to be reset to the default 10m. Is there any way to only overwrite the Long/Lat/Alt fields but keep all the other fields untouched?
However, when reimporting the .txt file with the transformed coordinates this also causes the Accuracy field in the Reference Pane to be reset to the default 10m. Is there any way to only overwrite the Long/Lat/Alt fields but keep all the other fields untouched?
10
General / Re: Extraction of XMP/EXIF data for editing outside Metashape
« on: January 07, 2019, 02:41:52 PM »Hello BobvdMeij,
Camera locations coordinates (Lat, Long and Altitude) are loaded from image EXIF, so the data from XMP is not loaded to the Reference pane, Relative and Absolute Altitude values are loaded to the camera.photo.meta and are stored in the project file, just for case anyone wants to use them.
The following script example will print out to the console the required tags for the cameras in the active chunk:Code: [Select]import Metashape
from xml.dom import minidom
elements = ["drone-dji:AbsoluteAltitude=", "drone-dji:GpsLatitude=", "drone-dji:GpsLongtitude="]
chunk = Metashape.app.document.chunk #active chunk
for camera in chunk.cameras:
path = camera.photo.path
with open(path, "rb") as file:
image = file.read()
string = str(image)
xmp_start = string.find('<x:xmpmeta')
xmp_end = string.find('</x:xmpmeta')
file.close()
if xmp_start != xmp_end:
xmpString = string[xmp_start : xmp_end + 12]
print(camera.label)
for element in elements:
try:
value = string[string.find(element) + len(element) : string.find(element) + len(element) + 10]
value = float(value.split('\"',3)[1])
print(element, value)
except IndexError:
print(element, " not found")
The external coordinate information can be loaded from the text file to the Reference pane or loaded via another script.
Thanks Alexey! The script does indeed succesfully write the ID/Long/Lat/Alt to the console. However the script seems to suggest the data is extracted from the XMP file while I thought you mentioned we should be looking at the EXIF instead, right?
It also seems to only write 6 decimals for Long/Lat whereas the Reference Pane actually includes up to 16 decimals for Long/Lat. For precision purposes a minimum of 8 decimals is required. Likewise the Altitude is only printed with 2 decimals whereas the Reference Pane includes up to 3.
At last how do we go about converting the values printed in the Console to a separate file? We basically need a single .txt/.csv file with four colums storing the exported camera-ID, Longitude, Latitude and Altitude respectively for all cameras in the chunk. This we can then put through an Excel-macro in order to transform the values to the desired coordinates.
11
General / Re: Extraction of XMP/EXIF data for editing outside Metashape
« on: January 07, 2019, 12:00:04 PM »Hello BobvdMeij,
If you want to do it directly in Metashape, then a simple Python script can be used that will save to text file the information from camera.photo.meta (extracted automatically be the application) or (with a bit more complex script) would look into the source images XMP to find the needed tag.
Do you have a list of tags that you would like to output?
Dear Alexey,
Thanks for the swift response. Regarding the required fields/tags I reckon it matters which sourcefile Metashape normally acquires the image position and altitude from. More specially whether the software extracts this from the EXIF or the XMP file.
Considering I've set my preferences to 'Load camera calibration/orientatation/accuracy from XMP meta data' I assume Metashape also acquires the Longitude/Latitude/Altitude information from the said XMP file. Or is this is an incorrect assumption and does Metashape import this information from somewhere else? If the XMP file is indeed the correct sourcefile I reckon I'm seeking the tags/fields as visualized in the screendump below.
In short I'm only after the Long/Lat/Alt data, which I then plan to transform externally outside of Metashape. I subsequently seek a way to re-import the transformed data (in Northing/Easting/Altitude format) and to replace the original Long/Lat/Alt values. All other information already imported from the XMP file (including XYZ image accuracy, Yaw, Pitch, Roll etc.) should remain intact.
12
General / Extraction of XMP/EXIF data for editing outside Metashape
« on: January 04, 2019, 10:34:50 PM »
Dear all,
We've found that the default transformation conversions implemented in Photoscan/Metashape are lacking some features and are therefore not meeting our needs. Hence we are considering conducting the transformation outside of Metashape using dedicated third party software and subsequently overwriting the original WGS84 image coordinates in Metashape by reimporting the transformated coordinates.
The transformation itself isn't expected to be an issue, but we're still seeking a straightforward method to extract the values from the desired fields stored in our Phantom 4 RTK's XMP/EXIF data. We're curious to learn what options are out there.
We've found that the default transformation conversions implemented in Photoscan/Metashape are lacking some features and are therefore not meeting our needs. Hence we are considering conducting the transformation outside of Metashape using dedicated third party software and subsequently overwriting the original WGS84 image coordinates in Metashape by reimporting the transformated coordinates.
The transformation itself isn't expected to be an issue, but we're still seeking a straightforward method to extract the values from the desired fields stored in our Phantom 4 RTK's XMP/EXIF data. We're curious to learn what options are out there.
13
General / Re: "Selected vertical datum is unavailable."
« on: January 02, 2019, 01:46:30 PM »
Following! We've been running into the same error when trying to convert WGS84 to our National Grid.
14
General / Re: 3D highlighted volume stockpiles
« on: December 08, 2018, 01:25:21 PM »
To the best of my know knowledge such visualization options are not available at this moment. But perhaps they may be shipped with Metashape, the upcoming replacement of Photoscan?
15
General / Re: Serious problem with DEM and GIS software
« on: December 03, 2018, 09:28:07 PM »The latest screenshot is again related to "Palette" raster transformation applied to the exported DEM - it contains Red, Green and Blue channels and alpha-channel with the transparency. Can you please open the DEM exported without any raster transformations applied and check the "table" view mode in the "Identify results" frame?
Is this?
That's it! Seems you've figured it out after all
