Forum

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - smescarzaga

Pages: 1 [2]
16
Hello all,

I've been trying to search through academic papers to get to some critical or baseline publications that discuss and resolve the question posed in the subject line. I haven't much luck beyond the off-handed suggestions that long focal lengths are less desirable for 3D reconstruction; but no explanation as to why. Can anyone chime in on this questions and, if possible, suggest any relevant literature?

Thanks,
S

17
For anyone still interested: After speaking to a photogrammetry expert, it was mentioned I should fix the initial focal length before aligning and avoid optimizing it during gradual selection. This seems like it's actually producing a more accurate ground elevation.

I'd still like to input the principle point coordinates and k1, k2 and k3 values listed in the cameras calibration certificate. The only problem is I don't understand which units PS wants these values input as.

Attached is a screenshot of the calibrated parameters of the camera and of the radial distortion factors. Can anyone tell me how to input principle point coordinates and k1, k2 and k3 values into PS properly?

18
Hi folks,

I just wanted to check in to see if anyone had any ideas as to why this is happening. It seems strange that cameras GNSS/IMU hihg-precision data is producing such strange elevation values.

I'm also attaching here one of the .geom files that accompanies each .jpg. I've stripped out lat, long and altitude from the line
Code: [Select]
latlonh_platform_position omega, phi, kappa from their respective lines. This .geom file is from a nadir shot.

Is there anything in here I could potential add to the processing to help constrain those z values?

19
Hey Alexey,
Thanks for responding. I'll message you the reports from both nadir only and nadir/oblique jobs (they are chunked up differently only due to more images being processed in the nadir/oblique job). I'll also message you the calibration certificate.
S

20
I should also attached screen shot of camera calibration here.

21
General / Re: Dealing systematically with noise created by water bodies
« on: September 17, 2018, 09:45:48 PM »
Awesome, I'll definitely give this a go. Many thanks for your reply here and to my other thread.

22
Attached is a screenshot of the reference settings panel. These are used in both nadir only and nadir/oblique mixed.
The photos came with no exif data, only a recent camera calibration document from the manufacturer (from which I got focal length and pixel size).

23
The title pretty much sums it up. Let me give some background info on the data, processing etc:

The imagery from a high-end survey camera and delivered along with post-processed camera coordinates and omega/phi/kappa values. Manned-aircraft, flying at ~ 2333m (height above ellipsoide, I think since it was delivered in WGS) collected 0.25m/pixel nadir and obliques (forward and aft) at each camera coordinate. Although photos within the oblique collection are smaller (width x height in pixels and also dpi), I'm using the same camera calibration values that I used for the nadir data.

I was keen to include the oblique dataset in the processing because there wasn't great overlap with just nadir alone (I don't believe 3D reconstruction was the primary purpose of the survey). Comparing results from nadir only and nadir/oblique processing runs are...interesting. I'm getting better overall error with the nadir only job, which I guess I understand. HOWEVER, when looking at elevations values between the two, they're waaaaay off. Nadir only values are up to ~200m off from expected values whereas the nadir/oblique mix produces much more reasonable values.

Can anyone tell me what gives and how to fix it? I've read in the manual that PS expects camera heights to be height above ellipsoid, so I'm hoping the values that were delivered with the photos are ellipsoid height as opposed to have some geoid applied to it. I can't see this mix up creating such a large discrepancy though.

Thanks!

24
General / Dealing systematically with noise created by water bodies
« on: September 17, 2018, 06:04:00 AM »
Because I'm working with coastal imagery, nearly every photo in the dataset (~4,000) has water pixels in it. This has caused a lot of noise in the dense cloud, particularly near the land-water interface (which is were I'm interested in studying) I think it'd be rather inefficient to try and mask every photo manually in Photoscan or photoshop. I had a tip from someone to, during the gradual selection phase, remove all tie-points that had an image count of 2. Not only did this remove much more than half of the points (not the best overlap), but I still ended up with a bunch of noisy points in the water. T
Since the ROI is rather large, my next thought was to try filtering these points out systematically with a filter (maybe in cloud compare) looking for areas of high frequency z change. 
Has anyone had any luck with filters in or outside of cloud compare filtering out noise due to water? I've attached a screenshot of some of the noise.

Thanks.

25
General / Re: Using pictures with different sizes in the same project?
« on: September 16, 2018, 05:47:36 AM »
Hi Sav,
I'd like to follow up with this issue:
I'm working with manned-aircraft image data from a high-end survey camera (Applanix). Surveys were flown with nadir, and forward and aft oblique photos. On-board GPS/IMU gives me survey grade positions and omega/phi/kappa. However, the obliques that were delivered are of a different size (7212 x 5408 for obliques @ 72 dpi and 10328 x 7760 for nadir @ 96 dpi). In doing some testing, I've decided to process the obliques with the nadirs as there not a huge amount of overlap among just nadirs and, curiously, I'm getting much more realistic elevation values by combining obliques with nadirs. Thus I'm using the same camera calibration across both datasets (0.0052 x 0.0052 pixel size (mm) and 51.542 focal length (mm)).

What you're saying here is that that should be ok...?

Thanks.

Pages: 1 [2]