Agisoft Metashape 1.7.0 pre-release

[Alexey Pasumansky]

1.7.0 11539

I built a mesh on a project with 371 photos and only had 10 depth maps produced. I then tried a smaller project with only 10 photos and ended up with only 1 depth map.

I reran the 10 photo project using 1.6.5 just to be sure, and have 10 good depth maps. I tried 1.7.0 on medium and on high with the same result - 1 depth map.

Hello Tom,

Can you please send one of these projects (371 or 10 photos) with the alignment only (in PSZ format) to support@agisoft.com?

[Alexey Pasumansky]

version 1.7.0 build 11539.

got some inaccurate results in depthmaps generation. not sure if results from to less image overlap or something else.
Input: 57x  16bit tif files from 61mp raws. 24mm g-master lens.

Hello Exorbitart,

Is it possible to share the complete image set and related project with alignment results to support@agisoft.com?
Also have you checked if 1.6.5 results are better? Probably the surface itself has some reflections which affect the reconstruction results.

[Paulo]

I am creating a Footprint Polygon for selected cameras using following script https://github.com/agisoft-llc/metashape-scripts/blob/master/src/footprints_to_shapes.py

The polygon shows correctly in Model view but it is not closed in Ortho view (missing last segment)  see attached screen view

Update: after saving project and reopening, same footprint now appears with just 3 segments. See attached 2nd screen. It seems the script should add an extra corner to footprint vector list equal to first so as to work correctly with latest release...

New update: doing following changes to above mentioned script fixes the problem:

Code: [Select]

    def process_camera(chunk, camera):
        if camera.type != Metashape.Camera.Type.Regular or not camera.transform or not camera.selected:
            return  # skipping NA cameras and non selected

        sensor = camera.sensor
        corners = list()
        for (x, y) in [[0, 0], [sensor.width - 1, 0], [sensor.width - 1, sensor.height - 1], [0, sensor.height - 1]]:
            ray_origin = camera.unproject(Metashape.Vector([x, y, 0]))
            ray_target = camera.unproject(Metashape.Vector([x, y, 1]))
            corners.append(surface.pickPoint(ray_origin, ray_target))
            if not corners[-1]:
                corners[-1] = chunk.point_cloud.pickPoint(ray_origin, ray_target)
            if not corners[-1]:
                break
            corners[-1] = chunk.crs.project(T.mulp(corners[-1]))

        corners.append(corners[0])                            # add 5th corner equal to first
        if not all(corners):
            print("Skipping camera " + camera.label)
            return

        if len(corners) == 5:                                 # changed 4 to 5
            shape = chunk.shapes.addShape()
            shape.label = camera.label
            shape.attributes["Photo"] = camera.label
            shape.type = Metashape.Shape.Type.Polygon
            shape.group = footprints
            shape.vertices = corners
            shape.has_z = True

    with concurrent.futures.ThreadPoolExecutor(multiprocessing.cpu_count()) as executor:
        executor.map(lambda camera: process_camera(chunk, camera), chunk.cameras)
see 3rd attachment

[Alexey Pasumansky]

Hello Paul,

This seems to be due to the latest changes in internal shape representation in build 11539. Thank you for pushing the script update.

[danderson4]

Any projected release date for version 1.7?

[Alexey Pasumansky]

Hello danderson4,

I think it will be very end of December (or maybe early January). Usually major release updates are published on December 31st.

[Diego]

Hello Alexey,

Support of the new depth maps generation for the cameras with the rolling shutter compensation not available yet (build 11539), I hope it is ready before the final version, and support to correct rolling shutter in images without distortion.

Best regards,

Diego

[Exorbitart]

version 1.7.0 build 11539.

got some inaccurate results in depthmaps generation. not sure if results from to less image overlap or something else.
Input: 57x  16bit tif files from 61mp raws. 24mm g-master lens.

Hello Exorbitart,

Is it possible to share the complete image set and related project with alignment results to support@agisoft.com?
Also have you checked if 1.6.5 results are better? Probably the surface itself has some reflections which affect the reconstruction results.

Hello Alexey,
I send you some example phtos, the report and the resulting maps that represent the output model. The full project is to big to send (66GB).
Hope you can see anything that help to clarify the issues.

thanks,Benjamin

[Alexey Pasumansky]

Hello Diego,

New depth maps should work with the rolling-shutter cameras in the latest 1.7.0 pre-release (11539), which errors are you observing?

[Paulo]

In latest release. I get crashes when using Detect Powerlines. Data set: 140 eBee 16Mpix images.

First crash on aligned set with 1.4.3 version  and min_altitude 5 m;
Second crash after doing new alignment with 1.7 and min_altitude 5 m;
Third crash with min altitude set to 1m.

In each case report was sent to support...

In previous pre release I did successfully use Detect Power lines see attached ....

Update: new trial using new generated DEM as basis for altitude. It seems the original DEM had some issue causing crashes.
Now Detect Powerlines terminates without error using min_altitude of 5 m. see 2nd attachment...

Sorry for any inconvenience caused....

[Diego]

Hello Alexey,

Well, it doesn't work at all well, my proof is as follows:

A very small delimited zone with version 1.6.5 in just 15 seconds processes the dense cloud in lowest quality, what is expected for a small zone and low resolution.

2020-12-08 11:31:15 checking for missing images... done in 0.009 sec
2020-12-08 11:31:15 Finished processing in 0.009 sec (exit code 1)
2020-12-08 11:31:15 BuildDenseCloud: quality = Lowest, depth filtering = Mild, point colors = 1
2020-12-08 11:31:15 Generating depth maps...
...........
...........
2020-12-08 11:31:30 422779 points extracted in 0.837 sec
2020-12-08 11:31:30 saved dense cloud in 0.053 sec
2020-12-08 11:31:30 loaded dense cloud data in 0 sec
2020-12-08 11:31:30 dense clouds joined in 0.025 sec
2020-12-08 11:31:30 loaded camera partition in 0.001 sec
2020-12-08 11:31:30 Finished processing in 15.475 sec (exit code 1)    (Only 15.475 sec)

But in the version 1.7 build 11539 is broken, after 35 minutes says that still needs more than 3 hours to finish and does not advance, something that in the previous version took only 15 seconds, clearly does not work, the new version, has interesting changes but things that already worked well in previous versions were broken in this new version.

I hope all this can be fixed before releasing a new version

Best regards,

Diego

[Alexey Pasumansky]

Hello Diego,

Do you use GPU for the processing, which model and which driver version? And can you provide the log from 1.7.0 related to the beginning of the processing operation which includes the actual depth maps generation (if it ever starts).

[danderson4]

Thanks Alexi!
Cannot wait for the new release
Dave

[Alexey Pasumansky]

Hello Paul,

Was the DEM generated in Metashape or imported from external source?

[Paulo]

Hello Alexey,

the original DEM was generated in Metashape but it had some issue with CRS (compound CS WGS84/UTM 14 with Vert_datum CGVD 2013) as in Ortho display I could see the DEM but the corresponding underlying satellite imagery would not display. So I regenerated new DEM using ITRF08/UTM14 + ggm2010 height and now everything is OK for Detecting powerlines and display in Ortho View....