Messages

16

General / Re: which camera for low-altitude aerial photography (for use with PhotoScan)?

« on: April 09, 2013, 12:53:18 PM »

Hello RalfH,

thanks, I was thinking about the S100 because of the 24mm wide angle and it's manual focus option (I assume that autofocus will limit the maximum shooting frequency in the CHDK script). Also the GPS is a plus

17

General / Re: "ground control" pane - "view estimated" button

« on: April 09, 2013, 12:48:31 PM »

Hello Alexey,

I'm sorry, I made a mistake. Of the 8 objects visible on both models, I accidentally misplaced one marker on the model from which I estimated the coordinates (model 2012). This will probably be the reason for the bad optimization in model 2010.

A new question however arises from this:

Is it ok to again (but now with the right marker coordinates) optimize starting from the point cloud which was badly optimized before? Or is it necessary to start from scratch (i.e. start a new alignment from photos)?
In other words, does the quality of the optimization depend on the quality (i.e the deviation from the "real coordinates") of the current point cloud to be optimized?

thanks,
Jan

18

General / Re: "ground control" pane - "view estimated" button

« on: April 08, 2013, 08:14:36 PM »

Hi Alexey,

I'm using 0.9.0 build 1586 (64 bit). The marker accuracy parameter was 0, I've set it to 0.001 meter as you suggested. This seems to give much better results as the model is more or less flat again after the optimization (in contrast with before). There are however still large errors according to the info in the ground control pane (1 error even above 10 meters), but this isn't obvious in the point cloud at first sight (strange). I will let you know when the geometry is built, if the result is satisfactory or not.

many thanks!
Jan 

19

General / Re: "ground control" pane - "view estimated" button

« on: April 08, 2013, 07:08:34 PM »

Hello Alexey,

thank you, this is the meaning I was assuming.

I though have very bad results using this feature (see below):

I have made 2 models of the same area (about 250 m long x 125 m wide), but with pictures taken at different times. Model_1 is based on pictures taken in the year 2010, and Model_2 is based on pictures taken in 2012.

There are 4 aerial targets visible on the 2012 pictures, about 50 to 100 meter distance from each other. Their coordinates are known precisely (as measured with a total station).

There were however no well known aerial targets on the 2010 pictures. Therefore, I looked for 8 objects which are visible on both (2010 and 2012) models, and which didn't move during this period of time. I estimated the coordinates of these 8 objects by placing 8 markers on these objects in the 2012 Model. Via "View Estimated" in the Ground Control panel, I could then retrieve these estimated coordinates. I then used these 8 coordinates as source coordinates on the corresponding marked objects in the 2010 model. After this, I optimized the photo alignment, hereby hoping to make the model of 2010 also georeferenced, and congruent with the 2012 model. However, the result is unacceptable, with errors of more than 10 meters. It is much worse than before the optimization.

What could be the reason for this bad result? 

kind regards,
Jan

20

General / "ground control" pane - "view estimated" button

« on: April 08, 2013, 05:21:43 PM »

What is the purpose of the "view estimated" button in the "ground control" pane.

I want to use it to retrieve coordinates of some objects by putting flags (markers) on these objects in a georeferenced model in agisoft.

Am I getting precise object coordinates with this method?

regards,
Jan

21

General / Re: which camera for low-altitude aerial photography (for use with PhotoScan)?

« on: April 06, 2013, 09:33:19 PM »

after some googling,

I assume that the "Canon Powershot S100" is a good option since it has 24 mm focal length, and is capable of running CHDK scripts.

However, this camera has no intervalometer (or time-lapse) option by default. Is it than still possible to introduce, and to parameterize an intervalometer with a CHDK script in this camera?

Another question:
which camera focal length do you use/prefer with low-altitude areal photography? Does it matter that much, as probably a longer focal length can be compensated by just flying higher above the ground? Or are there other side-effects of this compensation?

regards,
Jan

22

General / Re: Volume measurements

« on: March 28, 2013, 08:42:08 PM »

I've been using the method as proposed by RalfH,

you can use Matlab or ImageJ (open source software) for that

23

General / Re: which camera for low-altitude aerial photography (for use with PhotoScan)?

« on: March 27, 2013, 08:23:42 PM »

Thank you all for the info, I will delve into it...

24

General / which camera for low-altitude aerial photography (for use with PhotoScan)?

« on: March 26, 2013, 06:45:34 PM »

Hi all,

I'm sure some people here make their own aerial pictures with a balloon, kite or drone (and use these as input for the PhotoScan software).

Which camera do you use/recommend?

I currently use a Ricoh GX200, but the intervalometer with this camera is limited to 5 seconds. However, I would like to have a camera with an intervalometer range starting from 1 or 2 seconds. The only one I found with this specification is a Pentax Q10, but this camera has no lens of 24 mm (35 mm equivalent) focal length, which I prefer.

Anybody suggestions?
thank you,
Jan

25

General / Re: markers

« on: July 03, 2012, 06:29:37 PM »

Hi Alexey,

short answer: yes it was ok before saving, no updating control pane did not help

long answer: I think I best explain my work protocol:

*1* I know the local coordinates (x,y,z) of 4 aerial targets. So I place markers on these aerial targets, and give in there local coordinates. So now a (local) reference system is set. Thus far OK.

*2* I additionally place 2 markers on the "foot" and "head" of a shadow produced by a thin pole which is placed perpendicular to a horizontal ground surface. I don't know the positions of these 2 markers, but I assume that the estimates which Photoscan calculates for these coordinates (based on the reference system of the previous 4 markers) are correct. So I give in the estimates of the shadow coordinates as known coordinates.

*3* Based on the production time of the shadow picture, I know the direction to which this shadow points to. With this information and the gps coordinates of 1 target point, I can transform local coordinates of the aerial targets to latlong coordinates in Excel. 

*4* In this last step I change the coordinates of the markers from local to latlong coordinates.

After this last step sometimes the trouble begins (slow performance, floating markers on the 3D model). Even when I delete all the markers completely, and  place them again and fill in their local coordinates again, the markers float again.

PS: Each time I filled in local coordinates or latlong coordinates, I changed the reference system to local or WGS84 respectively, so a dismatch between coordinate values and coordinate system should not be the cause of these problems...

kind regards

26

Feature Requests / Re: Ground control and markers

« on: June 29, 2012, 09:00:33 PM »

Hello Alexey,

I've tried several things, but I only managed to manually grey a marker on individual pictures.

Is it possible to simultaneously grey them all out on each picture on which they occur, and enable (making blue) only those that I want to enable. In one project I have for instance 4 markers, and each marker occurs on more or less 25 pictures (yes a lot of overlap in that region). It still takes a lot of time if I have to manually grey out 20 (from 25) of them for each marker.

thank you,
Jan

27

General / markers

« on: June 29, 2012, 08:43:12 PM »

Hello,

after placing 4 markers on 4 targets on a model (from about 1000 pictures), I refined the position on each of them on individual photos. This was last week. Now I reopen this project again, and all the markers are drifted away from the target objects as viewed from the model. However if I look at the marker positions on each individual photo, they are still correctly placed.

So now I don't know whether PS uses the correct marker positions or not during orthophoto generation

regards

28

General / Re: too much processor consumption?

« on: June 12, 2012, 01:00:54 PM »

I encounter this problem also with other models.

It has something to do with markers. With markers, moving, rotating, zooming, saving the model goes very slow (full processor consumption),

but when I delete the markers, everything goes fast again (low processor consumption)

I can't find a reason why the presence of markers should do this.

could this be a bug?

Does anybody else encounters this problem?

update:
I have not always this problem. With some models with markers I don't have this problem. The number of faces is always 200k

29

General / Re: too much processor consumption?

« on: June 07, 2012, 08:34:24 PM »

Hi Wishgranter, thx for the input

I'm using ubuntu 10.04 LTS, so I guess I cannot benchmark my system (with this program).

Anyhow I don't think it is driver related as I've also a previous version of this project file, which is the same except it has only three markers (in local coordinates), and this project file is going fine in photoscan.

I must say that during the production of the 'slow' project file, I changed from local coordinates to latlong coordinates. I needed to first setup a local coordination system to provide the necessary information for setting up a WGS84 coordination system. Maybe here went something wrong (during the change of the coordinate system).

I will try again and let it know if I encounter the same problem again.

30

General / Re: too much processor consumption?

« on: June 07, 2012, 11:04:59 AM »

Hello Alexey,

The model has 199577 faces; 9 markers were already placed,

during the initial placement of the markers a few weeks ago I did not have this problem.

Even only moving the mouse without clicking anything leads to 100% processor consumption of all my processors. When I let the mouse cursor rest again, the processors fall back to background level.