I have been using Pix4d for a number of years and have recently started getting some problems. It started off with data from our Ebee in that the pointcloud appeared to be “gridlined” and as you rotate the point cloud in the raycloud viewer the point cloud would disappear and reappear sometimes partially sometimes completely!! When I import this data into Recap though it normally looks OK, it just means you cant do flythrough videos because the image flickers in and out. Recently though I flew a mission with my Falcon 8, the data looks fine until I try to add ground control points, I get the same inverse shur error which apparently only affects the quality report but the data goes heavily gridded and patchy, when I densify it I get the very noisy, patchy and unusable model as in the screenshot below, this ONLY happens after adding ground control! I have processed it without and it works fine? The images have been geotagged by the Falcon but again I have tried with both geotagged and non geotagged images and its fine until I add the GCP’s?? I’m getting desperate to complete this data so any idea would be appreciated. The GCP’s were fired in with a total station and the quality report shows them all to be sub 10mm and there are 2 check points which show sub 10mm and had no issues on the ground so I’m confident that the control is good. The mission was a mixture of NADIR and Oblique imagery.
Given the behavior of the point cloud you are describing (grid lines, blinking, etc.), the issue probably concerns visualization in the rayCloud and not the point cloud itself.
Adding ground control points (GCPs) then reoptimizing does not alter the number of automatic tie points (ATPs), but rather optimizes the model to fit as best as possible the distribution of the GCPs. The fact that the appearance of the point cloud changes after adding GCPs would confirm that visualization in the rayCloud is the issue.
The graphics card (GPU) is the most important component when working in the rayCloud (see Hardware Components Usage when processing with Pix4D), so can you make sure that it is compatible with OpenGL 3.2 and that its driver is up to date? Which GPU do you have?
I’m sure it’s not an issue with my hardware because I have reprocessed the exact same dataset without adding GCP’s and it comes out perfect, if it were a hardware issue it would surely effect the reconstruction either way? To prove it wasn’t a visualization issue I ran the pointcloud into Recap with the same result of it being very noisy although not so heavily gridlined. As I mentioned I have the same issue to a lesser extent with data from my Ebee, the problem seems to me to be trying to use geotagged data and then add GCP’s to it, something happens at this stage to cause the issue, I am currently rerunning a recent Ebee project and will not add GCP’s to try and prove the point.
OK to prove the point I have reprocessed a job I have flown with my Ebee without adding GCP’s, the image below is the original project using GCP’s collected with a survey grade RTK GPS, as you can see the data is gridlined and is less dense
Now this is the exact same project processed without adding the GCP’s, I have included a shot showing the image locations as well. Much nicer data with no sign of gridlining and also more dense, what could possibly be going on here?
I would appreciate if someone can shed some light on this, I had previously attributed it to poor imagery from the Ebee compared to my Matrice 600 with A7r but the Matrice could never obtain geotagged imagery. Now I have the Falcon 8 with A7r and the ability to geotag it seems the issue is somewhere within Pix4d? This error always seems to be accompanied by the inverse shur coherence error as well, which apparently only effects the quality report but I’m pretty sure something else is going on as well?
Thank you for publishing the results of your tests - I have a better idea of what is happening now.
I can now see that indeed, it might not be hardware related. The behavior of your project is similar to what we have already seen before and the issue was related to the ground control points (GCPs) coordinates.
1 - Make sure you selected the right coordinate system. And could you post a screenshot of the Map view of your project?
2 - Adding a processing area around your project area could help. Could you try doing that and then process step 1 again?
The co-ordinate system for the geotagging is WGS84 and this is auto detected by pix4d, The ground control points are always surveyed in OSGB co-ordinates so I select arbitrary as the output co-ordinate system. Is this correct?
With regards a processing area, I have tried this also but it doesn’t change whats happening.
What are your thoughts on what could be going on with the processing steps? As I mentioned its always accompanied by the invert covariance shur error? Could this be the base of the problem?
Thank you for trying, and the coordinates systems for your images and GCPs seem to be correct.
Regarding the other similar case we had, the client was using the site calibration procedure. It turned out that running step 1 again (not reoptimizing) after adding the ground control points (GCPs) got rid of the gridlines in the point cloud.
Could you try this and let us know if it works?
In this case, it seemed the gridlines were due to the big shift that is introduced with the site calibration. When creating a project and processing step 1, a rough estimation of the processing region is defined. After marking GCPs and reoptimizing the project, the whole project is shifted to the locations of GCPs whereas the first estimated processing region stays at the original location of the images.
Running step 1 again after adding GCPs will shift the processing region with the project.
I have tried processing as you suggested by rerunning step 1 and it works The only issue is the quality report has strange information in the image position and gcp sections, although the text is correct with regards accuracies etc. Should perhaps a note be added in your documentation regarding this step? I surely cant be the only person experiencing this if with geotagged imagery and OSGB control points??
Thanks for helping resolve this issue, should this be added into the the Pix4d documentation? I surely can’t be the only person who has this problem and it’s frustrating that I have been struggling to get acceptable data from my Ebee when the solution was relatively simple. Anybody using Geotagged imagery combined with regional survey grids must experience the same?
For now, we have had very few reported cases - actually two, taking yours into account. The product development team is aware of it and, in the meantime, we will use this forum post in case someone else runs into the same problem.
These cookies are necessary for the website to function and cannot be switched off in our systems.
They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences,
logging in, or filling in forms. These cookies do not store any personally identifiable information.
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site.
They help us to know which pages are the most and least popular and see how visitors move around the site.
All information these cookies collect is aggregated and therefore anonymous.
If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
These cookies may be set through our site by our advertising partner (Google).
They may be used by Google to build a profile of your interests and show you relevant adverts on other sites.
They do not directly store personal information but are based on uniquely identifying your browser and internet device.
If you do not allow these cookies, you will experience less targeted advertising.
The only issue is the quality report has strange information in the image position and gcp sections, although the text is correct with regards accuracies etc. Should perhaps a note be added in your documentation regarding this step? I surely cant be the only person experiencing this if with geotagged imagery and OSGB control points??