Latest Contributions by CodyBenkelman

Chuck I'd have esimilar comments and questions re: my response to Jessica above.   Cody B ... View more

Jessica - sorry for the delay - I did not see your message.  Have you gottn this resolved already? It appears you have the Standard license, is that correct?    We sometimes see minor misalignments but typically not as much as you show in this screenshot.  Can you confirm you had ~70% overlap or more, both along and between flightlines?  I you have less overlap, you may find these sorts of difficulties. Did you us "None" for the orthorectification setting?  If your project has significant terrain changes, you may want to use the "Sparse point cloud" instead of "None". If you still need help, please contact Tech Support. Cody B ... View more

Bill I apologize for the long delay - I missed your message.  (Note I posted this an hour ago, then edited - so if you saw my original post, please review again)   These are known limitations in the multispectral processing workflows - we hope to be able to address this in the version 2023.1 release (Q1 next year).  If you have access to version 2.3.3, you should be able to proceed with the GCPs, but the water mask was not available in that version. Cody B.  ... View more

Kevin - this is an age-old debate.  Many people refer to DEMs as "2.5 D" since they're clearly more than 2D, and yes, useful for some 3D analysis such as line of sight/viewshed.  The fundamental reason we don't consider them fully 3D is that you can't represent any overhanging features (e.g. look under tree canopy to see the tree trunk).  In the case of a building with overhanging eaves, the DSM shows the building as having the full XY extent of the roof footprint, whereas the foundation of the building is smaller - and in most applications seeking the building footprint, they want the foundation, not the roof extents.  But for some specific applications, you're correct that the DEMs can be considered and used as 3D datasets. Personally I think it's an advantage to call these "2D" for users of Drone2Map Standard - the Standard license does not include full 3D functionality but it IS able to create the DEMs (DSM and DTM) - so it's a benefit to these users who may want to calculate volumes of stockpiles or excavations - but the terminology is certainly open to ongoing debate. Cody B   ... View more

Dilshan Once again sorry for the long delay - not sure if you still need this - we wrote up a procedure for correcting altitude values here https://www.esriurl.com/CorrectDroneZ  It discusses sampling the ground elevation from the Esri ArcGIS Online world terrain service, but you could also use your own DEM - it doesn't matter what projection the DEM is in - but a high accuracy DEM is not required.  You're correcting for the drone's reported altitude above sea level or above the ellipsoid - localized changes in the DEM are not reflected in the drone altitude.   However, after running the multiplexer, if you want to show your FMV-compatible video on top of a custom DEM, you can do that by adding the DEM into ArcGIS Pro as an Elevation Source Layer   ... View more

Patrick Creating single file OBJs is on the roadmap.  I'll confirm with the engineers regarding FBX Cody B.   ... View more

I re-read my notes above and realize I failed to mention our Oriented Imagery capability which also supports video.  This is not photogrammetric processing - so it won't create orthos, point clouds, meshes etc. - but re: your comments above about "...a large quantity of archived drone videos..." and "... tag features in the video..." (especially oblique orientation), our growing Oriented Imagery capability provides an excellent foundation for these sorts of use cases.   See https://doc.arcgis.com/en/imagery/workflows/resources/managing-and-visualizing-oriented-imagery.htm for an overview (with resource links) and an example in a web map here https://oi1.img.arcgis.com/app/index.html?oic=f339778a895948ca923d780b7f9017e6    ... View more

I've asked our engineer responsible for this tool to comment - so we may update this response - but I looked at an extracted video frame (tif format) using GDALINFO and it appears correct (below) to me - I highlighted the corner coordinates in bold - note these are raw image pixel coordinates, not a projected coordinate system.   c:\image_mgmt_workflows\OptimizeRasters\GDAL\bin>gdalinfo C:\Users\cody6520\Documents\ArcGIS\Projects\ProProject_FMV+OIC_UC2022droneSeminar\ExtractFrames\YUN_0127_multiplexed_GimbalEdited_0000004.tif Driver: GTiff/GeoTIFF Files: C:\Users\cody6520\Documents\ArcGIS\Projects\ProProject_FMV+OIC_UC2022droneSeminar\ExtractFrames\YUN_0127_multiplexed_GimbalEdited_0000004.tif Size is 1920, 1080 Coordinate System is: COMPD_CS["unknown",     GEOGCS["GCS_WGS_1984",         DATUM["WGS_1984",             SPHEROID["WGS_84",6378137.0,298.257223563]],         PRIMEM["Greenwich",0.0],         UNIT["Degree",0.0174532925199433],         AUTHORITY["EPSG","4326"]],     VERTCS["WGS_1984",         DATUM["D_WGS_1984",             SPHEROID["WGS_1984",6378137.0,298.257223563]],         PARAMETER["Vertical_Shift",0.0],         PARAMETER["Direction",1.0],         UNIT["Meter",1.0],         AUTHORITY["Esri","115700"]]] Origin = (0.000000000000000,0.000000000000000) Pixel Size = (1.000000000000000,-1.000000000000000) Image Structure Metadata:   INTERLEAVE=PIXEL Corner Coordinates: Upper Left  (   0.0000000,   0.0000000) Lower Left  (       0.000,   -1080.000) Upper Right (    1920.000,       0.000) Lower Right (    1920.000,   -1080.000) Center      (     960.000,    -540.000) Band 1 Block=1920x1 Type=Byte, ColorInterp=Red   Overviews: 960x540, 480x270, 240x135   Metadata:     COLORINTERP=Undefined Band 2 Block=1920x1 Type=Byte, ColorInterp=Green   Overviews: 960x540, 480x270, 240x135   Metadata:     COLORINTERP=Undefined Band 3 Block=1920x1 Type=Byte, ColorInterp=Blue   Overviews: 960x540, 480x270, 240x135   Metadata:     COLORINTERP=Undefined   Are you asking because you're having some problem with the images?  A few important points: 1) if your video is aimed above the horizon, exporting a frame may result in a cropped image 2) these video frames are not orthorectified - ArcGIS is not attempting to apply a lens model, nor fit the image to terrain - so it's not intended to support measurements, but simply provide a convenient visualization.   Let us know if that answers what you need Cody B   ... View more

This has been implemented in the latest release of Drone2Map, version 2022.1 - available in either the Standard or Advanced license. One note of caution:  Drone2Map can now display the apparent temperature in Celsius or Fahrenheit, but be aware that the emissivity of the surface can still cause these temperature values to be incorrect.  See https://en.wikipedia.org/wiki/Emissivity  For similar features across a project site, the relative temperature measurements should be reliable, but comparing temperatures of concrete vs. metal vs. vegetation will be less accurate due to their different emissivity values. Cody B.  ... View more

Hi Sara  Sorry for the delay, I just found your post.  It's a known issue that many drones report incorrect height values.  This is most easily and accurately corrected by using ground control.  I see two green crosses, so it appears you DID use control?  (I know you sent me private message about control points as well)  Are you sure they were referenced to orthometric height, not ellipsoidal height?    I'd also recommend at least one additional point near the center - long narrow projects sometimes curve upward or downward and I see yours did that - adding a 3rd point should make it flatten out Cody B>  ... View more

I agree with LongDinh.  The resources listed above (the Image Management documentation and  Imagery Workflows) will take some time to read and understand, but these are our recommended best practices.   If you need assistance with accessing your imagery using the mosaic dataset, let us know more about your data - is it a large collection of orthorectified image tiles?  3 band RGB (not multispectral)?  8 bits per pixel?  Are there any areas of overlapping imagery?  Will this imagery be used outside your organization? Cody B.  ... View more

Teresa You are correct that if the images do not seem to overlap based on initial configuration, the block adjustment won't run. It's hard to know what might be wrong without more discussion, but this diagram shows the different parameters that affect how large the images will appear on the ground.   Ortho Mapping assumes your drone altitude values reference sea level (geoid, blue) then calculates H, but if you're not near the coast and your drone reports H, the apparent footprint will be tiny.  It's also possible that your focal length or sensor size are wrong but that is unlikely... Did you change your Elevation Source? If you try again and it does not work, could you upload one raw image here?  I'll look at your image metadata.  What drone & camera are you using? Cody B.        ... View more

I inserted this comment above, but repeating it here for anyone simply scrolling down to the latest post. ### UPDATE ADDED June 2022 ###  We have published a tech article regarding how to apply corrections for height values in flight logs (most typically from DJI drones but applicable to any drone, presuming you are able to extract the required metadata; Note this new article is ONLY about correcting height values, not about interpreting drone flight logs to FIND or FORMAT the metadata).   See http://esriurl.com/CorrectDroneZ Also repeating from above - Esri does provide a free flight planning and flight control app (for iPad only) that will automatically record metadata in the required format for any video flight.  See at http://esriurl.com/SSLE Cody B. ... View more

Yes, this is a common workflow, and in many cases recommended as a 'best practice'   ... View more