Forum

Author Topic: Altitude used in Processing UAV (DJI Phantom 4 Pro)  (Read 21678 times)

Alexey Pasumansky

  • Agisoft Technical Support
  • Hero Member
  • *****
  • Posts: 14927
    • View Profile
Re: Altitude used in Processing UAV (DJI Phantom 4 Pro)
« Reply #15 on: March 27, 2018, 08:21:34 PM »
Hello MIG-29,

Can you please type in the following command to the Console pane in PhotoScan (while the project with the DJI images is active and provide the output)?

Code: [Select]
PhotoScan.app.document.chunk.cameras[0].photo.meta
But basically I think that the following information should be repeated: DJI is storing two altitude values in the XMP meta-data: Absolute altitude (I assume it's a barometric altitude) and Relative (this one seems to be height above take-off point). Also they are copying one of these values to GPSALtitude tag in EXIF - and it's Absolute altitude. Other applications (providing that that have some level of integration with DJI firmware) might be reading information from the XMP and also use the coordinates of take-off point or base station to calculate the valid altitude.
Best regards,
Alexey Pasumansky,
Agisoft LLC

jazzyj

  • Jr. Member
  • **
  • Posts: 87
    • View Profile
Re: Altitude used in Processing UAV (DJI Phantom 4 Pro)
« Reply #16 on: March 27, 2018, 09:53:53 PM »
It has been widely reported that the elevation data recorded by the DJI Phantom 4 in the EXIF data is the altitude above ground level (above the point of takeoff) and is determined by barometric pressure.  The drone does use GPS for navigation.  There are also two elevation fields in the EXIF data and I believe one is labeled GPS elevation.  It has been confirmed multiple times that the DJI Phantom 4 model is writing the above ground value not the GPS altitude above sea level value.

It is also noted that the barometric altitude measurement "drifts" over time of the mission by around 10-15 feet so the drone will think it is 10-15 feet higher above the take off ground level near the end of the battery than it recorded near the beginning.

It is unfortunate DJI is no longer writing GPS altitude to EXIF as this does not have the drift problem.  Also on jobs where there may be multiple take off points at different elevations, they will all be consider 0 feet AGL therefore the exif altitude reading would not even be relatively conisistent from the other take off points.  Example you take off at A then go run mission take point B which is 50 feet higher elevation above seal level than A.  The Exif elevation for point B mission of 150 feet would be equivalent to 100 ft elevation data in EXIF for mission flown from point A.  Not good. 


...somebody in an earlier thread wrote: "PROBLEM
The usual metadata tag that is used by these applications is the ‘GPSaltitude’ tag. Currently DJI populate this from the aircraft's GPS unit. The altitude recorded here is grossly inaccurate. We need to fix this as far as we can."

This can not be an issue or correct, since the Drone is flying the mission by the GPS, so the altitude data in the exif file should be the same as the actual GPS height which also is tranponded to the control software on pad/mobile.

Why is not the exif altitude and the drone altitude the same? and if not - why do Dronedeploy get it right?

MIG-29 (Fulcrum)

jazzyj

  • Jr. Member
  • **
  • Posts: 87
    • View Profile
Re: Altitude used in Processing UAV (DJI Phantom 4 Pro)
« Reply #17 on: April 25, 2018, 01:57:08 AM »
There was reports last year that the P4A/P went from storing GPS altitude to storing barometric relative altitude above ground relative to takeoff point.  It appears to me that the altitude being used by Photoscan from photos taken by a Phantom 4 Adv/Pro is currently indeed the GPS altitude above sea level.  So did it change back?  Anyone with a P4A/P can also verify this if they use Photoscan.  You can go into the reference pane and view the altitude values for each camera position.  For a recent job, the ground elevation above sea level according to Google Earth Pro was 350m and Photoscan was showing 526m for camera position at that point.  This was for a mission to fly 400 feet above ground level.  Either Google or the Drone's GPS is way off though.

350m = 1150 feet.  This is in the ballpark for the known elevation of the surrounding area (it's farmland.)

526m = 1725 feet

1725-1150 = 575 feet.  That' 175 feet higher than the the mission altitude. The GPS altitude is actually supposed to be fairly accurate, I believe within 15 feet.  Maybe this drone is faulty?

You can use this handy online EXIF viewer to see what's inside (http://exif.regex.info/exif.cgi ).  In the XMP there is an Absolute altitude and a relative altitude.  And in the EXIF there is GPS altitufde.  The EXIF GPS altitude matches the Absolute altitude in the XMP and the relative altitude in the XMP is correct. The rumor before (may have been reality until a firmware update) was the relative altitude above ground from the barometer was stored in both fields.  It is no longer.  Check for yourself if you don't believe me.  (One problem with the Internet, especially discussion forums, is how easily false information can spread because no one takes the time to verify for themsevles that what they are reading is true.  Think "fake news" !)
Whether this was just a temporary change/glitch in the firmware some months back or if it was "fake news" I don't know.

My question is, does it matter which elevation type is used in photogrammetry processing as long as the drone's elevation above ground is maintained relatively consistent across all photos?  Meaning if the drone goes over a valley and the altitude above ground because 100 feet higher, it seems with barometer above ground measurement, the drone would think the ground is 100 feet closer than it really is whereas GPS altitude above sea level would be consistent.  It would seem to me you want a consistent altitude reading for all the photos for the entire job site despite your launch point.  Seems this would be true using either measurement.

The big question to me is, if you are using absolute altitude in processing (above sea level), how can the drone know the absolute elevation of any point on the ground (without using GCPs)?  Seems to me it can't.  It can only identify relative elevation changes without GCPs.  Now if the processing used altitude above ground, theoretically if you knew the base elevation of any point in the photo, you could therefore calculate the absolute ground altitude above sea level of any point in the photo by adding that to the elevation data output.

Admittedly, I'm on the fringe of my knowledge of photogrammetry in the context of generating ground elevation data so these are all semi-educated guesses on my part.
« Last Edit: April 25, 2018, 02:04:53 AM by jazzyj »

SAV

  • Hero Member
  • *****
  • Posts: 710
    • View Profile
Re: Altitude used in Processing UAV (DJI Phantom 4 Pro)
« Reply #18 on: April 26, 2018, 11:19:15 AM »
Hi jazzyj,

We did a survey using a P4P and a DJI Mavic Pro about 4 weeks ago (both running the most recent firmware back then), taking off at sea level (on a beach) and flying a standard mission at 60m (P4P) and 30m (DJI Mavic Pro).

This is the XMP info for both:
Quote
P4P
- Absolute Altitude: +82.49
- Relative Altitude: +60.00
- GPS Altitude Ref: Above Sea Level
- GPS Altitude: 82.486 m

Mavic Pro
- Absolute Altitude: +53.19
- Relative Altitude: +31.00
- GPS Altitude Ref: Above Sea Level
- GPS Altitude: 53.186 m

By default, the GPS Altitude value gets imported into PhotoScan, which is quite inaccurate (as you can see). However, if you know the elevation above mean sea level (AMSL) of your point of take-off and add the relative altitude that is stored in the XMP to it, then you should be quite close to the truth (approximately +- 5m). In the case of our P4P, that would be....

0m (elevation AMSL of point of take off) + 60m (relative altitude) = 60m (flight altitude AMSL)

A Python script can do this correction/calculation for you  ;D

However, if you want to get reliable results, you will need to accurately survey a sufficient number of GCPs. No shortcuts here. Note that GCPs are also used for (self-)calibration of your (non-metric) camera, hence they are actually more important than most would think.

All the best.

Regards,
SAV
« Last Edit: April 26, 2018, 11:26:38 AM by SAV »

gto234

  • Newbie
  • *
  • Posts: 42
    • View Profile
Re: Altitude used in Processing UAV (DJI Phantom 4 Pro)
« Reply #19 on: April 26, 2018, 03:06:14 PM »
I agree with SAV. With GCP's you don't have to worry about false GPS reading of your drone. Wrong values will be corrected automatically based on GCP's elevation.
The question I have though is, is it important to use a Geoid in the Coordinate system specified inside Photoscan? I mean the GCP's we shoot with RTK GPS have orthometric Elevations based on a Geoid seperation file. In the Photoscan settings I couldn't combine the system i work with a Geoid file. It say unsupported. So I choose the coordinate system without a Geoid. Is it ok?

jazzyj

  • Jr. Member
  • **
  • Posts: 87
    • View Profile
Re: Altitude used in Processing UAV (DJI Phantom 4 Pro)
« Reply #20 on: April 26, 2018, 07:56:22 PM »
Hi jazzyj,

We did a survey using a P4P and a DJI Mavic Pro about 4 weeks ago (both running the most recent firmware back then), taking off at sea level (on a beach) and flying a standard mission at 60m (P4P) and 30m (DJI Mavic Pro).

This is the XMP info for both:
Quote
P4P
- Absolute Altitude: +82.49
- Relative Altitude: +60.00
- GPS Altitude Ref: Above Sea Level
- GPS Altitude: 82.486 m

Mavic Pro
- Absolute Altitude: +53.19
- Relative Altitude: +31.00
- GPS Altitude Ref: Above Sea Level
- GPS Altitude: 53.186 m

By default, the GPS Altitude value gets imported into PhotoScan, which is quite inaccurate (as you can see). However, if you know the elevation above mean sea level (AMSL) of your point of take-off and add the relative altitude that is stored in the XMP to it, then you should be quite close to the truth (approximately +- 5m). In the case of our P4P, that would be....

0m (elevation AMSL of point of take off) + 60m (relative altitude) = 60m (flight altitude AMSL)

...

Yes, you have basically confirmed my own observation although the discrepancy appears to be consistently 22m high in your case.  Unfortunately it isn't consistent across locations as we were seeing it report 50m+ higher in an inland area where known ground elevation was about 1,150ft.  The barometer is quite accurate though.

I should note that if all you need is a topographic map of the land showing relative elevation differences for say for pre-design purposes, I think knowing the absolute ground elevation is really unnecessary.  It's the relative changes between points that is important.  In that case the use of GPSs is much less beneficial in my opinion.  Most have stated that vertical accuracy has been around 3 times GSD.  I personally think that's very optimistic so I always assume 5 times with no GCPs.  So if you fly to capture images at 1-inch GSD, the RELATIVE vertical measurements will be within 5 inch accuracy.  For most projects this is more than adequate when measuring land areas with features (gullies, hills, ridges) that are representing +/- 100 feet or more in differences.

It all really depends on the application.

jo

  • Newbie
  • *
  • Posts: 4
    • View Profile
Re: Altitude used in Processing UAV (DJI Phantom 4 Pro)
« Reply #21 on: April 26, 2018, 11:59:37 PM »
I believe both embedded GPS and gcp are important for calibrating the non metric camera we use in uas mapping

Incoherence between embedded GPS position and gcp position are unfortunately easily balanced by changing either calibration or exterior orientation during the optimize process. (provided that they are both used in the self calibrating bundle block adjustment of course)

I have observed drift in altitude information from phantom 4 pro images (fw 1.06)  that affect the accuracy of photogrammetric results. Also incoherence between altitude of different flights. I do not know yet how to handle this..

Jojo

SAV

  • Hero Member
  • *****
  • Posts: 710
    • View Profile
Re: Altitude used in Processing UAV (DJI Phantom 4 Pro)
« Reply #22 on: April 27, 2018, 05:47:26 AM »
Hi jazzyj,

The rule of thumb that you mention (vertical accuracy is around 3 times GSD) is only valid if accurately surveyed GCPs have been used (!!). If not, then the error is much higher (even larger than your estimate of 5 times GSD), due to shortcomings in the self-calibration of your camera.

Interesting fact: James et al (2014) pointed out that the additional collection of oblique imagery instead of nadir only (convergent imaging geometries) is able to reduce the error in self-calibrating image networks where the interior orientation parameters are acquired during processing (bundle adjustment). This means that accuracy is also influenced by camera orientation.

Accuracy is quite a complex topic when it comes to SfM MVS workflows. There are many factors that play a role.

Long story short. If you want to get 'visually accurate' models wit a non-metric camera (as used on most UAVs), then you probably won't need GCPs. If you want 'measurably accurate' results, then you'll need GCPs that have been properly surveyed (using RTK/PPK GPS or total station).

All the best.

Regards,
SAV
« Last Edit: April 30, 2018, 09:17:40 AM by SAV »

jazzyj

  • Jr. Member
  • **
  • Posts: 87
    • View Profile
Re: Altitude used in Processing UAV (DJI Phantom 4 Pro)
« Reply #23 on: April 27, 2018, 09:28:05 AM »
Hi jazzyj,

The rule of thumb that you mention (vertical accuracy is around 3 times GSD) is only valid if accurately surveyed GCPs have been used (!!). If not, then the error is much higher (even larger than your estimate of 5 times GSD), due to shortcomings in the self-calibration of your camera.

Interesting fact: James et al (2014) pointed out that the additional collection of oblique imagery instead of nadir only (convergent imaging geometries) is able to reduce the error in self-calibrating image networks where the interior orientation parameters are acquired during processing (bundle adjustment). This means that accuracy is also influenced by camera orientation.


I don't doubt what you assert is true.  Maybe the information so widely spread then is assuming oblique imagery is also used but of course most of the information lacks specific details.  It may be the case of many information sources regurgitating flawed assertations.

https://blog.dronedeploy.com/accuracy-in-drone-mapping-what-you-need-to-know-10322d8512bb

"Relative accuracy: Is typically a multiple of your data’s average Ground Sampling Distance (GSD). The horizontal relative accuracy is 2x GSD (for example, if your GSD is 2 cm/pixel, the horizontal accuracy will be approximately 4 cm) and the vertical relative accuracy is typically 3x GSD."

https://support.skycatch.com/hc/en-us/articles/219500068-What-s-the-Z-Accuracy-of-Data-Captured-with-Skycatch-Flight-App-

"The expected accuracy for the Z coordinate is 3x GSD vertically.

The rule of thumb for transferring from GSD to Z accuracy is multiplying the GSD value by 1.5 - 3."


https://support.pix4d.com/hc/en-us/articles/202558889-Accuracy-of-Pix4Dmapper-Outputs

"Generally, one can expect an error of 1-3 times the Ground Sampling Distance (GSD) of the original images for the relative position of a point in a project that is correctly scaled and reconstructed."

https://github.com/gtoonstra/project-ion/wiki/How-to-guarantee-the-quality-of-survey-data

"You should nowadays be able to achieve about 1x GSD RMSE in your model. So if you have 2cm / pixel, your model error shouldn't be larger than 2cm horizontally. Vertically it's about 3x GSD."

http://www.mowastecoalition.org/resources/Documents/2016%20conference/Tukuh-Blackstone.pdf

"Relative 3D model accuracy – 1 to 3x GSD"

https://www.fsbpa.com/17AnnualConfPresentations/Sasso-Witkowski.pdf

"Horizontal Accuracies based on 2x the GSD while your Vertical Accuracy near 3x GSD."


And on and on...

SAV

  • Hero Member
  • *****
  • Posts: 710
    • View Profile
Re: Altitude used in Processing UAV (DJI Phantom 4 Pro)
« Reply #24 on: April 27, 2018, 11:35:35 AM »
Hi jazzyj,

I think that quite often people just say 'looks good' and take measurements even without really knowing about the error/uncertainty. 
I don't think that a relative accuracy of 1-3 x GSD is possible without having a) a properly calibrated camera or b) accurate reference information (e.g., ground control points, etc) that allows for self-calibration during SfM MVS processing.

I am only commenting on the Pix4D statement - these guys know what they are doing  ;)
Quote
https://support.pix4d.com/hc/en-us/articles/202558889-Accuracy-of-Pix4Dmapper-Outputs

"Generally, one can expect an error of 1-3 times the Ground Sampling Distance (GSD) of the original images for the relative position of a point in a project that is correctly scaled and reconstructed."

correctly scaled ... how is that possible without using any reference information and/or a metric camera?

I might run a test with one of my datasets  in order to evaluate this issue.... if I can find some spare time  ;D

Regards,
SAV


« Last Edit: April 27, 2018, 11:38:08 AM by SAV »

cadm8

  • Jr. Member
  • **
  • Posts: 74
    • View Profile
Re: Altitude used in Processing UAV (DJI Phantom 4 Pro)
« Reply #25 on: April 27, 2018, 11:03:17 PM »
Ran recently a quarry survey with dense due to elevations GCPs and cross checked by surveying a profile line with our RTK GPS. Photoscan succeeded (as usually) in reconstructing the model within the GCP rule accuracies. The point cloud points  ;D were within the expected margins

SAV

  • Hero Member
  • *****
  • Posts: 710
    • View Profile
Re: Altitude used in Processing UAV (DJI Phantom 4 Pro)
« Reply #26 on: April 30, 2018, 09:22:30 AM »
For people who want to know more about DEM accuracy, camera calibration and use of GCPs:

Quote
The parallel-axes image configuration (= nadir imagery) results in unfavourable error propagation due to unfavourable parameter correlation, which inherits the separation between DEM shape and radial distortion (James and Robson, 2014a; Wu, 2014), resulting in a dome error that needs either GCP implementation or a well-estimated camera model for error mitigation (James and Robson, 2014a; Eltner and Schneider, 2015). However, GCP accuracy has to be sufficient or else the weight of GCP information during bundle adjustment is too low to avoid unfavourable correlations, as shown by Dietrich (2016), where DEM dome error within a river reach could not be diminished even though GCPs were implemented into 3-D reconstruction.
Eltner et al 2016

Scientific proof for my previous statements  ;D

Long story short: Without the use of accurate reference information (GCPs, etc) and/or a metric camera (which does not need self-calibration), you won't be able to achieve high quality results. Even the relative accuracy will be quite low due to 'doming' effects, es mentioned in several publications.

Regards,
SAV

« Last Edit: April 30, 2018, 09:26:26 AM by SAV »

SAV

  • Hero Member
  • *****
  • Posts: 710
    • View Profile
Re: Altitude used in Processing UAV (DJI Phantom 4 Pro)
« Reply #27 on: May 02, 2018, 02:23:36 PM »
Hi again jazzyj,

I've done some testing regarding the relative accuracy if no GCPs are used but only EXIF info from the Phantom 4 Pro. My results are based on a high resolution survey with an average flight height of 16m and an average GSD of 0.4 cm/pix (all imagery NADIR). I compared the difference between the use of GCPs (surveyed with RTK GPS) and no GCPs to see if the relative accuracy would still be OK.

Long story short. NO - but there is also some good news  ;). The main problem is that due to the lack of proper GCPs, the model is not correctly scaled and also tilted. The tilt is related to the known GPS drift. In 9 minutes it drifted by over 3m vertically, which means every DEM you get out of PhotoScan only using the EXIF info of your P4P will be tilted.

I've used CloudCompare to do a proper analysis. I have aligned both clouds using ICP. Then I've compared the tie points using the M3C2 algorithm to assess the VERTICAL difference. It was between +0.54m and -0.42m, which is definitely a much higher error than 2 to 4 times the GSD, which in my case would be 0.008 to 0.016m. However, it was noticeable that in flat regions of the model the error was overall smaller, but still too high for my liking.

I then fixed the scale of the tie point cloud by using ICP in CloudCompare and aligning it with the tie point cloud that used accurate GCPs. The vertical difference was much smaller then, between -0.10 to +0.03m, with almost all values showing an accuracy of 2 - 4 times the GSD - good news  ;D. Which means if you can properly scale your model, your relative accuracy should be fine.

Therefore, I suggest to include one or better several properly sized scale bars in your model in order to achieve a reliable relative accuracy.

I can therefore confirm Pix4D's statement:
Quote
"Generally, one can expect an error of 1-3 times the Ground Sampling Distance (GSD) of the original images for the relative position of a point in a project that is correctly scaled and reconstructed."

I hope this is helpful.

All the best.

Regards,
SAV



Hi jazzyj,

The rule of thumb that you mention (vertical accuracy is around 3 times GSD) is only valid if accurately surveyed GCPs have been used (!!). If not, then the error is much higher (even larger than your estimate of 5 times GSD), due to shortcomings in the self-calibration of your camera.

Interesting fact: James et al (2014) pointed out that the additional collection of oblique imagery instead of nadir only (convergent imaging geometries) is able to reduce the error in self-calibrating image networks where the interior orientation parameters are acquired during processing (bundle adjustment). This means that accuracy is also influenced by camera orientation.


I don't doubt what you assert is true.  Maybe the information so widely spread then is assuming oblique imagery is also used but of course most of the information lacks specific details.  It may be the case of many information sources regurgitating flawed assertations.

https://blog.dronedeploy.com/accuracy-in-drone-mapping-what-you-need-to-know-10322d8512bb

"Relative accuracy: Is typically a multiple of your data’s average Ground Sampling Distance (GSD). The horizontal relative accuracy is 2x GSD (for example, if your GSD is 2 cm/pixel, the horizontal accuracy will be approximately 4 cm) and the vertical relative accuracy is typically 3x GSD."

https://support.skycatch.com/hc/en-us/articles/219500068-What-s-the-Z-Accuracy-of-Data-Captured-with-Skycatch-Flight-App-

"The expected accuracy for the Z coordinate is 3x GSD vertically.

The rule of thumb for transferring from GSD to Z accuracy is multiplying the GSD value by 1.5 - 3."


https://support.pix4d.com/hc/en-us/articles/202558889-Accuracy-of-Pix4Dmapper-Outputs

"Generally, one can expect an error of 1-3 times the Ground Sampling Distance (GSD) of the original images for the relative position of a point in a project that is correctly scaled and reconstructed."

https://github.com/gtoonstra/project-ion/wiki/How-to-guarantee-the-quality-of-survey-data

"You should nowadays be able to achieve about 1x GSD RMSE in your model. So if you have 2cm / pixel, your model error shouldn't be larger than 2cm horizontally. Vertically it's about 3x GSD."

http://www.mowastecoalition.org/resources/Documents/2016%20conference/Tukuh-Blackstone.pdf

"Relative 3D model accuracy – 1 to 3x GSD"

https://www.fsbpa.com/17AnnualConfPresentations/Sasso-Witkowski.pdf

"Horizontal Accuracies based on 2x the GSD while your Vertical Accuracy near 3x GSD."


And on and on...
« Last Edit: May 02, 2018, 06:31:28 PM by SAV »

wizprod

  • Jr. Member
  • **
  • Posts: 85
    • View Profile
    • Dronographica
Re: Altitude used in Processing UAV (DJI Phantom 4 Pro)
« Reply #28 on: May 04, 2018, 03:56:31 PM »
How will an RTK equipped drone, using no GCP's or Scale Bars do? Comparable to RTK GCP's?

The time consumed by placing and measuring out GCP's seem to worry my clients, as it is considered downtime, where heavy machinery can't operate as freely a usual.

SAV

  • Hero Member
  • *****
  • Posts: 710
    • View Profile
Re: Altitude used in Processing UAV (DJI Phantom 4 Pro)
« Reply #29 on: May 04, 2018, 05:32:33 PM »
Hi wizprod,

Accuracy is quite a complex topic when it comes to SfM MVS workflows. There are many factors that play a role, e.g. GSD has an important influence on the achievable accuracy. But to answer your question....

Some time ago I ran a test to see how accuracy would change if I only used accurate camera locations and no ground control points. Because I did not have access to a drone with RTK/PPK capabilities, I simply flew a normal survey (all imagery nadir) and used a sufficient number of GCPs which I surveyed using an RTK GPS. Then I ran the camera alignment and optimisation in order to estimate camera orientations and locations. I then exported the estimated camera locations (no orientations), added a random error in the range of the RTK RMS error (1-4cm) to them and finally used them as 'EXIF reference information' in my test. This should simulate what an RTK/PPK drone would be delivering ( 'air control points'). Long story short. I basically achieved the same accuracy.  I think it has to do with the much larger number of air control points (one for each picture) compared to traditional ground control points, which actually helps to 'optimise' the camera pose and calibration as well as scene geometry.
Most surveyors would still suggest to place and measure a few traditional ground control points in order to verify and ground truth your modelling results. I personally suggest the same; make use of a small number of ground control points for QC validation, unless you completely trust your RTK/PPK capable UAV  ;)

Interestingly, there have been a number of studies and white papers that basically support what I stated before. They suggest that high accuracy datasets are achievable without any ground reference information by using an UAV with RTK/PPK capabilities  (e.g., https://www.questuav.com/wp-content/uploads/2017/07/DATAhawk-PPK-Accuracy-Assessment-and-Validation-v1.1.pdf).

Something else which I tested in order to improve accuracy (especially Z accuracy) is to follow the convergent image acquisition workflow which has been suggested by James et al (2014). The additional collection of oblique imagery instead of nadir only (convergent imaging geometries) is able to reduce the error in self-calibrating image networks where the interior orientation parameters are acquired during processing (bundle adjustment). Not hard to do, and in my case it improved Z accuracy by about 25%.

You might also find some interesting information regarding accuracy on this website: http://fairbanksfodar.com/understanding-fodar
This guy is involved in some great projects. I like his work :D

All the best.

Regards,
SAV

« Last Edit: May 07, 2018, 06:31:45 AM by SAV »