Z-axis inverted?

[falconensis]

Hello all,

I am teaching an undergraduate class in SfM and I wanted to use the dataset found here: GitHub - merkato/odm_boruszyn_kap: OpenDroneMap Boruszyn dataset · GitHub

The dataset is small enough that most students will be able to run it without a problem. However, after testing it myself it seems like the orthophoto, as well as the 3D model, are upside down.

The negative-GSD warning appears late, during report generation: [WARNING] Negative GSD estimated, this might indicate a flipped Z-axis. (the complete task output is pasted at the end of this post). I loaded the gcp_file.txt along with the images and used only the default setting.

I will assume that the GCPs were included since the report reads, “Geographic Reference: GCP” and “GCP errors: 12.91 m.” Though the report only contains a table with 2 GCPs, 1 and 2 even though there should be 5.

Importantly, the orthophoto had already been generated before this warning, and the subsequent processing continued normally.

The browser was Safari on a MacBook Pro, Apple M2 Pro, 16GB of RAM).

Any suggestion would be appreciated. Thanks!

Mathieu

Truncated Task Output

console.txt

---

[falconensis]

Hello all,

Let us not worry about this dataset and my question. I tried to recreate the GCP file but to no avail because it is difficult to know where the GCPs are located on some of the images. I just need to choose another dataset for my in-class exercise, that is all.

[Maurice.Sobiera]

Hi Mathieu,

in case it is still useful for you or anyone else using this dataset: we reproduced your result exactly (Negative GSD warning, flipped model, and in our case OpenMVS then stopped with “no valid point-cloud for the ROI estimation”), and found the cause.

The pixel coordinates in gcp_list.txt are for images at half the current resolution. The images in the repo are 4608 × 3456, but the largest pixel values in the GCP file are x = 2026 and y = 1620. The file was apparently made in 2012, when ODM resized images before processing. So every GCP observation points to the wrong spot. With so few points and no GPS in the images (kite photos), the GCP alignment then fits the model upside down.

You can see it directly in the images. Same GCP, three photos, top row = coordinates as in the file, bottom row = coordinates × 2:

With × 2 all three observations land on the same field corner; as given they hit random spots in the field.

Fix: multiply columns 4 and 5 by 2, e.g.

awk 'NR==1{print;next}{$4*=2;$5*=2;print}' gcp_list.txt > gcp_list_fixed.txt

or just use the corrected file (only columns 4 and 5 changed):

gcp_list_fixed.txt (881 Bytes)

With the corrected file and default settings everything works: all 46 images in one reconstruction, positive GSD (~4.2 cm), no flipped Z. Result: Z-Achse Boruszyn (Forum 26966) – Standard + GCP-Pixel ×2 (Datei für halbe Bildgröße erstellt) - WebODM

Two remarks:

• The GCP fit is still only ~7.7 m average (CE90 ~10 m), so the 2012 point marking isn’t very precise. Fine for an exercise, not for survey accuracy.
• One GCP (340594.082 548098.123) has z = 70.0 in one line and 70.5 in the other two. ODM treats these as two different points, which may be part of why your report showed fewer GCPs than expected. Use the same z on all three lines.

The CRS (EPSG:2180) is handled correctly. We checked that the points end up in Boruszyn (16.64° E, 52.78° N).

Best regards,
Maurice / Bitblade

[falconensis]

Dear Maurice,

Thank you so much for spending time figuring out the problem. I will definitely let the students know about the fix, the reason of the issue, and of course why the open-source community is an asset.

I had noticed the 70 versus 70.5 but changing that did not improve the upside down Z-axis. I had also turned to AI for help but to no avail. The last suggestion from ChatGPT was to recreate the .txt file via the built-in GCP editor but I could not find the GCPs in the photos very well. So I eventually gave up. And it is likely that I would have reused the sizes of the pictures already found in the txt file so that would not have helped.

So, just out of curiosity, how did you solve the issue? I suspect that you have used ODM for much longer than I have but how did you think about looking into the sizes of the images? It never occurred to me that this could be the problem.

Thanks again for the help!

Mathieu

[Maurice.Sobiera]

Hi Mathieu,

Glad it helped – and thanks for passing it on to your students!

Here’s how I approached it:

1. Run without GCPs first. The model came out the right way up, so the image alignment itself was fine. A Z-flip that only appears once GCPs are used usually means the GCPs are pulling the reconstruction somewhere the photos don’t agree with.
2. Draw the GCP pixel positions onto the photos. For each line of the GCP file I plotted the given x/y on the referenced image. The markers didn’t sit on the targets – they all landed in the upper-left quarter of the images, at roughly half the distance from the corner where the real targets were.
3. Compare the coordinate range with the image size. The largest x/y values in the file were almost exactly half of the image width/height. That pattern almost always means the points were picked on downscaled copies of the photos (a preview or resized export) rather than on the originals.
4. Fix: multiply all pixel coordinates by 2, re-run → markers land on the targets and the Z axis is correct.

Why it flips instead of just getting a bit worse: with every image coordinate halved, the rays from the cameras to the GCPs all point to the wrong places, and the georeferencing finds that a mirrored/upside-down solution fits those wrong rays better than the correct one. Small tweaks like 70 vs 70.5 can’t fix that, because the error is in the image coordinates, not the ground coordinates.

A quick sanity check for the future: the GCP file doesn’t store the image size, so ODM can’t detect this. Compare the max x/y in the file with the real image dimensions, and open one or two photos to check that the marked pixel really is on the target. That catches it in a minute.

And no need to give up on the GCP editor next time – it works fine as long as you pick the points on the full-resolution originals.

Best,
Maurice