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

Pages: [1]
1
General / Re: P4RTK OPTIMIZE CAMERA ALIGNMENT
« on: September 23, 2021, 12:31:14 AM »
MaciekK I also have the ability to switch to the p1 and m300. But have wondered to what big benefit. For a few bucks I can deploy P4RTK to a survey crew who uses it for a couple years before it wears out. And get one pixel or less precision fairly easily. I so far am not sure what extra value will be gained by deploying to them a setup (P1) that costs 5 times as much. if it is not going to produce better results anyways.

But it very well might be time to move on to better equipment and cameras. Are you finding it to be worth it for the better equipment? You probably use it yourself. I dont, I train crews and send them out and they only do photo missions as one of many things. I am thinking maybe just keep one or two p1 around for when I need the best possible results. I dont know. if they make a mistake it cost way more with P1. ha ha.

Rest of you ... I am still looking for some feed back to original post!

2
General / Re: P4RTK OPTIMIZE CAMERA ALIGNMENT
« on: September 23, 2021, 12:25:34 AM »
MaciekK are you saying you do not select k4, and even ONLY select k2? Obviously we are talking about each dataset computing distortion coefficients per mission and not holding to a predetermined calibration (as we all know the environmental conditions are changing the answer too much.)

I just want to confirm you are NOT talking about holding a fixed value for each mission, but rather only solving for k2 uniquely each mission. Is that right?

by the way when a person is getting sub pixel precisions it can get tricky to know if any setting tweaks even matter at that point.

Thank you for your reply.

3
General / P4RTK OPTIMIZE CAMERA ALIGNMENT
« 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.

4
General / Re: Issue reading PPK updated exif coordinate information
« on: November 21, 2020, 06:19:43 AM »
ever resolve this? I seem to have the same or similar problem. I re-write the exif position info and metashape is not reading that?

5
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?

Thanks

6
Bug Reports / Re: cloud processing OPENSSL will not install
« on: October 30, 2020, 03:32:51 AM »
ok I will answer my own post. I used Alexey's reply to another post:


"Please try to download OpenSSL Binaries Win-64 v1.0.2u binaries from the following page:
http://wiki.overbyte.eu/wiki/index.php/ICS_Download#Download_OpenSSL_Binaries_.28required_for_SSL-enabled_components.29

Unpack the archive and put its contents to Metashape Pro installation directory, then re-start the application."

so i don't know if it truly has to be version 1.0.2   but just used that since it was there. And the trick it to copy the contents to the install directory - just as he says. For windows that was at /programs/Agisoft/metashape

i did not need to reboot. but only re open the metashape app. And then it seems to be working now.


7
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:
https://agisoft.freshdesk.com/support/solutions/articles/31000155067-how-to-process-a-project-on-the-cloud

I go to the SSL link. I then go to the first web link:
https://slproweb.com/products/Win32OpenSSL.html

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.

8
General / Re: Issues with Phantom 4 RTK proccessing
« on: September 16, 2020, 02:38:47 AM »
just a suggestion. maybe just leave everything is wgs84. And any markers be in same, and use ellipsoid heights and not ortho heights. Then you don't need to bother with any geoid.

Then bring that data (whatever you use from metashape - ortho-mosaic, or point cloud, or dem, whatever) into Global Mapper. Then in Globla Mapper change the projection to whatever you want. The vertical will still be ellipsoid. You can then load the geoid in as a surface. And combine your surface with it, surface plus surface and you will get the geoid adjusted elevations.

no reason to insist on specific coordinate systems in metashape - most of the time - in my opinion.

9
General / Re: Adding markers from excel or csv
« on: September 16, 2020, 02:32:59 AM »
You also can import markers from a .csv file. it is very easy to do. I do it sometimes.

10
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.)

11
General / Re: Work Flow for GCP
« on: October 13, 2018, 04:15:38 AM »
SAV


Just commenting in regard to the 'air control'. We have done the same test you suggested to simulate having rkt or ppk positions. And got the same results you mention. So now we are in the process of sorting out how to get PPK on our drones. I know this is already figured out - but there is not yet some good 'how to' out there.

Main reason for this reply is to add our experience as evidence. We ran raw imagery with proved up positions (by imputing it back into the images after a GCP process.) We used EXIF TOOL for anyone interested. Anyhow it worked as expected. The whole point is what happens when you feed in more precise photo positions. Well you really do seem to get equivalent precise results. So then ground control is really more of a check and not part of the process. Which will be better, of course.

So on to air control. Once I sort out how to do it I will post a video or a write up. There just does not yet seem to be one out there. Even though a lot of products are set up to use this method.

12
General / Re: Work Flow for GCP
« on: October 13, 2017, 03:52:58 AM »
are you saying you used GCP to get image positions good to cm. Then you backwards saved those image locations back into the images, I suppose as exif. As a kind of cheat way to simulate having cm quality image positions from air?

Then saved them, then started new project, loaded them in and they have 'air' reference positions. Then ran workflow with no GCP, and got almost same answer?

Is that what you are saying? If so then answers my question, and basically means I don't quite get how it worked out. (in photoscan.) I don't understand HOW it uses the air positions. he manual says it only uses the images to estimate parameters. So I am puzzled.

I know rtk,ppk, stuff exists. I don't know if it is being fed into photoscan and resulting in cm level results. I assumed they had to use some specific software - that cam with the units. Like Topcon or Leica or something. ??


13
General / Re: Work Flow for GCP
« on: October 12, 2017, 07:00:08 PM »
Very grateful SAV. Thank you. If air control is used, very high accuracy, will it get as good of results? I am having a hard time pinning that down. Since I think the algorithm will only use the images to estimate the parameters. Well it uses the air position, but seems only to use that to speed up processing by excluding looking for pairs where there is no image overlap.

I mean even if you said your reference positions are accurate to 1mm. Wouldn't the algorithm shrug that off and find the key points it believes exists, wherever it actually does - and end up getting an image position of its own. And therefore show that as 'error' in the top panel (images with reference).

I realize there is no such thing as 1mm accurate air control. I am asking this to see if investment should be made in super good air control (which is expensive and not simple), versus just plugging in GCP instead and accept typical crappy air positions. I already know that GCP woks fine. I do get some data that has pretty good air control ... but I am skeptical that in the end it really gets applied.

Anyhow ... very grateful for your reply. I didn't think there could be a very good reason to run Align Photos a second time ... seemed you would just be running all the optimizations afterwards anyhow.

14
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?

geomaticist

Pages: [1]