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

Pages: [1] 2 3 ... 16
1
Hi HarryTwomey,

make sure you have project where the coordinates of photos  and markers are within the IRENET 95 bounds....

for example I imported your foto coordinates in Meta 1.5.2 in WGS84 datum or Irenet 95 (equivalent)

Code: [Select]
47_EP-11-31756_0022_0107.JPG -7.681338 52.749182 265.181
and when I ranform to Irenet 95/ITM + Malin head head I get

Code: [Select]
47_EP-11-31756_0022_0107.JPG 621513.954020 666505.171191 208.568732
Should work if you have your geoid tif in coorect geoids folder of Metashape and use attached prj file....

2
Hello Wotjas,

it seems the required bands for CIR composition have to be normalized to 1 ( i.e. dividing by 65535) before using them in raster calculator...

see attached screen capture...

3
General / Re: delete deactivaded cameras
« on: May 08, 2019, 11:04:07 AM »

4
General / Re: How to select disable cameras.
« on: April 30, 2019, 09:10:23 AM »
Hi 8ashe,

to create a list of all disabled cameras in chunk and remove them, use following code:
Code: [Select]
chunk = Metashape.app.document.chunk

cameras_disabled = [camera for camera in chunk.cameras
                            if camera.enabled == False]

chunk.remove(cameras_disabled)

Hope this can help you,

5
Feature Requests / Re: Latvia Geoid
« on: April 17, 2019, 11:21:41 AM »
Hello,

you can create a compound CS adding the following tif representing the LV 14 geoid...

Compound Coordinate System: LKS92 / Latvia TM + geoid LV 14
Projected Coordinate System: LKS92 / Latvia TM (EPSG::3059)
Linear Units: metre (EPSG::9001)
Projection Method: Transverse Mercator
    Latitude of natural origin: 0
    Longitude of natural origin: 24
    Scale factor at natural origin: 0.9996
    False easting: 500000
    False northing: -6000000
Geographic Coordinate System: LKS92 (EPSG::4661)
Angular Units: degree (EPSG::9102)
Geodetic Datum: Latvia 1992 (EPSG::6661)
Ellipsoid: GRS 1980 (EPSG::7019)
Prime Meridian: Greenwich (EPSG::8901)
Vertical Coordinate System: Latvia 2014
Vertical Units: metre (EPSG::9001)
Vertical Datum: Latvia 2014

Aatached is tif file

6
Hi Harry,

in Metashape, to create the compound CS with provided grid file, just follow the steps 1 to 7 highlighted in attached screen captures….

Once you click OK in step 7, you will have a tif geoid file stored in your users AppData\Local\Agisoft\Metashape Pro\geoids folder….(in case you used install for current user only option). This tif file will be used in your COMPD_CS to transform elipsoidal height to MSL height or ortho HT....

Hope this helps,


7
Harry,

i recalculated the transformed coordinates of your photo set and now I get a different result in height as my OSGM15_Malin.tif file was originally a little off…

The latest tif I sent is correct...

Maybe now it concurs with your results!

8
Harry,

I am not familiar with GridInquest but maybe interpolation used is different or actual original grid file used is not same?

The Malin grid file I downloaded from http://www.isgeoid.polimi.it/Geoid/Europe/Great_Britain/Great_Britain_OSGM15.html has points spaced about every 1.3 km  over Ireland…. so the actual interpolation method matters here….

Attached is Zip file of Ascii grid file downloaded from site as well as corresponding tif generated from Metashape….

Note that Malin Head geoid correction has accuracy of about 2.3 cm over Ireland….


9
Harry,

i downloaded the Malin Head geoid from http://www.isgeoid.polimi.it/Geoid/Europe/Great_Britain/Great_Britain_OSGM15.html and from grid file created a tif containing the geoid height or undulation for Malin Head… see attached tif file….

And in Metashape I configured a custom compound  CS for IRENET95 ITM + Malin Head geoid height adding the above mentioned tif file….

Now your photo centers transformed to IRENET95 ITM + geoid Malin Head is in attached text file.

Please check if transformation is correct,

Cheers,




10
Python Scripting / Re: Number of Cameras in version 1.5.2 vs 1.4.5 API
« on: April 04, 2019, 11:56:04 AM »
Hi Alexey,

thanks for prompt reply... I am now inserting the camera.type test in my code. However now I get an indentation use error:

2019-04-04 02:51:26   File "C:/Users/paul.pelletier/AppData/Local/Agisoft/Metashape Pro/scripts/test.py", line 29
2019-04-04 02:51:26     quality = float(camera.meta['Image/Quality'])
2019-04-04 02:51:26                                                 ^
2019-04-04 02:51:26 TabError: inconsistent use of tabs and spaces in indentation

Attached is my python script.....

Maybe you can help with this, must be silly error

Update,

I was able to fix the indentation problem by copying on indentation from line to line.... Problem resolved

11
Python Scripting / Number of Cameras in version 1.5.2 vs 1.4.5 API
« on: April 04, 2019, 09:54:58 AM »
Hello,

I am using a script that loops over all cameras in a chunk to extract information... This script works well in 1.4.5 and 1.5.2... However I am noticing sometimes that if I open a PhotoScan project in 1.5.2 then the API detects more cameras than actually present in project....

For example I have a project with 118 cameras and if in 1.4.5 I do following command len(chunk.cameras), I get correct result, 118....
However, opening same project in 1.5.2, the same command returns 168 instead of 118... It adds 50 empty cameras to chunk....

Is this a bug^?

Please see attached logs for 1.4.5 and 1.5.2 versions...

12
Python Scripting / Re: Script using strict volumetric masking
« on: March 24, 2019, 02:26:25 PM »
Thanks Alexey,

so in my script for version 1.5.2, I added

chunk.buildDepthMaps(quality=PhotoScan.HighQuality, filter=PhotoScan.MildFiltering, reuse_depth=True)

before chunk.buildModel….

however, please see my post on increased processing time for such modelling in current version compared to 1.4.5

13
General / Processing times version 1.5.2 vs 1.4
« on: March 24, 2019, 01:22:05 PM »
Hello all,

i am comparing processing a full body model using 120 photos in versions 1.5.2 and previous 1.4.5..... on same computer

2019-03-24 02:56:47 Platform: Windows
2019-03-24 02:56:47 CPU: Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz (laptop)
2019-03-24 02:56:47 CPU family: 6 model: 58 signature: 306A9h
2019-03-24 02:56:47 RAM: 16.0 GB
2019-03-24 02:56:49 OpenGL Vendor: NVIDIA Corporation
2019-03-24 02:56:49 OpenGL Renderer: GeForce GTX 670MX/PCIe/SSE2
2019-03-24 02:56:49 OpenGL Version: 4.6.0 NVIDIA 417.01

I am generating a mesh from depth maps in high quality with strict volumetric masks on….

For version 1.4.5 the time to generate  mesh from depth maps is 49 min.

For version 1.5.2 the time to generate  mesh from depth maps  is  1 h 42 min.

I realize the mesh from depth maps algorithms have changed but the considerable increase in processing time is concerning….

Hoping to get your thoughts on this issue….

Attached are processing logs from both versions and screen shot of both models side by side….

Seems model 1.52 is a little better but substancial increase in processing time does not seem to justify such marginal quality improvements….

Note that in both cases following tweak was used in preferences/advanced :  main/dense_cloud_max_neighbors  60

14
Python Scripting / Script using strict volumetric masking
« on: March 23, 2019, 11:57:37 PM »
Hello,

in 1.4 version, I was using a script to generate model from depth maps with high quality and strict volumetric masking on…

The code line was:

chunk.buildModel(surface=PhotoScan.Arbitrary, interpolation=PhotoScan.EnabledInterpolation,  source=PhotoScan.DepthMapsData, quality=PhotoScan.HighQuality, volumetric_masks=True, reuse_depth = True, keep_depth = True, vertex_colors = False)

Now in 1.5.2, I get invalid keywords for quality and reuse_depth parameters….

Why are these parameters no longer available? These keywords were avalable in 1.5.0 API reference...

15
General / Re: Systematic Z Error in Proportion to Altitude (Phantom 4 RTK)
« on: February 24, 2019, 12:59:07 AM »
Hello Domingo,

yes please send the dat, and would certainly have a look at it… If you measures a few GCPs from the base station, then we can have an independant check on the quality of airborne RTK positions….

Pages: [1] 2 3 ... 16