Pix4Dmatic/processing PC crashing during densification


I’m having a lot of issues processing some of my recent Phaseone datasets, with my computer crashing during densification.

After I restart the computer/software/project, I’m unable to restart form the densification step that previously failed. Instead I have to start from calibration over again.

Not sure what the issue(s)
2022-06-05_14-37-24.txt (1.6 MB)
2022-06-07_12-22-28.txt (1.4 KB)
may be, but I’ve added the logs to try to help understand what is happening…

Hi Rory,

Thank you for attaching the log files. Upon review, I can see that there was not enough space on the disk to save the dense point cloud. I see that you started with almost 100 GB. With cameras such as Phase One with larger image sizes/resolutions, it is imperative to have ample space as they can generate rather large file sizes during processing. I see that by the time you reached the densification step, there was only 15 GB left which was not enough for the dense point cloud.

Adding more storage space will allow you to process this project at the current settings. Reducing the Image scale and Density can help reduce these file sizes to work with the storage space given.

However, the article Recommended Hardware - PIX4Dmatic recommends 100 GB - 200 GB Free space (2’000-5’000 images at 20 MP) as a bare minimum. The current recommendation is using SSD, 150 GB - 250 GB Free space (2’000-5’000 images at 20 MP).

I hope this information proves helpful.


1 Like

Hi @Jonathan_Dennis thanks for looking into this.

In my case I have Pix4Dmatic installed on my C drive which is the one running out of space here, but all of my data and exports are on a separate 2TB SSD.

Can I configure my settings so that Pix4Dmatic uses my high volume data drive for all of the temporary densification files? I don’t really want any new files to be generated on my OS drive to be honest, and I’d prefer to avoid reinstalling Pix4D onto my data drive.

Further to this - the other problem is that when this happens it seems to corrupt my entire project, so I need to start again form the calibration step. Is there any way to recover the calibration information so I can just restart from the densification step?

Hi Rory,

Glad to help.

It is best and recommended that you keep PIX4Dmatic on your C drive. You are correct to have the processed data saved to another drive as you have it, to save space on the C. The best course of action to take would be to upgrade your C drive to something larger, and SSD if possible.

There is no way to recover calibration information from a failed project.


Thanks Jonathan,

I’ll take your advise and look into a larger C drive - we do have a 500GB SSD but with these PhaseOne datasets are quite taxing!

There is no way to recover calibration information from a failed project.

Understood, though this should be considered a bug, or at least a feature to be implemented in my opinion. I had successfully completed calibration and checked it before the failed densification step, and that calibration information should be resilient to corruption. Put it this way - I could have backed up my project manually before attempting densification and been able to recover it, so why can’t Pix4Dmatic just back up this information itself and save me the effort if things go wrong?

Hi Rory,

Pardon as I misunderstood the question and misspoke. As mentioned, you can save after running a successful calibration step. If the project crashes, upon reopening, there is an auto-save function that recovers the calibration results but it is necessary to save before closing again, or reprocessing as the results will be lost.

Scenario 1) If crashes during densification, calibration succeeds, and the project was not saved. There is an auto-save. Calibration should be recovered after re-open the project, however, you would need to save the project before closing it again, otherwise, the processing results will get lost.

Scenario 2) If densification fails, calibration succeeds, and the user saves the project. Then the project can still be reopened with the successful calibration results. Densification can then be run after the disk is cleaned up.

If this is not the case, then there would be a bug.

I hope this helps explain things better.



Thanks for the additional information @Jonathan_Dennis. And no need to apologise! looking back I didn’t express the question as clearly as I should have or explain everything I saw.

Considering your two scenarios, it’s a strange situation for me since my calibration results weren’t lost per-se, but seemingly corrupted. After re-opening the project:

  • The UI suggested I had run and completed calibration
  • I could see all the auto-tie points in the 3D viewer if I remember correctly)
  • I was still able to command the start of the densification step, as if the calibration step were completed separately and successfully
  • I was able to reopen the project repeatedly to this same stage

The issue was that if I attempted to start processing from densification it would immediately crash.

In any case, the greater issue is solved now that I have cleared more space in my C drive, so happy to close this query. I will say that relying on the user to understand that they need to manually save a project after a reopening that project when it fails is not so user-friendly (even if this is a really unlikely situation).

I wonder if there would be any real downside to just writing the calibration results to disk as that step completes, as if the user had manually saved the project in between calibration->densification…

Hi Rory,

Ok, so it sounds like you experienced the appropriate behavior. The immediate crash was the software looking for and not finding enough space on the drive to proceed with the task.

I will say that relying on the user to understand that they need to manually save a project after a reopening that project when it fails is not so user-friendly (even if this is a really unlikely situation).

We would absolutely agree. When inquiring about this with the team, I was informed that this has already been recognized and they are currently working on improvements here.

Following the release notes with new versions should signal their implementation.