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 - JanS

Pages: [1] 2
1
General / Re: Best way to roughly constrain alignment/geometry?
« on: May 05, 2012, 09:42:35 AM »
Hi,

Since you don't seem to have that many photos, you could try to assign each photo relative coordinates e.g. (0,0) , (40,0),... if you have some idea on the distance between photos within and between flight lines. You can try using these coordinates as ground control to have PhotoScan better pre-order the images before point cloud construction.

2
General / Re: Matching a large number of photos in PScan pro
« on: April 30, 2012, 01:08:02 AM »
Hi Alexey, Paulov,

Thanks for your comments. This post is from last year, so possibly current Photoscan versions are faster doing the processing. We eventually split everything up in 3 chunks, the largest one with about 4000 photos. I didn't quite remember the processing time, but it was multiple days, mainly due to estimating scene structure. Our PC was a core i7-2600, so not that much slower than your model unless this step also relies on GPU.

After that project, we didn't process any data set close to this size. On typical datasets of 500-1000 photos the geometry reconstruction takes most of the time.

3
Feature Requests / Re: Ground control and markers
« on: March 27, 2012, 01:29:58 AM »
Thank you Alexey,

It seems we had the same ideas about the markers. I indeed only tested them in 0.8.4.
Does your optimization algorithm have a protection against overfitting (i.e. if too few markers are used) and - related to this - any suggestions on how many markers/on how many images are required for reliably fitting the camera model?

Keep up the good work,

Jan

4
Feature Requests / Ground control and markers
« on: March 25, 2012, 01:00:21 AM »
Hi,

In our last projects, using v0.8.4 we did some experimenting with the ground control settings. While certainly already functional, I think there are some improvements that can make this feature much more useful. Here are some comments and recommendations.

- placing GCP's (markers) in itself works well, zooming in and out is fast and it helps a lot that markers can be seen on the model as well as on the photo's
- as I understand now, when adding a marker before the model geometry is constructed, this markeris only on one photo. When adding it after model construction, it is also added on every photo where it is visible. This is a nice feature, but it can cause a lot of work to place every point right. e.g. in our last UAV project, overlap was between 65 and 85% so every marker was on between 10 and 15 photo's. We typically have between 10 and 20 markers per flight... My suggestion is to slightly modify the behavior as follows: when one adds a marker on a photo, it is automatically added on every other photo, but as a 'preliminary' or 'temporary' point, e.g. with a grey flag instead of a blue flag. When one opens a photo with a temporary point and moves the point, it becomes a 'definitive' point. Photoscan would then only use the 'definitive' markers for calculations, while the temporary points are used to assist the user.
- the use of markers as tie points to optimize the point cloud/camera calibration seems a very strong feature to me. Calibration parameters supplied by UAV manufacturers may not be that reliable and/or not entirely compatible with Photoscan. As I understand this feature now, there may however be an issue with the processing chain: 1. align photos, 2. build geometry as it is much easier to place markers, 3. optimize point cloud which detroys the model (am I right?).
To avoid building the model twice, it could help if PhotoScan could place preliminary markers on photo's directly after camera alignment. If a user enters or imports reference X,Y and Z coordinates, an initial estimate of the position on the photo could be made assuming a flat terrain. Now users can position the markers right (not necessarily all of them), optimize the point cloud and then build the geometry.

Best regards,

Jan

5
General / Re: Agisoft PhotoScan 0.8.5 pre-release
« on: March 22, 2012, 09:05:49 PM »
Hi Alexey,

Thanks for the reply. I think you are right and it's better indeed to leave it as is. We actually raraly/never use Belgian datum for geographic degrees. It's either lat/lon in WGS84 (GPS positions) or Belgian datum as projected (Lambert). There's plenty of tools around that do this conversion for us so for us there's no need to include datum conversions in PhotoScan reprojections.

Best regards,

Jan

Hello Jan,

We've checked the coordinate conversion from Belge 1972 to Belgian Lambert 1972 (Datum Reseau National Belge 1972) and the result was the same as in free coordinate converters available on the web.

Could you please tell us how is it possible to reproduce or detect the mistake, since PhotoScan doesn't use GDAL?

6
General / Re: Agisoft PhotoScan 0.8.5 pre-release
« on: March 17, 2012, 08:59:14 PM »
Hi Alexey,

Thanks for the follow up.

It was build 1398 of March 1st. Meanwhile I can confirm that on the same set of images, v0.8.4 has no problems in photo alignment.

The projection system I was referring to is the Belgian projection 31370. It's definitely in your list, but if derived from GDAL the towgs84 parameters are often wrong. Instead of:
+towgs84=106.869,-52.2978,103.724,-0.33657,0.456955,-1.84218
they should be
+towgs84=-106.869,52.2978,-103.724,0.33657,-0.456955,1.84218

Jan

Hello Jan,

Could you please specify which build of 0.8.5 you were testing?

And regarding projection system - what's its EPSG code?

7
General / Re: Agisoft PhotoScan 0.8.5 pre-release
« on: March 16, 2012, 01:17:14 PM »
Hi all,

From our last UAV project, processed with 0.8.5 beta I can confirm that the photo alignment does not work as expected. Using the GPS positions as initial values produced a lot (>50%) of unaligned photos. The generic matching algorithm matched all photos.
The final DEM was lower in quality than what we normally expect, but this may also be partly due to the type of area and illumination conditions (very low sun).
So until you have fully debugged the new algorithms, I'd prefer the option to also use the old algorithms for photo matching/DSM construction when you release 0.8.5.

Otherwise, I like the new features being implemented.

Some thoughts about projection systems: it seems as if they're 'hard coded' into the exe. Maybe useful if you could put them in a text/xml file that we can edit so that we can include our own projection systems. For example, the default Belgian projection system has wrong parameters in the Proj4/GDAL library...

Best regards,
Jan

8
General / Re: Agisoft PhotoScan 0.8.4 pre-release
« on: October 19, 2011, 01:03:04 AM »
Hi all,

Does anyone else experience a reduced responsiveness of the GUI when opening large project files? We have some projects of 600+ photos that load well in 0.8.3, but seem to stall in 0.8.4.

Best regards,

Jan

Pre-release version of Agisoft PhotoScan 0.8.4 is available for download.

This pre-release is considered as unstable and is not recommended for production use.

Please use the links below for download:

Agisoft PhotoScan Standard edition
Windows 32 bit
Windows 64 bit
Mac OS X
Linux 64 bit

Agisoft PhotoScan Professional edition
Windows 32 bit
Windows 64 bit
Mac OS X
Linux 64 bit

Please let us know if you have any problems using this version.

Please post problems and/or questions concerning other PhotoScan version in separate topics.

This topic will be removed when the final 0.8.4 version is released.

Note
Project files created with 0.8.4 version can't be opened with earlier versions.

9
Camera Calibration / skew coefficient
« on: September 25, 2011, 08:09:20 PM »
Hi,

In the Agisoft Lens manual and website, there is a good description of all the parameters except for the skew that is not mentioned but is part of the xml. Is this parameter actually used and if so, is it possible to update/post the equations (see appendix in the manual)?

Many thanks,

Jan

10
Bug Reports / Re: export orthophoto, bounding box and pixel size
« on: August 31, 2011, 12:05:25 PM »
Thanks Alexey,

This would certainly help us since many of our clients have requirements for exactly defined pixel sizes.
I understand now that the current implementation is not a but, although changing it would make PhotoScan behave more conform to mainstream GIS/remote sensing software (PCI, ArcGIS, ERDAS and the like)

Best regards,

Jan

11
Bug Reports / export orthophoto, bounding box and pixel size
« on: August 27, 2011, 11:45:53 PM »
Dear forum,

Export orthophoto seems to have some issues resulting in slightly smaller pixel sizes than entered in the textbox.

e.g. when I enter 1 m as pixel size and take care the bounding box min/max limits are also rounded to 1 meter, the resulting pixel size is 0.999899 m. Bounding box margins are also slightly off.

When instead I use the max. image size textbox instead of pixel size textbox, I can avoid the issue. e.g. I want a 1 m pixel size and have an area from 536200 to 537200 (1000m) in X and 25600 to 26000 in Y (400 m), I enter 1000 m as max image size and the resulting image has exactly 1 m pixel size. In this case however, the resulting image goes from 25600 to 25999 in Y (399 instead of 400 pixels).

Note: in my case, both the model and the export coordinates were in UTM 31 N.

Best regards,

Jan

12
Bug Reports / Re: model export to obj, coordinates truncated
« on: August 17, 2011, 12:46:15 AM »
Hi jan,

I have encountered the same problem. You can either use the meshlab approach or use local coordinates. You may also encounter the binning of one set of the coordinates into 10 m intervals with high density models in projected geographic coordinates (UTM).  Alexey indicated this would be solved in the most recent release but I havnt had a chance to test it out yet.

Hi Matt,

Thanks for the reply. Local would indeed be another option, but we want to use the model for showing in CAD/GIS software so we'd have to apply the matrix rotation from local to UTM in postprocessing. I was using 0.8.3pre-release.

Best regards,

Jan

13
General / Re: Agisoft PhotoScan 0.8.3 pre-release
« on: August 17, 2011, 12:37:42 AM »
Hello Jan,

Operations with photos are slow because GUI is updated after every operation with photo. Performing scripts from the command line should remove this slowness.
We are considering the implementation of GUI block function that also could solve the problem if scripts are run from GUI. Also Python functionality would be extended by time and I think it will include setting the camera view direction and position.

Hi Alexey. That's exactly what I was hoping for. Greetings, Jan

14
Bug Reports / model export to obj, coordinates truncated
« on: August 14, 2011, 11:29:21 PM »
Hi,

When I export my model in UTM coordinates to .obj, all X and Y coordinates (not Z) are truncated to integer values (rounded off at the meter). This does not occur when exporting to .ply (so I have a work around using Meshlab). It also doesn't occur when exporting the points to .obj.

Best regards,

Jan

15
General / Re: Agisoft PhotoScan 0.8.3 pre-release
« on: August 13, 2011, 02:54:27 PM »
Python support is greatly appreciated. It allowed us to programmatically add/remove photos and to copy transformation matrices between chunks. Combined with matrix multiplication, this gives a good programmatic control of alignment.

Some comments and requests:
- all operations on individual photos are rather slow (add/remove/select, en/disable), certainly for larger chunks (1000+ photos). It would help if we could provide a list of photos to each function e.g. doc.chunk(1).removePhotos(myList)

- camera control: get/set view X,Y,Z and view directions. Can be powerful combined with export in local coordinates since it gives fine control over the view. Alternatively an option to view and set the view from the GUI would be cool as well. Maybe on the status bar?

Keep on the good work,


Jan

Pages: [1] 2