Messages

391

General / Re: Agisoft PhotoScan 0.9.1 pre-release

« on: March 07, 2013, 03:53:49 AM »

Mosaic issue?

I generated two orthophoto mosaics with 0.9.1 and was surprised to see some artifacts in the mosaicking. The surface model still looks OK, but there appears to be least one horizontal seam in the image - right in the middle. It's not completely clear to me if it is continuous or not, but I did find it exactly in the middle of two different images I generated from two different areas of a model.

Projection was NAD83 UTM 10. orthomosaic bounds were specified in integer meters.

392

General / Re: Agisoft PhotoScan 0.9.1 pre-release

« on: March 07, 2013, 01:44:00 AM »

Export Orthophoto/Blending Mode Average crashes Photoscan.

I attempted to generate both tiff and jpg orthos with blending mode average. Both times Photoscan crashed. I successfully exported a mosaic with the same dimensions, so the problem appears to be specific to the pixel-averaged image export.

crash reports were sent (according to the reporter). Let me know if I can do anything else.

393

General / Observation on point cloud alignment with long "ribbon" orthophoto and many GCPs

« on: March 06, 2013, 09:18:21 PM »

I wanted to share a learning experience I had today. I have been working on a long narrow stretch of coastline where we have 30-50 m bluffs and GCPs at top and bottom of bluffs. Also a long spit. The area was flown from 500m with about 500 images.

With the unreferenced model, there was noticeable "frown" over the length of the shoreline (about 15 km). After changing to WGS84 coordinate system and inputting control points, I was having a big problem where no matter what photos I disabled, if I try to generate a model with the entire coastline it would fold like a pretzel and I would get errors of 1000s of meters relative to GCPs.

I even went out and collected more GCPs in areas where the model folded to try to fix the problem, but the solution was simple! I changed the GCP accuracy from 0 m to 0.01 m, and the alignment became perfect.

I just wanted to share in case other people had the same problem.

394

General / Re: de-activate CPU cores?

« on: January 30, 2013, 11:48:04 PM »

You should also be able to go to the photoscan.exe process in task manager and deselect one or more processors (right-click/set affinity...)

395

Bug Reports / Re: Orthoimage reconstruction artifacts in DSMs from 9.0 - photo lines and pits

« on: December 28, 2012, 11:02:44 AM »

I am confused by this. I don't use any gradual selection tools in the point cloud process, and the only filter I use is the one in the Build Geometry... dialog, where I leave it at the default.

I have not spent much more time trying things in 0.9.0 because I am re-flying ~60 sq km every ten days or so and that keeps me plenty busy with the image processing, but I finally put together a second computer that I could try to reprocess some data with for comparison purposes if that would be useful.

I have projects that I completed in 0.8.5, complete with GCPs, and I could reprocess the "Build Geometry" step and compare DSMs if that would help with anything. Unless I don't understand the gradual selection process, I don't think that played a role for me.

This problem is still keeping me from switching to 0.9.0.

396

Bug Reports / Re: Orthoimage reconstruction artifacts in DSMs from 9.0 - photo lines and pits

« on: November 30, 2012, 06:45:48 AM »

Any resolution to this? I am still using 8.5 to avoid artifacts.

397

Feature Requests / ortho and DEM generate in batch

« on: November 21, 2012, 08:14:18 PM »

I think it would be great if I could setup parameters for orthophoto and DSM generation (projection/extent/format/name/etc) in batch for all chunks in a project. Currently DEM generation is very fast for me, but orthoimage generation can take up to 30 minutes, and I am generating DSMs, RGB average images and mosaics for 3 to 4 chunks per project. It would be nice to make that 3-4 hours of compute work happen all in a row without me having to intervene every 30 minutes to keep it on track.

Also have I mentioned... I <3 Photoscan

398

General / Re: Once again about DEM and 3D accuracy

« on: November 21, 2012, 07:27:13 AM »

Regarding test done by surveying a GCP but not using it to control the the PS project, results are as follows. In theory I understand that accuracy should be equal to XY=2*GSD and Z=4*GSD. I find it rather to be in the range XY=1*GSD and Z=2*GSD. When testing in relation to a arbitrary spot shot taken , not a physically identifiable point, results are  better than  XY=2*GSD and Z=4*GSD...

I have had basically the same results as Herman. I fly with a GSD of 10 - 15 cm and a network of ~15 - 20 control points placed around a ~3 km reservoir, and I am generating surfaces that are +/- <25 cm difference over ~90% of the raster cells when compared flight-to-flight and with independent RTK GNSS profiles and aerial and terrestrial LiDAR. I am probably pushing the distance between control points a bit - I do see a little higher error in areas with a longer range between control points - but it is working very well for my purposes (calculating sediment volume).

399

Bug Reports / Orthoimage reconstruction artifacts in DSMs from 9.0 - photo lines and pits

« on: October 31, 2012, 08:06:59 PM »

I originally posted about this in the general forum, and another user has reported the same issues so I thought I would add a note here since it looks like it might be a bug.

When reconstructing in smooth/high (50M polygons for ~250 12 MP photos in my case), photo alignment artifacts show up in areas of high overlap, and it appears that overall alignment with GCPs is worse for the same photoset in 0.9 vs 0.8.5.

Original post has several image examples:

http://www.agisoft.ru/forum/index.php?topic=766.0

400

General / Re: Strange(bad) results: 0.9.0 vs 0.8.5 on 5 sq km project (17 GCP, 221 photos)

« on: October 29, 2012, 09:24:32 PM »

Anyone else have any insight on this? I've gone back to 0.8.5 and I was wondering if there is a way to test my next flight with 0.9.0 without having to manually input control points twice.

But if the problem is due to a project being partly done in 0.8.5 then it seems like that's exactly what I'll have to do - make a project with 0.8.5, upgrade to 0.9.0 and create the same project, then compare.

(also if I am posting in the wrong part of the forum I apologize)

401

General / Strange(bad) results: 0.9.0 vs 0.8.5 on 5 sq km project (17 GCP, 221 photos)

« on: October 19, 2012, 06:08:14 AM »

I have a 50M face model with 221 aerial photos covering about 5 sq km with 17 GCPs. Due to issues I encountered with the surface generated from 0.9.0, I downgraded to 0.8.5 and regenerated the project using the same parameters.

General method was: align photos, generate geometry, select control points, optimize, regenerate geometry, export orthoimage, average image, and DSM. Project datum and control points were entered in WGS84. surfaces were exported in NAD83UTM10.

I generated a surface with 50M polygons with each version, using the same base project (photos and alignment). Then I compared them to each other and to a LiDAR flight flown in April. The results were not good for the DSM generated with 0.9.0. Here's what I found:

DSM surface comparison with LiDAR was much better with 0.8.5. Unchanged surfaces were < 0.25 m different on average. With 0.9.0, elevation values on unchanged surfaces were 8 - 20 meters off, and warped into a frown. See first attached image  (sorry - values in U.S. feet).

DSM comparison between 0.8.5 and 0.9.0 showed that there was a warp on 0.9.0 Reason unknown. What I especially don't understand is why the control points looked ok in the project but not the DSM. Possibly export format issues?

Another thing I noticed was the quality of the DSM was worse in 0.9.0 (see second attached image). I've highlighted two features that I noticed - pits, and lines.

I am not sure if the warping issue is because of the UTM10 export, because the project started as a 0.8.5 project, or because of some inherent issue in 0.9.0. But I am pretty sure that the lines and pits are exclusive to 0.9.0.

Andy

402

General / Re: Question about face count in 0.8.5 vs 0.9.0

« on: October 19, 2012, 03:02:44 AM »

Forgot to mention area. Area is about 5M sq m.

What concerns me from a DSM standpoint is that my budget of vertices/faces seems like it's used up on the rougher surfaces, where in 0.8.5 I ended up with a DSM that had face density better partitioned across the surface - so if I wanted an end-result DSM of ~0.5 m resolution, I could do pretty well with 10 - 20m faces, or 2-4 per sq m. Now to get the same resolution I have to go up to 10 faces/sq m.

403

General / Re: Question about face count in 0.8.5 vs 0.9.0

« on: October 18, 2012, 06:43:17 PM »

top image is 0.8.5. Original msg edited to clarify.

Also I was able to better reproduce the surface (more like 0.8.5) in 0.9.0 by increasing face count from 10M to 50M faces. So it sounds like the face count parameter behaves differently. I think (based on the log) it might never generate the full resolution it did before.

So far I am ok at 50M poly's if I stay on point view.

404

General / Question about face count in 0.8.5 vs 0.9.0

« on: October 18, 2012, 01:50:57 AM »

I am generating orthoimages regularly of a draining lake in a forested watershed. I have been using a face count of 10M to guide DSM creation. I can do up to around 20M at least but I was happy with the product before at 10M. From what I understood - the full number of faces were generated but they were decimated before the final product, which allowed by medium-end machine to handle them (48GB RAM and two 560Ti cards)

In 0.9.0 the quality of  low-relief surfaces is much worse, and it seems like the quality of trees is better. Is 0.9.0 targeting complexity of the surface for face creation while 0.8.5 averaged more evenly when it decimated?

If not, what are other potential causes of this? If so, can we have an option to change it?

The only other change I have made is a new camera mount mount that improved the image clarity - I had some blur on about 20% of images before from engine vibration on the aircraft. Otherwise I think it has to be because of changes from 0.8.5 to 0.9.0.

[edit - added demo images - names correspond to PS version. Top is 0.8.5. The lines in the top surface are logs.]
[edit 2 - just found depth filtering in the new version. regenerating with mild instead of aggressive to see if this is a factor.

405

General / Re: Get rid of black color at the edge of mosaic and make it transparent

« on: October 14, 2012, 01:56:00 AM »

For viewing in Google Earth the TIF can be converted into a superoverlay composed of png tiles at the edges and jpg tiles (better compression) where there are not edges. GDAL supports this (GDAL2Tiles), and there is even a nice parallel-processing GUI utility (Maptiler) written to make it work smoothly and quickly (though not free if you want parallel processing). I've used this to tile up sonar backscatter and hillshade data to serve on Google Earth.

http://www.maptiler.org/