Negative GSD , Flipped Z axis Error

ODM
, ,
#1

Hello People!

I am having latest WebODM Native Windows Version on my new Laptop.
Core - i9
RAM - 64 GB
WebODM installed Drive Space - 600 GB SSD
GPU - 12 GB

I am continously facing ‘Negative GSD , Flipped Z axis’ issue with my dataset.

We are collecting same region data from last 3 months. No change in Camera Parameters or anything related to Image Capturing.

I even tried changing Processing Paramenters.
–ignore-gsd flag, dsm:true, dtm:true
With diffrent combination at lowest settings.
What Can be the Possible Reason for facing this issue?

console-22a.pdf (2.7 MB)

1 Like
#2

What camera/sensor are you using?

#3

21 megapixel… 1 inches CMOS sensor. Phantom 4 pro v2

1 Like
#4

Is the survey at nadir or perpendicular to the ground? Is this changed from prior logs of the same sensor/flight plan prior?

#5

perpendicular to ground. No changes at all.

#6

console (2).pdf (113.0 KB)
another console output
dsm: true, dtm: true, force-gps: true, ignore-gsd: true, mesh-size: 300000, pc-classify: true, pc-geometric: true, pc-las: true, resize-to: -1,

1 Like
#7

Unrelated to your inquiry, but you should really try to not use --ignore-gsd unless you absolutely need it, and I’m not seeing any indication that you do need it.

You can try these instructions to see if this squashes the warning message:

OpenSfM must have guessed the orientation incorrectly.

If you have a dataset at hand that exhibits the issue, you can try to patch / manually override the OpenSfM config to set align_method to orientation_prior always (currently that only happens if a dataset is not georeferenced).

https://github.com/OpenDroneMap/ODM/blob/master/opendm/osfm.py#L228
1 Like
#8

Ohk, I keep it in mind. --ignore gsd should not be used, but even if I’m using just dsm and dtm true, then also error is coming.

1 Like
#9

I’ve had it for a number of my datasets when I’m shooting from the ground or parallel to the ground. Normally they still reconstruct fine. Is your reconstruction wrong?

#10

It just stop , I gave you console, there’s nothing I’m getting what is the problem.
Even if it completes… I get flipped point cloud , but quality is good and bits and pieces of orthophoto.

1 Like
#11

Try without --ignore-gsd. It leads to hard to track down crashes in most cases.

#12

Ohk, I’ll do with only Dtm and Dsm tru options. And let you know the results.

1 Like
#13

console (3).pdf (584.9 KB)
This is the clog output for option [dsm:true and dtm:true]
The pointcloud is fine, no proper orthophoto and textured model…
report_compressed (1).pdf (244.8 KB)

1 Like
#14

That shift is incredibly strange…

Can you re-process without the GCPs? I’m wondering if they might have an error.

#15

console_without_gcp.pdf (144.0 KB)
This is the result. Now it’;s showing same error in odm post processsing. one step further than before

1 Like
#16

Perhaps try with --rerun-from dataset in case some prior stages aren’t in a good state.

1 Like
#17

How does resize options affect the processing and quality?

1 Like
#18

Resize when uploading? Directly. Say your dataset has a GSD of 5cm/px at full resolution and you resize to half the image size, you’ll have a GSD of roughly 10cm/px as a result.

1 Like
#19

Oh… But it does make the processing fast… right?
And yes… Resize option : 2048 px while uploading.
Where should I use it and where not?
Also how much to resize.

1 Like
#20

It can speed up processing, yes, it can also allow you to process more images in a Task than your RAM would normally allow you, and/or let you bump other quality parameters up (though how effective that is depends upon input data quality).

You might want to use it where it doesn’t negatively impact your output data. If you have certain constraints for GSD or perceptual quality, you may not be able to meet them with resizing.

Again, to my prior point: How much to resize depends upon what you need to do and what your output quality constraints are.