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 - mks_gis

Pages: [1] 2 3
1
General / Re: Control strip at lower altitude results in 10m shift
« on: May 21, 2024, 11:01:28 AM »

errors per dimension are shown in the ref pane when you are in errors view mode.


Well, after all these years of using MS I'd forgotten about that little button, D!ho :)

It seems there was an error in the PPK that resulted in a z error of 2m. I've reprocessed the trigger coordinates and the model is much improved.

2
General / Re: Control strip at lower altitude results in 10m shift
« on: May 20, 2024, 06:05:44 PM »

I think you have an error in your input data, 10 meters as an error is very unusual.

Dieter

Thanks for the link, that paper and the ones referenced were very interesting. I may have found an error in the PPK of the control strip triggers, although not 10m.

3
General / Control strip at lower altitude results in 10m shift
« on: May 17, 2024, 06:32:21 PM »
Hi,

I was playing around with our Mavic 3M to test some general workflows. DJI has the option to fly a set of oblique images at the end of a mission to improve accuracy, so I thought I'd check what impact this has. In addition, I thought it'd be a good idea to fly a nadir control strip at different altitude, to test what effect that has on a model. I was flying with a base and PPKd the triggers using REDToolbox. I also have GCP which I only use as check points.
The main model has 243 images at 60m AGL. There are 12 oblique images at 60m AGL and 8 images in the control strip at 50m AGL. I ran 4 models, all with the same setup, reference settings and markers:
  • Main images only
  • Main + oblique + control strip
  • Main + oblique
  • Main + control strip
I use a python script to run each model, so the process is exactly the same. (https://www.agisoft.com/forum/index.php?topic=9578.msg44253)
When I process the model with the main images and the control strip the whole DEM is shifted down by 10m, and I cannot work out why. I have set the capture distances for each image set (right-click on selected images). Why do these 8 images have such a disproportionate effect on the overall model? Am I missing any other setting to accommodate the lower flying height images? The horizontal accuracy is also a bit worse, but only 0.06 mean compared to 0.02 mean against check points. The model with main+oblique+control strip does not have this issue.
Further questions that may be interesting:
  • When you set the capture distance for individual images (right-click) is there a way of checking it has actually set it, because if it is repeated the default value is shown again?
  • When we have individual accuracy values for every image from the PPK/RTK process, do we still need to set the camera accuracy in the Reference Settings, i.e. does the per image setting override the Reference Setting value?
  • The error (m) given is an amalgamation of x/y/z, is there a way in Metashape to see the error per dimension?
  • Adding a control strip at a different altitude is sometimes mentioned here as a method to improve a model, but I cannot find an academic reference or technical article about it. If anyone knows of one please post it here.
Thanks

4
Thanks, that makes sense. However, that negates the accuracy benefits of the Sony, and flying at 300m isn't feasible without a very expensive OSC in the UK.

Manually derived GCP from the Sony is the best way forward then, if visible on the Altum.

5
General / Re: To CTL or not to CTL that is the RTK question?
« on: June 30, 2023, 03:22:47 PM »
Thanks Paulo, that makes sense. I fully agree, my curiosity stems from the webinar where Alexey and Wingtra say not to use CTL, just to use any GCP as CHK.

Although my recent, and first, PPK processing without CTL or using 4 CTL didn't make a significant difference in x/y or z. I may need to set up a proper test of this.

6
Thanks for posting. I tried that already, MS only aligned the Sony data, not the Altum, unless I got the workflow wrong in MS.

7
General / To CTL or not to CTL that is the RTK question?
« on: June 29, 2023, 06:59:34 PM »
Hi,

When processing imagery with RTK/PPK air control points, what is the best practice re GCP? I've seen a Wingtra webinar where Alexey recommends to only use check points, but an Agisoft guide on this mentions using some CTL. Other sources state that some GCP is still best practice. I'd appreciate your views on this, with regard to Metashape processing. I'm not talking about check points, they are always useful to gauge result accuracy. If CTL are used, what are the priority settings in Metashape, is that controlled through the accuracy settings, as I understand it?

With RTK/PPK Alexey also recommends using Fit additional corrections for PPK data in Optimize, specifying all General parameters, but I've found better results with Adaptive on its own. Tbh, I always use adaptive, without fully understanding when to NOT use it. A simple guide on that would be helpful.

Thanks
M

8
Hi,

Given a RTK enabled high-res system (Sony RXII on WingtraOne with PPK in this case) and a non-RTK system (MicaSense Altum on WintraOne Gen 1, hence no PPK) and given that the same area is flown, can the RTK data be used to control the non-RTK data, without manually deriving GCP from the RTK system processed data? When imaging intertidal areas creating GCP is often not possible due to mud/tides/access. In a test case I did have 6 GCP in the area, but not well spread out due to aforementioned constraints. But in future we may not be able to put out GCP.

What would the workflow be here? Can the RTK RGB and MS data be processed together, using the RTK RGB images as a 'scaffold' for the MS in a multi-camera setup?

Thanks
M


10
Hi

The script was last updated for version 1.8. There must have been changes to the Python API in the update to v2 which break the script, hence the error.
I will look at this and update the script when I have time, hopefully next week
I'll also need to check why the major version check didn't flag this as an issue.

Cheers

11
General / Re: Waving a white flag
« on: June 10, 2022, 01:20:45 PM »
Refine markers does indeed work for this workflow, white flags turn blue as an image is loaded after the initial points are manually defined, thanks.

Quote
Not sure what you mean about the names not being important, please clarify. I need to match the names to update the coordinates from the GCP file. (That's a minor issue, as you can edit the GCP csv to match the labels, i.e. "point 1".)
In the import reference dialogue there is a checkbox that "ignore labels", try it and you will understand. Metashape manages to match markers and ground points on its own (obviously it can fail if points distribution is too much regular making several matches plausible)
Also you may need to see if by enabling "refine markers" under tools menu, you get the boost you want for your workflow. (also needs some user care, that is why it is not enabled by default)
Best regards,

José Martínez
Geobit & Accupixel
Metashape traning

12
General / Re: Waving a white flag
« on: June 10, 2022, 12:55:52 PM »
Exactly what I was looking for, thanks Alexey

Hello Martin,

The following code should create marker projections (blue flags) on the images, based on the marker 3D location, which can be defined either by the reference coordinates only, or by other manually placed projections:

Code: [Select]
import Metashape
chunk = Metashape.app.document.chunk #active chunk
for marker in chunk.markers:
if not marker.position:
continue
point = marker.position
for camera in [c for c in chunk.cameras if c.transform and c.type == Metashape.Camera.Type.Regular]:
if camera in marker.projections.keys():
continue #skip existing projections              
x, y = camera.project(point)
if not(x) or not(y):
continue
if (0 <= x < camera.sensor.width) and (0 <= y < camera.sensor.height):
marker.projections[camera] = Metashape.Marker.Projection(Metashape.Vector([x,y]), False)
print("Script finished")

Is it what you are looking for?

13
General / Re: Waving a white flag
« on: June 09, 2022, 12:41:49 PM »
Thanks for the response

To clarify, green marker=user placed, blue marker=system placed, both used in processing, white marker=system placed but not used in processing, that's understood. I also understand I need to check all blue flags, as mentioned in the OP.

Correct me if I'm wrong, Add Marker adds a marker and works out the projections on the other images, Place marker adds it in 2D on that image only.

Not sure what you mean about the names not being important, please clarify. I need to match the names to update the coordinates from the GCP file. (That's a minor issue, as you can edit the GCP csv to match the labels, i.e. "point 1".)

At the moment you have two workflows as I see it, and my question is if they can be merged, as both are cumbersome in their own way.

WF1 - using add markers: Add marker by right clicking on each marker once, move a few blue flags, check the others and leave them if good enough. Then load GCP file with matching names to update the coordinates of the markers to the GCP. Issues are that you need to find each GCP, not always easy on e.g. glacial rubble.

WF2 - using a GCP file: Load GCP file, some white flags pop up, if you fix about 4 in place and Update Transform all other GCP are roughly located, which is better in terms of finding them. After manually updating a couple of markers each the others show up in the right place, but need to be clicked on to turn green. With several markers on several images each that's a lot of clicking.

So my question is, can you use the gcp workflow and get blue flags, best of both worlds.

This is not a big issue, but I'm trying to find the most efficient way of marking GCP, just tired of clicking markers, either way.



14
General / Waving a white flag
« on: June 08, 2022, 05:52:10 PM »
Hi,

 When adding markers, if a markers are placed you get an automatically aligned blue flag on the other images it appears on. They still need to be checked, but are often ok, making the process less manually intensive.

 When loading a GCP file and placing a marker the flags never turn blue, they are white, and not used in processing. You need to click on every white flag to turn it green. Now, you can add points, rename them to match your markers, and then load the coordinates later, but that's cumbersome. Is there a way to turn the white flags blue, mirroring the add points workflow? I ask this before I spend time coding some python to turn flags green.

Cheers
M.

15
TBH, I can't remember why it is False. This script develops as and when I need it, SfM is only a small part of what I do. I'll look into it when I next edit it, but you seem to have the skill to develop it further for your needs.

Pages: [1] 2 3