Creating and Managing Multiple Chunks

[Alexey Pasumansky]

Hello lfsantosgeo,

That might be the reason of the problem. As a workaround, you can import the XML to the 1.3.x version project, then open it in the version 1.4 and export XML in new format.

[Alexey Pasumansky]

And as for the previous comments on the reprojection error calculation, are you still observing the difference between GUI output and script?

[LFSantosgeo]

That might be the reason of the problem. As a workaround, you can import the XML to the 1.3.x version project, then open it in the version 1.4 and export XML in new format.

As always, thank you for the reply Alexey!
I've opened a saved project in 1.3x on the 1.4 version and exported markers through the File > Export > Export Markers...

And then I tested it on a new project: added photos, converted to markers coordinate system and then went to import File > Import > Import Markers...
It opened all of the markers! Great! But there are some problems... The error (m), error (pix) and projections are quite different from what's is shown in the previous version of PS (1.3.x). Look at the attached image!


 

[Alexey Pasumansky]

Hello lfsantosgeo,

The number in the Projections column in the Reference pane shows the number of projections on the aligned photos. According to the screenshot is seems that all nine photos are not aligned.

[LFSantosgeo]

The number in the Projections column in the Reference pane shows the number of projections on the aligned photos. According to the screenshot is seems that all nine photos are not aligned.

Alexey,

On the last screenshot, from my last post, I filtered the photos on Photos Pane to show only the ones related to the marker #113 (Filter photos by selection...). So in the Photos Pane it shows 9 photos aligned with its valid and pinned markers and projections from marker #113.

But in the Reference Pane the number of projections for marker #113 is 0 (despite having in the photos pane the 9 aligned with its projections). This happens not only for #113 but also for the rest of the markers.

This was aligned with 10,000 keypoints / 4,000 tie-point limite / lowest (just to go fast and see if the markers were correctly imported).


To be clear about it... I added another 2 screenshots comparing the project made with 1.3.2 and a new one:
1. the first shows the project that was saved on 1.3.2 which opened normally on 1.4. With the reference pane showing the errors, projections etc as it was saved last time. That was aligned with Highest / 80,000 keypoints / 8,000 tie-points.

2. the second shows a new project created, with the same photos, same steps (add chunk, add photos, convert coordinates, align photos, add markers -- exported from the opened 1.3.2 project). The alignment with HIghest / 40,000 / 4,000. The screenshot shows the difference in errors.

Considering that in the 1.3.2 PS version in different projects, with different alignment parameters when importing the markes XML all the results were the same! Always with the values of the 1. first screenshot.

Questions:
A) Are the differences caused by different alignment parameters?
B) Or are they caused by the XML format from 1.3.2 to 1.4.0?
C) Or are the differences caused by different PS versions?
D) Am I missing something?

Looking forward for the reply!

[Alexey Pasumansky]

Hello lfsantosgeo,

In this post - http://www.agisoft.com/forum/index.php?topic=8124.msg39960#msg39960 -  neither of the images containing the marker is aligned. But in your latest post I see that on both screenshots there are 9 projections for the marker, since all the corresponding images are aligned.

As for the difference in the errors, I think that the following situation is being observed:
- the images were aligned and optimized in the version 1.3.2, then marker projections have been exported to XML,
- when you import the XML back to the new project aligned with the different parameters - you load only the projections of the markers, not their 3D positions. The position of the marker in 3D is defined by it's projections on the images.
Also I see that in the second case the georeferencing is performed both on the cameras and markers, but it seems to give considerably smaller impact (due to the difference in the accuracy for cameras and markers) then the different alignment results.

[LFSantosgeo]

In this post - http://www.agisoft.com/forum/index.php?topic=8124.msg39960#msg39960 -  neither of the images containing the marker is aligned.

That's true! Just realized it now! Thanks for pointing it out.

But in your latest post I see that on both screenshots there are 9 projections for the marker, since all the corresponding images are aligned.

Cameras are aligned due to higher alignment parameters! That's why the projections are shown on the Reference Pane.

As for the difference in the errors, I think that the following situation is being observed:
- the images were aligned and optimized in the version 1.3.2, then marker projections have been exported to XML,

That's what I've done... Aligned (with a default set of parameters+ highest) and optimized

- when you import the XML back to the new project aligned with the different parameters - you load only the projections of the markers, not their 3D positions. The position of the marker in 3D is defined by it's projections on the images.

I did a step further. Maybe this is what I was missing... I optimized the cameras and the errors diminished significantly! Total error for all markes came down to 0.03m according to expectations. Nonetheless not exactly like it was before due to different alignment parameters set (?) even with the cameras unchecked.

Also I see that in the second case the georeferencing is performed both on the cameras and markers, but it seems to give considerably smaller impact (due to the difference in the accuracy for cameras and markers) then the different alignment results.

I know about the difference in accuracy for cameras and markers. I only highlighted on the second screenshot because it was, for both of cameras and markers, different from the first screenshot. Even the cameras errors were different from the original project.

I guess I was indeed missing a step after all. The optimize after uncheck the cameras and importing the markers.

By the way, talking about optimizing. I have this data set made with Phantom 4 that I'm aware that it has a rolling shutter effect becaused it has an electronic shutter. I was reading here (http://www.agisoft.com/forum/index.php?topic=7653.msg37151#msg37151) that it might have a huge effect. I wonder how to activate it through Python coding?

Code: [Select]

    chunk.optimizeCameras(fit_f=True, fit_cx=True, fit_cy=True,
                                                         fit_b1=True, fit_b2=True, fit_k1=True,
                                                         fit_k2=True, fit_k3=True, fit_k4=False,
                                                         fit_p1=True, fit_p2=True, fit_p3=False,
                                                         fit_p4=False)

I saw in the 1.4.0 API:

Sensor.rolling_shutter
Enable rolling shutter compensation.

[Alexey Pasumansky]

Hello Luiz,

When you are optimizing the alignment - the relative positions of the cameras are changed, so the same projections of the markers would result in different 3D point for the marker (estimated location), so the error value (source - estimated) would be also different.


In the version 1.4 you can enable the rolling shutter compensation before the optimization:

Code: [Select]

sensor.rolling_shutter = Truethen it will be estimated automatically during the optimization. In principle, the rolling shutter property can be modified before the initial alignment, then it will be taken into account during that stage.

[LFSantosgeo]

When you are optimizing the alignment - the relative positions of the cameras are changed, so the same projections of the markers would result in different 3D point for the marker (estimated location), so the error value (source - estimated) would be also different.

Ok! That justifies the marker's errors difference between the original and the new project.
Then would you recommend to import the markers anyway thus optimize or to start from ground zero and place them again hoping to achieve equivalent total error?

In the version 1.4 you can enable the rolling shutter compensation before the optimization:

Code: [Select]

sensor.rolling_shutter = Truethen it will be estimated automatically during the optimization. In principle, the rolling shutter property can be modified before the initial alignment, then it will be taken into account during that stage.

[LFSantosgeo]

Putting it to use... Before the alignment process.

Code: [Select]

    # enabling rolling shutter compensation
    try:
        for sensor in chunk.sensors:
            rolling_shutter = True
    except Exception as e:
        print("Error:", e)
        raise

    print("Rolling shutter compensation done!")


[LFSantosgeo]

And as for the previous comments on the reprojection error calculation, are you still observing the difference between GUI output and script?

Hello, Alexey;

I'm still observing differences between GUI and script.
Also when running the script several times I get different tie-points for the same group of photos and parameters.

See the attached image! I also attached the python code... Now when running it in PS the user view after running it shows the cameras completely messed up (as a globe).

[LFSantosgeo]

Just figure it out:

Code: [Select]

    # configuring the coodinate system for the project
    try:
        n_crs = PS.app.getCoordinateSystem("Select GCP Coordinate System...")
        print("GCP Coordinate System:\n{}".format(n_crs))
    except Exception:
        print("Error: unable to define GCP coordinate system")
        raise

    crs = chunk.crs  # chunk current coordinate system
    chunk = doc.chunk  # defining where the transform will happen


    # convert coordinate system for loaded images (cameras)
    for camera in chunk.cameras:
        csys = PS.CoordinateSystem
        camera.reference.location = csys.transform(camera.reference.location,
                                                   chunk.crs, n_crs)

    # convert coordinate system for chunk
    doc.chunk.crs = n_crs

    print("OLD COORDINATE SYSTEM:\n{}.".format(crs))
    print("\nNEW COORDINATE SYSTEM:\n{}\n".format(n_crs))

EDIT: code to fix the reference problem from previous post