First attempt at a 3D model - methane flue dataset

This is my first attempt at creating a 3-D model with ODM, or with any software for that matter. Here’s an image which shows the subject pretty clearly:

The URL includes the “all assets” download and a folder with all the input images. These were captured in 4K 60fps video from which I extracted frames at manually selected times which seemed good to me. I can also put the whole original video up (on YouTube, it’ll be too big for Dropbox).

Anyway as you can see the result was pretty much disastrous. Reminds me of that scene from The Fly where the chimp gets turned inside-out during the teleportation process!

Obviously I’m doing something really wrong but there’s so many dials to turn that it would be nice to have some guidance on which to start with. I’m guessing that just the nature of the input images is probably a problem in the first place.

Any help appreciated, thanks!

(I’m not sure I have put this in the right category, please lmk if so and where to put it. I used the template for the Datasets category below)

Dataset URL (Dropbox, Google Drive, GitHub…): Dropbox - attempt 1 - lightning - Simplify your life
Number of images: 55
Size in MB: 27.8 MB
EXIF GPS (yes/no): no
GCP (yes/no): no
RTK (yes/no): no


With a site that size and 55 images you are probably lacking overlap between images. I would at least quadruple the amount of images to process and gps is certainly helpful.

Check out the documentation below for help with flight recommendations. The vast majority of processing issues i have had were due to my datasets.

Hope this helps.



uplanddog has you set :slight_smile:

Video framedumps can be problematic as Rolling Shutter Distortion tends to be worse in video, and as uplanddog noted, you’re missing geolocation EXIF which helps keep the reconstruction sane.

However, you might want to make your framedump more deterministic… Maybe once every 0.5s or so to help compensate for these issues.

1 Like

I captured new inputs, this time manually taking stills, which have location data unlike frames extracted from the video, at what seemed like reasonable intervals. DroneDeploy requires the location data so I hadn’t tried it with my earlier images but this time I ran them through and the result is pretty good:

(I’ll later upload the actual full .obj model to the same Dropbox folder but want first to check that the TOS for the free DD trial don’t preclude something like that)

Uploading the images now to to see how that fares – I don’t see the same presets as in my local WebODM instance, ie:

Is there some way to get presets without having to run the local WebODM container just as a front end for Lightning?

Also getting a bit ahead of myself but let’s say that visually the DD-generated and WebODM generated 3D models look very similar. How could one quantify the quality of one vs. the other?

Oh, one more question - I captured the images in raw (.DNG) format but uploaded the JPEG versions as that was already almost 2 GB and DNG’s would be more like 6.6 GB. For 3D maps does there tend to be any advantage to using a raw format (after, I’m guessing, a conversion to PNG or JPEG with zero compression)?

I’ll report back with how the results from WebODM look just with the default settings.

Thanks for all the help folks, this is a great forum!


At the moment, no, the WebODM Lightning WebUI Dashboard does not support presets, so you’d need to use WebODM or the WebODM Lightning client for Windows to get them.

Hard to say without truth data (a model to compare both against, or measurements for specific aspects of the model). I’d say you’re stuck with qualitative visual analysis for this.

I’d recommend RAW → TIFF if you must to keep the extra bitdepth. It really only helps for scenes with a large amount of stops of dynamic range which will be clipped in JPEGs lossy compression and limited bitdepth. If your scene is pretty evenly-lit and not grossly under or over-exposed, you probably don’t need the extra dynamic range.


Update: That was pretty quick (WebODM processing), about 20 minutes! Unfortunately I didn’t record when I started the processing on DD so I’m not sure how that compares.

The quality on the default settings definitely isn’t as good as DD:

Trying again with WebODM/Lightning but this time kicking it off locally with the “3D model” preset.

Edit: Much improved:


Here’s both the DroneDeploy and WebODM results imported into the same project in Meshlab and manually placed side by side:

WebODM is the one where the flue looks like it’s wearing a blue beanie :slight_smile:


Search around on the forums for other comparisons with dronedeploy. You may find some settings (especially in newer posts on the topic) that will help with the outputs. OpenDroneMap defaults to very efficient settings rather than best available.


Here’s the latest attempt following some of the suggestions in this recent thread: WebODM to DroneDeploy comparison - ortho is spot on, holes in 3d model - #15 by israelbar

To be clear there aren’t actually smurf-blue clouds emanating from the flue :slight_smile:! I’m guessing that might come from texturing_keep_unseen_faces: True.

[INFO]    auto_boundary: True
[INFO]    boundary: {}
[INFO]    build_overviews: False
[INFO]    camera_lens: auto
[INFO]    cameras: {}
[INFO]    cog: True
[INFO]    copy_to: None
[INFO]    crop: 3
[INFO]    debug: False
[INFO]    dem_decimation: 1
[INFO]    dem_euclidean_map: False
[INFO]    dem_gapfill_steps: 3
[INFO]    dem_resolution: 1.0
[INFO]    depthmap_resolution: 640
[INFO]    dsm: True
[INFO]    dtm: False
[INFO]    end_with: odm_postprocess
[INFO]    fast_orthophoto: False
[INFO]    feature_quality: high
[INFO]    feature_type: sift
[INFO]    force_gps: False
[INFO]    gcp: None
[INFO]    geo: None
[INFO]    gps_accuracy: 0.2
[INFO]    ignore_gsd: False
[INFO]    matcher_neighbors: 24
[INFO]    matcher_type: flann
[INFO]    max_concurrency: 16
[INFO]    merge: all
[INFO]    mesh_octree_depth: 12
[INFO]    mesh_size: 300000
[INFO]    min_num_features: 15000
[INFO]    name: 00d1f44e-9366-40b1-ad88-534448c56047
[INFO]    optimize_disk_space: True
[INFO]    orthophoto_compression: DEFLATE
[INFO]    orthophoto_cutline: False
[INFO]    orthophoto_kmz: False
[INFO]    orthophoto_no_tiled: False
[INFO]    orthophoto_png: False
[INFO]    orthophoto_resolution: 1.0
[INFO]    pc_classify: False
[INFO]    pc_csv: False
[INFO]    pc_ept: True
[INFO]    pc_filter: 0.0
[INFO]    pc_geometric: True
[INFO]    pc_las: False
[INFO]    pc_quality: high
[INFO]    pc_rectify: False
[INFO]    pc_sample: 0.01
[INFO]    pc_tile: False
[INFO]    primary_band: auto
[INFO]    project_path: /var/www/data
[INFO]    radiometric_calibration: none
[INFO]    rerun: None
[INFO]    rerun_all: False
[INFO]    rerun_from: None
[INFO]    resize_to: 2048
[INFO]    sfm_algorithm: incremental
[INFO]    skip_3dmodel: False
[INFO]    skip_band_alignment: False
[INFO]    skip_orthophoto: False
[INFO]    skip_report: False
[INFO]    sm_cluster: None
[INFO]    smrf_scalar: 1.25
[INFO]    smrf_slope: 0.15
[INFO]    smrf_threshold: 0.5
[INFO]    smrf_window: 18.0
[INFO]    split: 999999
[INFO]    split_image_groups: None
[INFO]    split_overlap: 150
[INFO]    texturing_data_term: area
[INFO]    texturing_keep_unseen_faces: True
[INFO]    texturing_outlier_removal_type: gauss_clamping
[INFO]    texturing_skip_global_seam_leveling: False
[INFO]    texturing_skip_local_seam_leveling: False
[INFO]    texturing_tone_mapping: none
[INFO]    tiles: False
[INFO]    time: False
[INFO]    use_3dmesh: False
[INFO]    use_exif: False
[INFO]    use_fixed_camera_params: False
[INFO]    use_hybrid_bundle_adjustment: False
[INFO]    verbose: False

Yup! Good instinct.


I think youre doing good, those models looks right. Maybe its just a matter of adjusting some parameters or including some more pictures. Some years ago, I worked with some of those gas flares, but never attempt to create the 3D models.

1 Like

I had some of those weird floaty bits in a 3D model of a pine cone, but increasing a couple of parameters cleaned it up nicely

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.