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

Pages: 1 2 [3] 4 5 ... 28
General / Re: Dense Cloud - Where do the rings come from?
« on: July 23, 2018, 05:08:24 PM »
Like SAV said it's an overlap issue. So to answer your question whether or not it can be resolved; yes, just fly with a higher overlap.
If you feel that the overlap is insufficient on the borders of your project area (because of these circles) simply increase your project area so that you have an overshoot above the actual project area.

General / Re: Major Speed and memory managment overhaul needed
« on: July 22, 2018, 03:29:29 PM »
Why do you process the TIFFs and not the high quality JPEGS? There are numerous topics on this that shows that using TIFFs (except greyscale thermal) does not necessarily yield better results.

Though the increased size for the TIFFs will use more memory while processing.

You'll want to place the GCPs on the corner of the project site. From emperical testing I can see that a gcp has a usable radius of around 200m.

From the manual:

Max angle (deg)
Determines one of the conditions to be checked while testing a point as a ground one, i.e. sets limitation
for an angle between terrain model and the line to connect the point in question with a point from a
ground class. For nearly flat terrain it is recommended to use default value of 15 deg for the parameter.
It is reasonable to set a higher value, if the terrain contains steep slopes.
Max distance (m)
Determines one of the conditions to be checked while testing a point as a ground one, i.e. sets limitation
for a distance between the point in question and terrain model. In fact, this parameter determines the
assumption for the maximum variation of the ground elevation at a time.
Cell size (m)
Determines  the  size  of  the  cells  for  point  cloud  to  be  divided  into  as  a  preparatory  step  in  ground
points classification procedure. Cell size should be indicated with respect to the size of the largest
area within the scene that does not contain any ground points, e. g. building or close forest.

Is this clear to you?

JMR is absolutely correct. You will introduce relative distortions that won't necessarily show up as visual mistakes in the Orthomosaic. They'll only appear once you have some reference data to compare it with.

General / Re: Ram usage on Orthomosiac stage
« on: July 06, 2018, 11:00:19 AM »
Before you get to the orthomosaic stage, you would have to build a mesh though. At an estimate, in your case you'd need about 800GB for that step. I base that on a Medium Quality model with 10,000 photos of 12 Mpx requiring 40GB.
Seeing as the topic starter mentioned he wants help with processing a orthomosaic chunk this is not really relevant.

After all you only need a surface of arbitrary resolution to project the images onto to create a orthomosaic. Therefor the amount of polygons in the mesh (or DEM surface) does not matter for creating the orthomosaic.

For instance you can create a lowest quality dense cloud with the minimal amount of point density and then create a surface from that point cloud. This greatly reduces the processing time but a too low point density might give issues in areas with large height variations.

General / Re: Slow alignment on new machine
« on: June 18, 2018, 06:15:18 PM »
I doubt photoscan scales properly with 24(!!) cores.. Even utilizing 12 cores seems to be a hassle sometimes..

So even though you have 24 cores, they're only running at 2 GHz with a turbo frequency of 3GHz (which is hard to maintain constantly). 2 GHz is rather slow even though there are 24 of them. If the software doesn't utilize the hardware properly, like in this instance, you'll end up having slower performance than a higher clocked i5 or i7!

Also having 4 graphic cards is also something that does not scale properly. You'll definitely not gain any linear performance boost by adding four. We at least did not see any increase in performance when adding a third GPU to our system.
The GPU's are also not used during the alignment step so you will only see any performance gain during the Build Depth Maps stage of the Build Dense Cloud step.

Is there a reason why you chose this particular set up? Is this system build specifically for Photoscan processing?

General / Re: Which projection or EPSG does PhotoScan uses ?
« on: June 18, 2018, 05:51:44 PM »
The default selected EPSG is 4326; WGS84 Lat/Lon

General / Re: slow processing, workstation issue?
« on: June 12, 2018, 08:03:58 PM »
As outsider mentioned, adding a second GPU will not yield the desired results. Mainly because the GPU is only used during 1 step of the Build Dense Cloud stage, the calculation of the Depth Maps.

The CPU you have is a 2 GHz chip with turbo up to 2.5 GHz. This is by far the biggest bottleneck of your system. You have plenty of ram and a GTX1080 is relatively fast compared to most of the other GPUs available within a reasonable price range.

As outsider also mentioned; be very cautious of which E5 Xeon you'll be buying. If you download the software called 'CPU-Z' you can see the make and model of your motherboard in the Mainboard tab of CPU-Z.
If you tell us the information about the motherboard we can help you choose the correct CPU.

General / Re: reuse depth map
« on: June 12, 2018, 02:36:15 PM »
Hi Ugo,

Unfortunately not as the depth maps are tied to the input resolution chose at the build dense cloud step. I.E. medium means the images are downsized by a factor of 4 and for high this is a factor of 2, so these files will not match up hence you cannot reuse them.

General / Re: axis of Z change
« on: June 06, 2018, 06:01:53 PM »
Your coordinates are decimal degrees which will not work with WGS84. You'll need an UTM zone for your specific project location.

General / Re: Field Calibration
« on: February 28, 2018, 07:06:09 PM »
The problem with this method is that weather conditions will change the intrinsic values of the camera model and lens parameters, making your first calibration set less valuable.

General / Re: Orthomosaic deformation of images
« on: February 22, 2018, 07:28:35 PM »
Seems to me like an alignment issue.

If the cameras that cover this region are not properly aligned, they will cause a displacement in the Orthomosaic because the positioning and or orientation of those cameras is 'off' compared to the flat plane.

General / Re: Importing DEM to improve geomtry accuracy
« on: February 14, 2018, 03:15:14 PM »
The DEM overwrites the DEM that's already generated in the report or is simply being used as the DEM to project the images onto. That step happens at  Build Orthomosaic, where you can choose which Surface to use (Mesh or DEM).

The order of steps is;
1. Align images in proper coordinate system
2. Geo-reference the project either by geotagged images or GCPs
3. Optimize the tie-points with the info from step 2
4. Import external DEM in the same coordinate system
5. Build Orthomosaic with Surface set to DEM

General / Re: Large Error in GCPs
« on: February 14, 2018, 03:10:22 PM »
Isnt the disabled option of alignment the best choice as far as accuracy goes vs generic or reference? Although it does take much longer.
Generic down-samples the images before trying to find matches in the tie-points. This speeds up the alignment because Photoscan will know which images are taken consecutively to each other which speeds up the estimating camera locations step.
I'd only advice to use disabled mode either with small data sets (<100 photos) or data sets that will not properly align on Generic mode.
If you have geo-tagged images it's best to use reference mode. In this mode, Photoscan will use the coordinate information to predict which images are consecutive.

Pages: 1 2 [3] 4 5 ... 28