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 - Isaac H. E.

Pages: 1 [2] 3
General / 16 bit Orthomosaic to GoogleEarth KMZ
« on: August 08, 2019, 04:27:51 PM »

Hi All,

I'm trying to export an Orthomosaic produced in Metashape 1.5.1, the original images were 16 bit TIFF and I'm now trying to export to GoogleEarth KMZ file format.

To visualize the 16bit within Metashape (at first all the images were all balck) I went to "Set brightness..." within "Tools" menu and in there I pressed the "Auto" button to stretch the histogram.

Within MetaShape I can see a nice colour representation in all the imagery but when I export the Orthomosaic to Google Earth KMZ I get a Black "patch" within Google Earth (16 bit color space being rendered in 8 bit)

Any ideas how I can get a nice image in Google Earth?

Many thanks


General / Re: Building jaggy edges, how to get rid of them
« on: June 26, 2019, 04:18:09 PM »

Hello Alexey,

Good evening, may it be that the response I was looking for is contained in the following paper?

Any plans to implement such an algorithm?



General / Building jaggy edges, how to get rid of them
« on: June 12, 2019, 01:45:30 PM »
Hello Everyone,

I'm trying to create a high resolution (5cm GSD) ortomosaic out of a few hundred images flown at 120m AGL with a DJI Mavic 2 Pro.

I get a reasonably looking multi million point dense cloud that I use to compute a DSM of my area of interest.

Then I compute an orthomosaic based on the DSM (trueortho) which leads to a beautifully looking result everywere excepte on the edges of the buildings where I get jaggy edges that render the orthomosaic pretty much useless as it is.

I know I can recompute the orthomosaic using a DTM instead of a DSM but then I would have to invest time lying polígons to manually choose which pictures are best looking, something I would like to avoid.

Is there a way to filter out the façade points out of the high density point cloud (it seems that the noise on the edge of the buildings mostly comes from poorly matched points on the facades)?

If my question does not go in to the right direction to solve my jaggy building edges problem and you have a suggestion I have bested interest in hearing your thoughts!


Hello Alexey,

I would like to to use the exterior orientation (EO) (XYZ+OPK) provided by a third party post processing INS (GNSS+IMU) software of a group of images part of a photogrammetric block.

Is it possible to "force" the EO information of each image loaded in to MetaShape to avoid having to rurn MetaShape "Align Photos..." procedure?

Best Regards


General / Automatic license deactivation on MetaShape exit
« on: March 13, 2019, 03:04:27 PM »
Dear Agisoft support team,

I happen to (mainly) use MetaShpae in two different computers my laptop and my ATX workstation unfortunately I quite often forget to deactivate the licenses from the machine I'm leaving, is it possible to configure in some way MetaShape 1.5.1 to automatically check out the license every time the end user closes the GUI?

Many thanks

Best regards


General / Re: EGM2008 geoid reprojected to ETRS89
« on: February 24, 2018, 01:48:45 AM »

Nevermind, I already found the way of creating my own geoids, case closed.

Best regards.


General / Re: EGM2008 geoid reprojected to ETRS89
« on: February 23, 2018, 02:24:38 PM »

The following Dropbox link points at the folder were I have the geoid prepared:

It is a subset of the egm2008-1.tif just covering Catalunya and shifted +0.5951 metres upwards.

The Authority is ICGC (Institut Cartogràfic i Geològic de Catalunya)

The current metadata:

Code: [Select]

UPPER LEFT X=0.0452233333
UPPER LEFT Y=42.9100696667
LOWER RIGHT X=3.4118899711
LOWER RIGHT Y=40.4934030208
WEST LONGITUDE=0° 02' 42.8040" E
NORTH LATITUDE=42° 54' 36.2508" N
EAST LONGITUDE=3° 24' 42.8039" E
SOUTH LATITUDE=40° 29' 36.2509" N
UL CORNER LONGITUDE=0° 02' 42.8040" E
UL CORNER LATITUDE=42° 54' 36.2508" N
UR CORNER LONGITUDE=3° 24' 42.8039" E
UR CORNER LATITUDE=42° 54' 36.2508" N
LR CORNER LONGITUDE=3° 24' 42.8039" E
LR CORNER LATITUDE=40° 29' 36.2509" N
LL CORNER LONGITUDE=0° 02' 42.8040" E
LL CORNER LATITUDE=40° 29' 36.2509" N
PROJ_DESC=Geographic (Latitude/Longitude) / WGS84 / arc degrees
PROJ_UNITS=arc degrees
COVERED AREA=75149 sq km
PIXEL WIDTH=0.01667 arc degrees
PIXEL HEIGHT=0.01667 arc degrees
MIN ELEVATION=47.612 meters
MAX ELEVATION=55.123 meters
SAMPLE TYPE=32-bit Floating Point
PHOTOMETRIC=Greyscale (Min is Black)
SAMPLE_FORMAT=Floating Point
ORIENTATION=row 0 top, col 0 lhs
PIXEL_SCALE=( 0.0166666665238, 0.0166666665238, 1 )
TIEPOINTS=( 0.00, 0.00, 0.00 ) --> ( 0.0452233333, 42.9100696667, 0.0000000000 )
MODEL_TYPE=Geographic lat-long system
RASTER_TYPE=Pixel is Point
VERT_DATUM=None Specified

Before creating the PS geoid it should be transformed from WGS84 to ETRS89 datum.



General / Re: EGM2008 geoid reprojected to ETRS89
« on: February 23, 2018, 12:44:14 PM »
Hello ruyi7952,

I'm the author of that article at, my problem has nothing to do with datum conversions, my question is about the resulting TIFF file that PS will use from geoids folder, shall the TIFF file have some sort of specific format? I can see that in the egm2008-1.tif file the EXIF specifies VERT_DATUM["EGM2008 geoid",2005,AUTHORITY["EPSG","1027"]] in the ImageDescription field, is all what it takes to use a TIFF withi PS?



General / EGM2008 geoid reprojected to ETRS89
« on: February 23, 2018, 03:11:44 AM »

I would like to use a croped, reprojected and vertically shifted version of the EGM2008 (defined for WGS84) geoid with the ETRS89 datum, is there any special instructions I should use to create a valid tiff file to be placed in PS geoids directory?

Many thanks


Feature Requests / PS pop up confirmation windows
« on: February 18, 2018, 08:13:11 PM »

I would appreciate if every time PS needs confirmation for something (ok / cancel or yes / no or ...) the pop up window would appear centred in my mouse cursor instead of the centre of PS window. By centering the pop up in to the cursor you would make me slightly more productive.
Note that there would be no risk of accidental double click issues because the pop up buttons would be positioned slightly below the cursor requiring a small travel to reposition the cursor over either confirmation button.



Feature Requests / Re: automatic shutdown
« on: February 18, 2018, 07:57:27 PM »
Thanks for suggestion.
Currently computer shut down could be performed in Pro edition using Python scripts.

Thanks Alexey your response is very much appreciated, being said that there are many of us that either don't want to learn Python or do consider the proposed method as too clumsy, I really think that should be in the GUI so that all users, knowledgeable or not, can enjoy such a feature that, in the end, is going to save them money.

Thanks for listening and for your continued support.


Feature Requests / Feature request, Batch Power off option additon
« on: February 18, 2018, 01:16:17 PM »

Would it be possible for you to add a "power off" option in to the Workflow / batch process window?

This would enable the end user to program a batch and leave the computer processing overnight without wasting unnecessary energy / money.


Bug Reports / Re: geoid sign seems to be wrongly applied
« on: September 12, 2017, 03:03:40 PM »
Hi Yoann,

You don´t really want to see the GNSS altitude in the EXIF metadata, the problem with the unfiltered GNSS altitude is that it is far more noisy than the altitude from the barometer, it is more accurate but less precise, ideally we should get a fix from DJI algorithms so that we can get 5-10 metres accuracy with high barometric precision (one good example of how this works in a real life product is handheld GNSS receivers from Garmin).


Bug Reports / Re: geoid sign seems to be wrongly applied
« on: September 11, 2017, 02:09:46 PM »
Hi rossnixon,

DJI drones mix the GPS altitude with their on board barometric altimeter to produce a smooth altitude output... there seems to be something wrong in the way they do it, this problem has nothing to do with ionospheric activity (CMEs, scintillation, ...) I have worked for 7 years in the GNSS industry and I can tell you that the largest height error you are going to see when operating in open sky, like I was doing, is 5 to 10 metres (in a small patch antenna). DJI seems to be using some sort of algorithm to track elevation changes because I have made 5 flights in totalover the same area, two of the flights were performed the 6th of Spetember and 3 of them the 10th. The altitudes of the flights performed the same day agree very well (high precision) between battery changes but the height of the flights performed during different days displays 124 metres of difference.


Bug Reports / Re: geoid sign seems to be wrongly applied
« on: September 11, 2017, 01:58:53 PM »
Hi Yoann,

No, unfortunately no, the only way I can imagine to "solve" the height variations would be to manually apply an offset to every EXIF height tag, this can be automated by taking a picture right at the beginning of the flight or right at the end with the drone landed, then search the correct ellipsoidal or ortometric height for that point and apply the difference to all the pictures, in fact there is a web site that does exactly that unfortunately they charge money for the processing... I'm not aware of any free solution.

Maybe would be a good addition to PS because if I'm not wrong 50% of the end user drone market is owned by DJI and all their drones suffer this same issue.


Pages: 1 [2] 3