Avoiding problems with incorrect Orthomosaic elevations, using feet instead of meters, using State Plane, or seeing a Black pane with red dots during processing

Hello, I am posting this after several days of methodical, sequentlal testing while capturing screenshots at points in time. Ideally, representatives of Pix4D will provide additional information, so that Pix4D customers can have more success when using the Pix4D Mapper (Desktop) user interface, Help pages and supporting video tutorials.

This post is primarily for someone who is attempting to use State Plane coordinates within Pix4D Mapper (Desktop) (“Pix4D”). I chose Pix4D because the licensing option was appropriate for annual work on an environmental monitoring project with a limited budget. I have a one month license of Pix4D (soon to expire). I have prior experience with a trial version of Pix4D, a trial version of Global Mapper, and Pix4D Capture for mission planning. I have studied many of the Help pages, searched the Community site, and watched tutorials. Before this last round of using Pix4D, I had created many Pix4D Projects.

Unfortunately I found several ways to be unsuccessful with Pix4D. If you are having difficulty, maybe the following sequence of screenshots and comments will help in your troubleshooting and interactions with representatives of Pix4D and other software suppliers or online services. Clues to some success are in screenshots 1 through 11 below.

Background:  I commercially operate several different UAV systems covering a wide range of field applications. The most recent acquisition is an Inspire 2 with the related kit from Klau Geomatics, and I have seen <3cm results in X, Y and Z axes after PPK with correction with data from a local CORS in the Washington State Reference Network. Therefore I am not using Ground Control Points during Pix4D processing. However I have Ground Check Points for comparison to Pix4D model data.

Screenshot 1 (below):  Up until a few days ago, none of my Pix4D models were successful when I attempted to use State Plane coordinates. 

However by the date and time of screenshot 11….  I had discovered settings that resulted in a model with correct X_Y_Z coordinates in meters.

Let’s start with Screenshot 1, below, where you can see the top of the images table. Note the Pix4D default values in the Vertical and Horizontal Accuracy columns. With default values the process is over 7 hours on my Lenovo P70. I could have changed the values to 3 cm (or to 0.09 ft) to match the values on my PPK geo-tagged images, however I did not require that level of accuracy in this model. 

Screenshot 2:   Note the selection of ‘ft’ and ‘Arbitrary’ in the context of this popup.

Screenshot 3:   The model has been generated. Note the elevation value of -57.37 feet for the marker on the large rock. 

Screenshot 4:  The value of a point on the sand below the rock wall is -68.44. Checking other points in this model, the elevations are increasingly negative starting from some camera sensor altitude above the ground.

Screenshot 5:   Note the change from feet to meters, leaving this ‘Arbitrary…’ selected. The resulting model continued to have the incorrect negative elevation values.

Before clicking OK, I used ‘Save Project as…’ to save the previous Project with a different name (‘Oct.11’).

Screenshot 6:   Leaving ‘meters’ selected, note the change from ‘Arbitrary…’ to ‘Known…’ with WGS 84, prior to checking ‘Advanced…’.

Screenshot 7:   After checking ‘Advanced…’, note the selection of this ‘Arbitrary…’.

Screenshot 8:   I saw the Warning popup, then clicked OK.

Screenshot 9:   Decided to ‘reoptimize’. This screenshot is after clicking to reoptimize. Conveniently, the two red ‘cameras’ related to the images of my two ground check point markers were ignored later when Orthomosaic views were generated. 

Screenshot 10:  Note the Warning.

Screenshot 11:   Note the Warnings about two skipped images. Not a problem. I had left those two image files in the larger collection. Good to know that Pix4D skipped those files. Note the Warning about Ortho Gain.

After processing was complete, were the X_Y_Z values correct in the Orthomosaic view? Yes! Success! However units are in meters, not in feet.

You can stop reading here, if you are content with models/views in meters.

However I wanted a way to display feet rather than meters, and to use State Plane settings.

(As of the date of this original post, I had no success with using feet or State Plane. Maybe by posting this, someone will suggest a way.)

Screenshot 12:   Now I changed Units from meters to feet. See the values for ‘Selected…’, ‘Known…’, and ‘Arbitrary…’. I am not positive, however I *think* that the values in ‘Selected…’ and ‘Known…’ were populated immediately after I selected ‘ft’ for Units.  

Screenshot 13:  The screenshot below is just prior to selecting a value from the EPSG list. (In past experiments with Pix4D, #2855 was missing in the drop-down list for EPSG. This time, with this Project, I found and selected #2855. Curious that 2855 was not visible in previous Projects, however it was this time. Really, I looked very carefully during past Projects but failed to find ‘2855’.)

 

Screenshot 14:   I found the message below to be ambiguous. If I knew the intent of the author, I might suggest different text. I clicked Yes.

Screenshot 15:   Warning before reoptimizing.

Screenshot 16:  Note the Warning popup. What is not visible is a rotating symbol (like: something is being processed) that continued for many minutes. I opened Task Manager to see if there was substantial activity. After a few minutes I gave up and clicked OK, which caused processing to continue.

Screenshot 17:   Waiting for Tie Points.

Screenshot 18:  Just prior to choosing Reoptimize first (as prompted), before Steps 2 and 3.

Screenshot 19:   Reoptimizing progressing.

Screenshot 20:  Step 2 started.

Screenshot 21:  Process failure. Should I start all three Steps, again? I decided Yes.

Screenshot 22:  Processing all three steps. (Just before grabbing this screenshot, Steps 2 and 3 were in green text.)

Screenshot 23:   Warning about GDAL.

Screenshot 24:   Seeing negative elevations. I changed from ‘Known…’ to ‘Arbitrary…’.

Screenshot 25:   Shall I wait, or click OK? At this point I gave up trying to generate models in feet or with State Plane.

 

I am interested in this also!

Please include me in responses.

Thanks

Hello John,

After downloading your data, I have done two projects, one in meters and one in feet.

I basically got the same result in both and I also got negative values (same as you get) for the height close to the shore.

The conclusion that I jump to is that the problem with the negative values is due to a wrong altitude contained in the EXIF tags.

By looking at the screenshots, the flying altitude which Pix4D is getting from the EXIF tags is around 6 meters and that is most probably wrong. 

I am not familiar with the kit from Klau Geomatics but it seems that the PPK data in this project was not properly written in the EXIF tags (at least the altitude).

If you use a correct height, you will get correct values.

@Gary, if you click on “Folow”, you will be notified every time there is a new post.

 

Regards.

 

 

1 Like

Hello Daniel, and thank you for your prompt observations. I have forwarded a link to this post to a software developer at Klau Geomatics, along with other information from you as sent through the Pix4D support system.

I am waiting for his response to your - and my - questions and observations.

At this point in time, I can only speculate, since I do not have access to the code at either company. I can only report what I am experiencing with each software product through their respective user interfaces, and through Help documentation/videos.

When I used the Klau product to geotag images, I had the option of choosing WGS 84 or another Coordinate System. My recollection is that I left the default setting as WGS 84.

Maybe I should have made another choice prior to geo-tagging and importing of the images into Pix4D, if my goal was to have an Orthomosaic in feet and accurate elevation values when pointing at a point on the ground in the Orthomosaic.

Fortunately I have retained copies of the original image files from the several flights across different geographical areas of my overall project. I also have the original log files that were produced by Klau equipment during each flight. I also have the CORS data files that I obtained from WSRN.org to use with PPK corrections within the Klau software.

It is quite possible that I am missing some basic education about Coordinate Systems, “Projected” and otherwise. For example, my desire to point at a pixel in a Pix4D Orthomosaic and know the 3D coordinates in layman’s terms (feet in X-Y, and Z above Mean Sea Level) may not be compatible with using this “projected CRS” or other system.

Overall, with much practice I have found that it is possible to make unfortunate choices with either product. I am now reluctant to make assumptions about what I am seeing, or about what is happening in either software product, or about how my actions with Klau software impacts outcomes in Pix4D. 

I am looking forward to learning more and moving ahead. 

 

 

 

Hello John,

Thank you for your comments.

The export from Klau software can be either WGS84 or any projected coordinate system. Pix4D can use any coordinate system defined in its database but it needs to know which one it is, therefore, make sure you select the right one when importing the geotags.

Regarding the orthomosaic, it is not possible to get 3D coordinates out of it. By definition, an orthomosaic is a 2D representation which does not contain any height information. If you want to click in a point and get X,Y,Z, you should go to the rayCloud within Pix4D or use other outputs which do contain that information, for example, the point cloud or the DSM.

Regards.

 

 

Hello Daniel,

Thank you for clarifying that I must first process my images with the Klau software in the coordinate system that I want to use later in Pix4D Mapper. That misunderstanding on my part is probably the cause of most of my issues as reported in the original post, after the comments about Screenshot 11.

Also, thank you for pointing out that an Orthomosaic is a 2D representation, not 3D. Referring back to Screenshot 11 in the original post, I said “…X_Y_Z values correct in the Orthomosaic view.” I meant to refer to what I can see when using the Mosaic Editor, since that is a mode I would often use when reviewing modeling results with the current client. 

My apologies for using the term "orthomosaic’ or “Orthomosaic” too casually later in this thread. Is there a Pix4D term for what is being seen when using the Mosaic Editor? In all cases I was referring to what I can do and see when using the Mosaic Editor. Attached is a screenshot that shows the two terms ‘Mosaic’ and ‘DSM’ in the pulldown menu. The ‘Mosaic’ option is what I have been referring to in this thread.

A specific word, when used in different contexts, can lead to software user confusion and mis-mapping of meaning to the term. Below is another screenshot where the term ‘Mosaic’ is used.

Thank you for your patience, especially since you did not have access to the Klau software product. That said, I hope that my observations about Screenshots 1 through 11 in the original post suggests some potential improvements to the Pix4D user interface and Help documentation.

By late next week I hope to finish re-processing all of my models, after first using the Klau software to re-process all of my image collections in feet, in State Plane.

 

 

 

The Warning section on this Help page attempts to clarify differences in meaning among these terms/phrases: “the Mosaic” and “the mosaic” and “(the) orthomosaic” and “(the) Orthomosaic” and “the edited mosaic” and “the Mosaic View”.

Maybe this term should be used in the Help documentation:  Mosaic Editor Views.

With practice, it becomes easier to comprehend what was meant by the author. However the user must retain a solid understanding of the current context when seeing the word “mosaic” in a sentence or paragraph on the Help page.

 

 

Hello John,

Thank you for your feedback.

It is true that we use “orthomosaic” or just “mosaic” to refer to the same product in our documentation. Please consider both terms to be the same. We should maybe unify it.

As for the X,Y,Z coordinates in the “Mosaic” view, they are displayed because Pix4D is taken the Z from the DSM. However, if you open the resulting mosaic after Step3 (stored at …\3_dsm_ortho\2_mosaic) in a third party software, no Z value will be shown as the TIFF images does not contain such information.

Thank you very much again for your suggestions.

 

 

Hello Daniel,

A recent consultation with Klau Geomatics has resolved my overall workflow problems with using their software with Pix4D Mapper (Desktop). I have now completed multiple, high-accuracy models that exceed their product claims, and when using a State Plane coordinate system. I have also received useful tips for avoiding some typical problems after returning from the field. While other companies offer only pieces of the overall solution to high-accuracy modeling/mapping (PPK or RTK), from my experience it is a wise business decision to go with Klau Geomatics. (I was not compensated in any way for the above comments.)

Thank you for your support, which contributed to my ability to develop a comprehensive self-training package for someone who is new to photogrammetry using images from an autopiloted drone. With Pix4D Mapper, our multiple-year, shoreline environmental monitoring project has begun producing very high-quality results that would otherwise be difficult and costly to achieve. We can now track changes in location and volume of sediment/sand in our local tide flats after winter storms. That information contributes to analyzing drift-cell behavior and finding ways to mitigate damage to real estate properties. 

 

Thank you for your feedback.

I am happy to hear that you are getting good results in your projects.

Talking about accuracy and RTK/PPK, there is a couple of articles that you might find useful:

 

Regards.