Phantom4 Multispec red edge densification fail

PIX4Dmapper
1

Hi there,

I’ve got a couple of big P4MS surveys (>100ha) that I am seeking to process in Pix4dmapper.
They were (mostly) acquired with RTK FIX, and have RTK GCPs available also.
The drone was flown 80% forwardlap, 70% sidelap, 120m AGL. The projects have either 10,000 or 12,000 .tif files as input (ie the P4MS bands 1 - 5).

For both of these surveys, I run initial processing and create a decent, if slightly noisy sparse point cloud.

image
image1463×707 120 KB

When I try to run the point cloud densification stage, the red, green and blue bands seem to run just fine, however for both surveys the red edge band fails with the following error:

image
image1910×1244 274 KB

I don’t understand why it would fail on just one band. I haven’t processed much multispectral data in Pix4dmapper before. Based on the reading I’ve done, I’ve followed the recommended workflow, which is:

  • create a new project
  • import only the .tif files from the flights. Ignore the .jpg files. Import all the .tif files for each band.
  • use the multispectral template
  • run initial matching
  • apply GCPs (when I do this it only seems to let me apply GCPs to the blue and red bands, ie files *1.jpg and *3.jpg)
  • run stages 2 and 3 to generate the mosaics for each band. For the densification, I’m using the default settings of 1/2 scale images, low point density and minimum of 3 matches per point.

Can anyone offer any suggestions or guidance as to how to overcome this issue?

2

Hi all,

I didn’t get a response here, and Pix4d Tech support, while prompt and polite as always didn’t offer anything that I hadn’t already tried/read.
In the end I had to process my flights with Metashape. I’m not blown away by the results, so would be open to going back to Pix4d for Phantom 4 Multispectral data, but I’d rather get acceptable results from Metashape than no results from Pix4d!

3

Hello Mike,
We are sorry that this thread was missed. Looking at your initial explanation, you said that you couldn’t mark GCPs for any image other than blue and red bands. This is not normal, the software should allow you to mark all the images for all the bands, and we also recommend marking at least 2-3 images from each band while marking the GCPs. Can you see anything weird in the project that might be having this issue?
Can you please forward us the quality report of the project and the .p4d files so we can look more into it?
Before you send us the above information, could you try the below recommendation and see if that helps?

  1. Change the camera rig processing option to Optimize Relative Rotation. For more information on changing the setting, follow the steps explained in the below support article,
    https://support.pix4d.com/hc/en-us/articles/115005852003-Processing-camera-rigs
4

Hi Kapil,

Thanks for the response.
I’ve tried multiple different surveys of various sizes, both with and without GCPs and I get the same error, so I don’t think the GCP process is causing the problem. I should note that the densification fails the same way either time, but sometimes on the NIR, others on the RE.

We’ve previously processed a few P4MS flights successfully in Pix4dmapper. My colleague deleted the .p4d and project files, so all I have to compare is the report .pdf, but those same settings aren’t working for me. I’m running this in GDA2020, whereas those previous surveys were in WGS84…not sure if that would affect anything?
I manually checked all the EXIF data for one of the new photos that isn’t working vs one of the photos for a survey that did work - the drones were running the same firmware version, so no easy wins there.

I’m currently testing on a subset of images from the middle of one of the survey sites - the whole dataset is 10,000 .TIF files, I’m only running 890, so it runs much quicker. Being in the middle, there are no GCPs to apply, and I’m getting exactly the same error as described above.
The spare point cloud looks really good, although some of the camera positions are obviously wrong - it was an RTK survey so shouldn’t be seeing that much difference between computed and initial positions.

image
image1529×1485 128 KB

I’ve just kicked it off with the “Optimize Relative Rotation” setting, so will report back with those results when complete.

5

I have emailed through the report at a zip file (no pdf version, so zipped up the xml/html one), and the .p4d file.

I used my previous support ticket - 127498.

Please let me know if that works or not.

Cheers,

  • Mike
6

Hello Mike,
If the project is not working, the log file and the pdf version of the quality report are important. So, can you attach whatever you have in the ticket, and I will look into it? Could you also provide the details about the hardware you are using in the same ticket?

Thanks,
Kapil

7

Just thought I’d update this issue in case anyone else suffers the same problems:

I shared some of my data with Kapil and Rosana and they were able to replicate the issue and do some deeper digging. The problem was that the principal points and perspective distortion numbers being saved by the drone in the EXIF data were very wrong for the RE and NIR bands.

Example of EXIV2:

image
image712×61 37.3 KB

Parameters based on the default settings from Pix4dmapper camera library:

image
image724×778 67.9 KB

I overwrote the settings in Pix4d with the numbers provided by Kapil and the project processed to completion.

Interestingly, I checked the EXIF data for the last time we used a P4MS (a different drone), and we didn’t have anything like those crazy numbers, even though the drone firmware versions were identical. I’m wondering if DJI calibrate those settings for each camera/drone and something went wrong with that drone…

Anyways, too late for this project, but good to know that there was a solution. Hopefully this info helps someone else.

1 Like