Support Website Contact Support Blog

Vertical Shift between Flight Blocks

Good day all

I have reported this issue to Pix4D team before and it seems been with the latest software version it has not been resolved.

When completing mapping over a large area say, multiple flights are inevitable usually. I covered about mapping last week with multiple flights. One area was reflown twice to address images that were taken while the drone was flying inside clouds, to these frames with clouds were to be remove and replaced with those taken on repeated flight when the clouds were gone. So, all the data were rapidly processed each flight separately before ultimately merging them. But it appears that each flight block is reconstructed at its own height. As a result data is shifted vertical up or down between blocks as shown in the section below. In plan it all looks OK. I was trying to attached quality report here it seems not possible.



Point clouds in plan view is OK



Could you share quality report?

Hi Jaakko


It seems impossible to attached PDf files here. So I have loaded it up into drobox link below.


Hi Clarence


It seems that you didn’t use mtp’s when combining projects. You should add Manual Tie Points in the intersection / common area between the subprojects. And another thing you could try is to merge the projects together one by one. If you have flights A, B and C. Merge A and B first if it turns out ok then merge C and so on.

Thanks Jaakko

I recall having told support staff as well, that MTPs not the best thing to do when processing a project of this scale or larger and when there are not so many features of easy reference such as buildings etc. Additionally, if I were to follow the merging one after another, it would make processing many folds slower, because problem with vertical offset can only be checked after step 2 is completed. What makes me fail to understand is that Pix4D is nearly 3 times more expensive than AgiSoft, but agisoft among others seems to handle this issue very well.


Thanks for you time to look into my issue. 



Hi again. 

I have also done few large scale projects with the same issue. I combined flights one by one:

  1. added manual tie point to 2 projects to be merged with same name.

  2. combined the projects. Reoptimized and generated quality report where I checked if 1 block was created. If 2 or even more then there was some kind of shift in the project. 

  3. Combined flight 3 to previous project and so one.

Just generate the quality report after merge and verify that only one block is created. No need to process step 2 to see that shift.


This if from your project and as you can see 4 block were created so you can be pretty sure that there is some kind of shift:


Hi Jaakko


Thanks for your additional comment, let me try that.

I appreciate.



Quick question.


Are the MTP supposed to be from exactly same feature in each project?

That is, MTP1 in project A should be of same feature as MTP1 in Project B and so on for the all the MTPs?


Yep and remember to name them exactly same way. For an example same stone on the ground that is visible in project A and B name it same way in both projects (e.g pp1 ). Mark at least 3 manual tie point in intersection / common area between each subproject. The more the better. 

EDIT: And remember to reoptimize the project after marking those manual tie point. After reoptimization you can combine them. This is important!


Yeah, I was going to re-optimize. Geese looking for common objects, in different projects, is what makes it such a slow process. let me give it go and see.


Hi Clarence,

Jaakko is right, adding MTP’s in the common area is crucial for merging. The merging procedure will be the following:

  • Before starting processing each subproject individually make sure you have a common area between two of them.

  • create a project for each subproject individually;

  • run just step 1 of processing for each project;

  • add common MTP’s in the subprojects before merging and mark them (see scheme below).


  • reoptimize each project; like this, the MTP’s are taking into consideration;

  • after step 1 has been completed merge the two projects as per instructions that are given: here

Could you please make sure that you are following the workflow given above?




Hi Ina


I understand these steps, but the problem is as I have always said, it works easier if the mapping was done in urban environment where it is easy to pick building or other features. But when mapping on an open land it is really hard to find features that can be used as common reference along the common area between blocks. What I think is a better alternative is to have all the images first georeferenced and process them all in a single project. This merging thing is just a nightmare. I spent 3 hours on Sunday trying to find matching features and it just dis not work. This approach is surely not suitable for the kind of mapping I do, and very frustrating.



Finally I found a solution to this. 

If anyone else has been suffering just as I have been.

Here is what I did.

I used .LOG file from pixhawk for geotagging (3DRobotics), so I have to create the sub-projects anyway and use each flight data log to geotag and pre-process in rapid mode. When merging, when Pix4D tries to create quality report, I stop it from continuing with that process. Then it stops while project is merged. Then all I do is open “Image Property Editor”  and edit the camera model ensure all paremeters are correct for the camera. What I noticed is that when merging each lock bring in camera model as if these blocks were mapped using different camera models. So Just ensure all of them are exactly the same and of correct parameters (sensor dimensions, focal length, pixel size etc). the I run step one again in full mode or 1/2 in order to overwrite data generated during rapid processing of individual projects. Once this step is completed, I simply continue with the usual workflow. No MTPs and no pain related to MTPs and the quality is as you see below. The rapid processing done on each sub-project is just for easy of merging. 




I hope this helps someone else, I will test it on my other projects that I had troubles with in the past to see how repeatable this solution is.

So, I believe geotagging all images and processing them all as one big project would work the same way, my only trouble is that i don’t like geotagging with Mission planner, because sometimes there are slightly fewer images that messages and you end up with all sorts of trouble, while it seems Pix4D is able to work out based on possibly time sync, i use that and works better less hassle. In the past i used to copy an image several times for the extra messages then i would delete the copies before processing, i realized that was also unnecessary pain.

Thanks all for your time and ideas.







I am glad that you have found a workaround. Just one question to make sure that I correctly understood your workflow:

In the first attempted to merge the projects your imagery was not geolocated? If so, how does it come that you have a height/altitude and the projects are not placed on an arbitrary CS?

Although it is possible the process projects together if there are big differences between the flights we always recommend to do the calibration individually since the camera parameters may change from one flight to another. 



Hi Ina


In all attempts, images were being geolocated using Pixhawk’s BIN (dataflash log) converted to .LOG. see as shown below.


At first, I tried to have all the images  geotagged using Pixhawh geotagger, but that did not work because of mismatching number of photos versus messages; and the time offset with pixhawk I don’t really like it as it seems unreliable; many times I have used in the past I saw it misbehave. If that worked, i would simply load them up all in one project and process them as one.



Therefore my best option for geotagging was to use Pix4Dmapper and the .LOG file; it does a very good job even if you have mismatch between images and messages. The only problem is that you can not load up all the photos in one project and use the log files one by one to progressively geotag the images. As a result I was forced to create each flight a separate project and geotag it them run rapid process. All the rapid processed data then were merged into one big project, but really with intentions to bring all the geotagged images into one project rather than using the rapid processing results. That is why as soon as it tried to create quality report after merging, I just cancel it and run the whole step 1 afresh. 

Surely, images can be processed without geotagging, but it takes nearly 3 times longer and many images are left uncalibrated especially those in areas with full vegetation cover. 

It would have been nice to do the calibration individually as you say because like for us our missions are usually long because our birds can stay afloat for +2hours and can be well over 1500 photos per mission. Tribute to our developer ARACE Aerial Systems who build our birds as seen below.

Unfortunately though, calibrating individual projects unless I go through the MTPs  option does not seem to be helpful, I would rather go through the workflow I just invented which has shown excellent results, Ihope you agree me based on the quality report I posted. As I said I am going to test this approach on another two projects which I had exactly same problem and was never re-solved but I ended up using a different software to process. But I have been a Pix4Dmapper since back in days when I first used customized into  " Post Flight 3DTerra". 


Do you think there could be better algorithm to replace the use of MTPs soon? I would like to see that one day.




Hi Clarence,

What would be interesting to try is to geotag the images using the Time offset and Use Cam message since it could be more restrictive. If this works properly then you will not have to do all the tricks but just processed all images together.

Again this is a guess, but I believe it is worth trying :-).


Let me know.





Most of the time I used time offsets with mismatching photos versus messages, I did not have much joy. I found photos positioned in wrong locations. Especially when the date and time on Camera is wrong the calculated time offset comes out weird leading to images being located  either ahead or behind their true positions. That is the whole reason I went and used Pix4D with the log file.

CAM messages Synchro is my proffered, but then there must be a perfect match between photos and messages.



Thanks for letting me know.

I am sorry to learn that the time offset with cam message does not work for you. In this case, you should continue with the workflow that you have described earlier.