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.

Topics - geomaticist

Pages: [1]
« on: September 22, 2021, 09:45:33 PM »
I am trying to pin down a best practice or some good answers to a question about 'consumer grade camera' and the phantom 4 rtk camera in typical aerial mapping and processing in metashape. First of all, is the P4RTK camera considered consumer grade? I would assume it is.

Second question is about what camera calibration coefficients are appropriate to model. f, k1, k2, k3, cx cy, p1, p2 of course are.

Guides such as the USGS 2020 paper say b1, b2, and k4 are no appropriate to model for most consumer grade cameras. So .. what about the P4RTK one?

obviously you can just model it anyways. The real issue is does it make any noticeable difference to compute k4, b1, b2 on this camera? Will it just always get an unstable solution and will that adversely affect final product precisions? Does anyone actually know or have checked.

In context i am typically ppk processing P4RTk gnss positions with Trimble Business Center. I just use a script to insert events into the rinex file. Then I take the positions and adjust each by the yaw,pitch, roll and offsets to camera (which for P4RTK is very easy since it is in the .mrk file anyways and when I hand compute I get same answer.) So I then load those vey good positions into the Metashape.

Works great. There is nothing more I can do there. The rest is in fine tuning the process in Metashape. Which I have down pretty well. But the one thing I cannot get a good answer on is if k4, b1, and b2 should even be included in the optimization.  And is it only theory or has anyone really seen a difference skipping them or adding them in anyways. i notice the values for k4, b1, b2 vary a lot between different missions using the same drone. but the other values tend to be somewhat similar (the adjusted values) So I am suspicious that computing skew and k4 is FAKE.


Ok I might as well ask couple other questions.

Anyone doing a slight offset from full nadir, like 95? Just wondering if that is still a thing. I have not heard of it in a couple years now.

Finally, how many of you are consistently able to get sub pixel final precisions (except for tiny pixels of course, how would you even know.) Please dont claim this unless you KNOW for sure. By checking gcp outside of metashape.

I am successfully getting sub pixel final precisions both in horiztonal and vertical when flying at 400ft down to 200ft. And only use ppk corrected 'camera' reference positions and NO INPUT GROUND CONTROL during processing. However ... keep in mind I will adjust bias out after the products leave metashape. I am a land surveyor and can get high quality control points.

Hopefully some of the knowledgeable users will reply.

If this was already answered in depth I apologize as I could not find it.

Bug Reports / EXIF reads incorrectly
« on: November 21, 2020, 06:17:21 AM »
I have drone images from p4rtk (where I did rtk). When I load those images into metashape they seem to read the reference positions correctly. But when I run ppk on the images, and then write the ppk position result to the exif of the images (a new image file.) And I can check that value with exiftool or in windows by properites / details and they both agree and match and match the ppk value I wanted. But when I load that new image file, the ppk one, metashape does not seem to read it correctly. The longitude field is still showing the old RTK value. For understanding this … assume I used an rtk base like 2 meters different than a ppk base value. The two images would have different reference positions, and they do. Exif tool sees the new position and so does windows. But metashape reads it wrong.

Maybe … there are two different places to pull gps from in an image? And I am only overwriting the exif. And metashape is reading it from a different field?

Anyhow something seems wrong. I tried to upload the two images, with different exif values, but that metashape does not read the difference and instead sees them both as same. byt the way the elevation field does change. Just not the longitude.

Maybe this is a bug or maybe my images are not written correctly? but if not, then why do I see the new ppk position in the image when I look with windows?


Bug Reports / cloud processing OPENSSL will not install
« on: October 30, 2020, 02:16:38 AM »
I have been trying to get the cloud processing to work. I have a login there.

'openSSL library not found. Please install OpenSSl 1.0.2 or 1.0.1 for cloud processing.'

using instructions at:

I go to the SSL link. I then go to the first web link:

then I have tried to run; Win64 OpenSSL v1.1.1h Light

then tried metashape. I get the error above. I also reboot and get same error. I tried to also install the 32bit (full, not light), and so on.

I am running metashape 1.6.2    on a windows x64 machine.

is there some specific way it needs to be installed? or can it dump the info in the windows folder. Also … is it ok I am trying to install openssl 1.1.1 instead of 1.02?   

We could use a bit more help on where to get version 1.0.2, and also where to install it at.

I really want to try to cloud processing out.

thank you.

General / RTK and PPK with P4RTK for mapping
« on: September 16, 2020, 12:26:14 AM »
greetings. I am a land surveyor and use a P4RTK to do typical mapping. It is to map and survey 2D generally and not modeling 3D building etc. I use Agisoft to process the images into the ortho-mosaic. Been doing this for about 3 to 4 years. This year we finally got the ability to use RTK and PPK. And yes it works great.

The point of this post is that for some reason I will see a RTK and/or PPK dataset of images for a mission result in a miss of photo control on the ground. I always have a few photo control points. First time this happens I was puzzled and ended up just shifting final ortho to a photo control point. So eventually I made a local drone research area on the edge of town. I am in Fairbanks Alaska. I have very accurate and precise survey control I set there and triple checked to make sure no blunders. And I have around 20 photo identifiable points on the ground surveyed in. I originally intended to collect drone data to study various ways to process it in Metashape to try to better understand it all. but first flight mission, that captures the whole area (only 195 images), at about 380ft or 115meters above ground, when i processed it in Metashape the ortho-mosaic misses the photo control. i will just use metric units. I processed the RTK corrected images. And I also PPK corrected the images as well and processed those separately. now it is worth noting the coordinate for reference positions for the cameras was basically exactly the same (because of how many digits it shows.) During RTK about 10 images were during a RTK drop. That is reflecting when I load in the images, a few show 'accuracy' of about 1.5 meter. Where the rest are in and around 1-2 cm. However the PPK all came in as 0.5cm or better (on the accuracy column). point here is that the reference positions are the same for same image, except a few where the PPK worked on an image where the RTK had dropped. Other than that, the PPK supposedly is might tighter precision. I realize it is not in real life.

Processing in a typical manner the RTK - the ortho missed the photo control by an average of 15.2cm. but after shifting the image, zeroing out the average move, the standard deviation is 2cm. Since the ground sample size of the ortho is 3cm, this is a very good fit (after shifting the ortho.) processing the PPK images resulted in an average move of 23.4cm. But after moving the ortho it has a standard deviation of 1.5cm. Again very good, but it required being moved.

Right after i collected two more flights of a smaller area (to make processing faster.) And had 45 images. Anyhow the point is the RTK images land right on top of the photo control. And flight after I did with RTK off, and then PPK them and the result lands right on top of the photo control. And the resulting precisions were both 2-3cm.

So the real point of this post is that most of the time when I do RTK or PPK the results land accurately on the photo control with the expected precisions. however, sometime, and I cannot at all explain why, some drone data will not land on photo control and I will have to shift it.

Anyone have any idea why this happens? you can assume I know how to measure and do control. And that I know what base coordinate is being used to send RTK corrections the drone, and so the RTK corrected images are what I expect. And that I know how to PPK correct the images as well. It just is not making any sense to me when sometimes the processed data will land on the photo control.

I am NOT using any control markers in metashape - yes I know how to. I should not need to I would think. The images loaded already have reference positions corrected and have 'accuracies' as well.

Am I doing something wrong? if the rtk or PPK corrections are muddled some how and the reference positions are off - how in heck are they all still very precise?

Anyone experience the same thing or know anything about this?

Thanks. (keep in mind most of the time there is NO shift, the final ortho is centered over photo control. so I am really not sure how it happens sometimes.)

General / Work Flow for GCP
« on: October 12, 2017, 05:08:20 AM »
I am trying to figure out a best practice work flow.  My goal is to make ortho-mosiacs that are as accurate as possible with the given data I have. I can get as accurate GCP I want since I am a land surveyor.

Normally I would run Load photos, they will have exif data. I then run convert locations to some projection. Then Align Photo. Using the appropriate settings. Then I bring in GCP as markers.

At this point I am unsure the best way to proceed.

Some say to then uncheck the image references. Only check the markers. Then to go run the Align Photos again, this time with only the GCP. OK. If so obviously the first time you run Align would be with low settings, then add markers, then run it with high settings. But ...

Why bother? I am confused by that. Shouldn't I just move on to another step. Like edit the sparse cloud by gradual selections. Then go do the Camera Optimization? Seems this is actually applying the GCP added as markers and taking advantage of the sparse cloud being edited of outliers.

Why do some people go back and run Align Photos again instead?

Also ... the photoscan manual is confusing. It refers to 'Align Photos', "Camera Optimization', and 'photo alignment optimization'. Are those three different things, or same thing with minor tweaks, or what?

Finally, I am wondering about something else. If you have super accurate exif (GPS) because you find some way to post process your positions. Lets say you can get it to 1mm accurate. just for argument. It seems to me that still the sparse cloud will not be as precise as that - because the 'actual internal and external camera orientation parameters being estimated are from the IMAGE DATA ALONE'. I assume that all air control can do is speed up processing as the images are know not need to look for matches in some of the other images.

Reason I ask if that I assume you can get some precision in the tie points based on how well you optimize. But that the higher accurate exif positions will only contribute up to a point, or maybe not much at all 'image data alone ...'.

So if you introduce markers, that are GCP, then you will only improve the precision. And that is the only way? 

I am thinking that the precision of the tie points, in this example, will not be 1mm. And be some unknown amount. And you cannot know what that is until you add in some markers. Then ... the markers had better be more accurate than the unknown accurate tie points ...

Hopefully someone out there can understand this. I am trying to get as tight a set of dense cloud points and ortho-mosiac as possible. With the best workflow. The photoscan manual seems to know really get into this. I have the ability to get as accurate GCP to use as markers as physicaly possible. I know how to do positional accuracy. What is the best work flow, and where can I read advanced info on using GCP or using accurate air control?


Pages: [1]