Messages

1

Feature Requests / Re: Please add Stubs for the Python standalone module

« on: March 11, 2024, 05:03:36 PM »

Hi Alexey

I'm sorry for replying so late, I only just got the time to update to 2.1 .
The stubs work nicely and developing is much nicer this way.

Thank you very much for implementing this so quickly.

best regards

Beda

2

Python and Java API / Re: Impact of workitem_size_cameras, workitem_size_pairs, max_workgroup_size

« on: March 11, 2024, 04:52:36 PM »

Did you find differences when adjusting these?

In my very limited testing it didn't seem to really make a difference.

3

Feature Requests / Re: Please add Stubs for the Python standalone module

« on: November 27, 2023, 04:20:30 PM »

Maybe take a look at mypy stubgen for an open source tool that should have similar functionality and will be easier to integrate into a pipeline.

4

Feature Requests / Re: Please add Stubs for the Python standalone module

« on: November 27, 2023, 03:30:53 PM »

Thank you for the answer

I tried your suggestion in 2.03 and while it now shows me the Metashape datatypes like Metashape.Chunk I get the same issue as you on all variables that have been returned by a function (because the return datatype defaults to "any").

I guess I have to wait for stable release of 2.1

Seeing as those autogenerated stubs seem to work at least partially, maybe you could think about including them in the module in the future?
Copying them back and forth between Editors surely is not the best solution.

5

Feature Requests / Please add Stubs for the Python standalone module

« on: November 24, 2023, 04:52:03 PM »

Without stubs, there are is no autocomplete, type hinting etc. in Editors that can't scan the .so files themselves (like VSCode with pylance for example.)

I understand that it kind of works in PyCharm (also not very well to be honest) but not everybody is free to switch editor as they want to.

By adding stubs you could vastly improve the quality of life for developers using your python module.

6

General / Re: Recommendations for drone mission planning and deployment app?

« on: November 13, 2023, 06:40:02 PM »

No I have never heard about using litchi but as far as i know it is a powerful tool that can do many different things. In my mind it was more about doing photo/video montages but maybe that's wrong.

Alternatively you can also try dronedeploy, you can use their missionplanner without the photogrammetry and as far as I remember it's free as well.

7

Python and Java API / Re: extract image/pixel coordinates for every point of the sparse cloud

« on: November 13, 2023, 12:12:27 PM »

they did some breaking name changes in version 2.0:

Code: [Select]

...
• Renamed Chunk.point_cloud attribute to tie_points
• Renamed Chunk.dense_cloud attribute to point_cloud
...
So now you try to access the dense cloud which probably doesn't exist in your project (hence the NoneType) and which doesn't give you access to it's points anyway.

You will have to replace point_cloud with tie_points and maybe some other things as well.

8

General / Re: Recommendations for drone mission planning and deployment app?

« on: November 13, 2023, 12:01:08 PM »

You mention updating to a mavic: make sure you buy the mavic 3 enterprise as that is the only current mavic drone that is suited for photogrammetry.
It Includes the DJI pilot missionplanner which honestly is all you ever need. Especially the new "smart oblique" missions it supports are really awesome!

For the Phantom 4 pro I have had good luck with drone harmony which also should be free for that drone.

9

Python and Java API / Impact of workitem_size_cameras, workitem_size_pairs, max_workgroup_size

« on: October 26, 2023, 03:56:32 PM »

Does somebody know the impact of the variables
workitem_size_cameras
workitem_size_pairs
max_workgroup_size

which are used in many functions of the python api?

Trough trial and error I have found out that workitem_size_cameras impacts how many images are processed in a package on the gpu. Afterwards it does initialize the gpu again "Found 1 GPUs in 0.000307 sec (CUDA: 0.000187 sec, OpenCL: 0.000107 sec)".

Now the interesting thing for me is that the defaults in the GUI don't seem to correspond to the defaults in the python module.
If I process a project in the gui, it extracts keypoints from all pictures in one go while in the python module it does it in sets of 20.

now my question is: How should these variables be used? does the GUI calculate ideal values based on the available hardware?

10

General / Re: Discrepancy between GNSS-measured GCPs and Drohne DJI Mavic E3 RTK

« on: October 23, 2023, 01:09:11 PM »

They are talking about a setup with a mobile RTK base with unknown absolute location.
If you used the same network RTK for corrections this does not affect you at all.

From what you described, the measurements should be indeed correct but as they don't align, something must have gone wrong somewhere.

11

General / Re: Discrepancy between GNSS-measured GCPs and Drohne DJI Mavic E3 RTK

« on: October 23, 2023, 12:18:01 PM »

So if I read it correctly you didn't actually "verify" the accuracy of anything, you just trust the values given by the manufacturer.

Those are usually best case scenarios and the values in the exif data are often a bit overoptimistic.
(also for the drone the spec is "Horizontal: 1 cm + 1 ppm; Vertical: 1.5 cm + 1 ppm", if you use a network RTK correction and are over 10km away from the nearest station, the ppm error will actually become dominant).


The same is true for the GPS Rover and that one is very sensible to user error (you need to keep the pole exactly straight, it's really easy to add 1-2cm of error by not leveling the pole correctly).

If you get a offset of 40cm though that would seem a bit too much, especially if it is consistent over multiple ground control points. Can you check what direction the error occurs in? If it is in z-direction, my guess would be that you got the pole offset of the GPS rover wrong.
I assume that you use the same height reference as well?
The drone uses above ellipsoid normally, if the rover is set to above geoid, that could also lead to a static height offset.

12

General / Re: Discrepancy between GNSS-measured GCPs and Drohne DJI Mavic E3 RTK

« on: October 23, 2023, 11:13:23 AM »

What was the RTK reference? Was it the same for both devices and did you do it at the same time?

How did you verify the 2cm accuracy? (In my experiments the Mavic3 Enterprise was more like 10cm accurate)

If you say accuracy do you mean relative or absolute accuracy?

13

Python and Java API / Re: Running Metashape within Docker using python wrapper finishes with segfault

« on: October 20, 2023, 03:06:50 PM »

Sadly I cannot really do potentially system breaking changes on our computation server.

However I get the same Issue on my personal laptop which is on an older Ubuntu version (20.04lts vs 22.04lts on the  server) if i connect over ssh.
I also tried an older Nvidia driver (tried 525 and 535 on the laptop, 535 on the server) but it didn't change anything.

As it does not seem to be device specific, the bug should hopefully be reproducible.

14

Python and Java API / Re: Running Metashape on a headless VM means no multithreading

« on: October 20, 2023, 01:26:03 PM »

If you are aiming at a completly headless setup why are you not using the standalone python module? https://agisoft.freshdesk.com/support/solutions/articles/31000154762-how-to-make-python-interpreter-to-use-metashape-module

I have no Issues with multithreading there.

15

Python and Java API / Re: Running Metashape within Docker using python wrapper finishes with segfault

« on: October 20, 2023, 01:01:20 PM »

I assume you mean vulkaninfo from the package vulkan-tools?

No it doesn't produce the segfault but it detects that DISPLAY is not set and skips a part.
"'DISPLAY' environment variable not set... skipping surface info"
I attached the output i get

I also have a support ticket open concerning the issue (#191429) but wanted to post here as well for other people that are running into the same Issue.