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

Pages: 1 ... 3 4 [5] 6 7
Python and Java API / Format for "projection" parameter in 1.6 Python API
« on: February 21, 2020, 01:11:14 AM »
What is the new format for the projection paramter used in "exportRaster" ?

Previously I had set it as: Metashape.CoordinateSystem("EPSG::"+str(epsgCode)) , when using "exportOrthomosaic" in 1.5

I can't figure out how to translate this to the 1.6 API

General / Re: GUI Reference Checkbox for Yaw
« on: February 18, 2020, 08:56:56 PM »
Is there any reason I would not want to use this data if I have provided it?

I can't figure out when it becomes checked/not checked.

Normally it was always checked, only recently when I move cameras into a new chunk, I see that it is unchecked by default.

General / GUI Reference Checkbox for Yaw
« on: February 18, 2020, 08:31:47 PM »
Can you please explain what the checkbox is under the Reference panel and for Yaw and why it has a checkbox next to it?

Sometimes it is 'unchecked', which seems to cause the Yaw value to be ignored during photo alignment. Is there a pattern for when photos are loaded checked/unchecked, and is there a way to verify this in the python API?

General / Re: Most efficient way to ensure High Accuracy alignment?
« on: January 17, 2020, 12:06:19 AM »
I'm thinking now I was skipping a few very important steps.

1) Optimize cameras: It looks like every time I run this, my total chunk error gets closer to 0. Is it really just that I should run this a few times? It seems almost too "easy", as it takes no time at all and greatly improves the results, is there any reason this isn't done by default???

I have a set of 18 aerial photos in a line with 90% overlap.

When trying to align all of them at once, I get an alignment failed error, and only the first 2/18 align. This happens even if I retry several times. I have also tried renaming and loading the cameras so that they are in a different order in the chunk, but same results.

If I remove the first 2 images and run the alignment, all 16/16 align. The first 2 images are most dissimilar to the rest, as a large cloud shadow covers them.

I need to find a way to automate this process so that I can have a rule to determine when to remove photos from the alignment.

Ideally I would be able to juggle the included photos such that I can get the best results for each set of 20 photos (lowest total chunk error, most photos included).
Do you have any idea what criteria I should base this on?

General / Most efficient way to ensure High Accuracy alignment?
« on: January 15, 2020, 08:15:35 PM »
I have a set of 20-40 aerial photos (in a line, ~90% overlap), with excellent GPS data.

I have run the alignment > mesh > orthomosaic workflow on them several times.
Settings are "High Accuracy" alignment > "Low Face Count" mesh > orthomosaic.

I am trying to figure out the most efficient way to get a high accuracy orthomosaic. I'm comparing my results to google maps to check accuracy (I don't know if they are perfect either, but so far it's been a good reference point).

At the moment, if I use only the first 20 photos, my total Chunk Error is showing as ~7m. I have tried rerunning alignment several times and still it sticks around there, even with "Highest" accuracy marked. When I look at the orthomosaic, it is clear that along a coastline that is in the image, it is not doing that good of a job aligning.

However, if I align all 40 photos, and then export the orthomosaic for the area of the first 20, the orthomosaic looks great and aligns perfectly on the coastline. It also has a total Chunk Error of ~0.6m.

I thought this might mean including a slightly larger area would be good for alignment (despite increased processing time), but later on in my dataset it actually produces worse results if I include more points for alignment that aren't quite in my reference chunk.

Do you have any recommendation for an efficient process to get high accuracy orthomosaics???
1) Should I be including additional cameras that are just outside of my orthomosaic bounds to improve the quality of the orthomosaic?
2) Is a low face count mesh the right choice for an orthomosaic, or should I adjust this?
3) Are there any other default settings I should be editing to increase the quality of the orthomosaic output?

I'm trying to create an orthomosaic of a long transect of 5000 photos.

After several failures, my current plan is to:
1) Align all photos in one chunk
2) Split into ~200 chunks
3) Create meshes
4) Combine chunks
5) Create orthomosaic

I looked at the split into chunks script ( but it isn't working out for me since it seems that it copies all the cameras every time. Running chunk.copy on 5000 photos with the alignment points as well is taking very long.

Does anyone know a work around where I can copy only my ~20 photos at a time, but also copy the alignment/key points with them into the new chunk?

General / Re: Bad Stitching - What causes this?
« on: December 30, 2019, 06:23:02 PM »
why are you dividing the flight lines into separate chunks if you have enough overlap between the lines and GPS tags?
What do you mean by "varying long flight-lines"?

A, sorry, I meant to say VERY long. I have 5000 photos, in one line, covering 225 miles. So, at any point only about 5 photos have any overlap at all.

I decided to split it into chunks because I somehow reasoned that because the start of my flight line and end of my flight line were so disconnected, there was no value in processing it all as one item.

I think this is part of where my issue lies, but when I've run it all in one chunk it is not getting any better results.

It is flying over forest, mountain, and river terrain.

Are you using a RTK-GNSS? And don't you have ground control points?

For gps data I am using  "Applanix POS AV V6", a seperate instrument, it states 10cm horizontal & 20cm vertical position accuracies. I have gotten great results so far with the data, it's only these 200+mile long lines that are causing issues.

No ground control points because I'm 300m above wilderness terrain :)

I'll take a look at that script now and see if it helps.

General / Re: Bad Stitching - What causes this?
« on: December 27, 2019, 09:29:02 PM »
I tried out creating a mesh and orthomosaic for one of these chunks individually, and it produced nice results.

So the final question then is, what is the right way to combine several small items into one big orthomosaic?

General / Bad Stitching - What causes this?
« on: December 27, 2019, 08:31:12 PM »
I have a set of aerial photographs taken in long lines. Over 80% overlap along the lines. Roughly 5000 photos. The GPS data is great, and includes lat/lon, altitude, roll, pitch, yaw.

I'm experimenting with different methods to get an orthomosaic for the entire set, but it just isn't working out. Here are the current steps I take:

1. Load the photos into chunks, with each chunk containing a group of ~ 20 overlapping photos in a contiguous area along my flight line. There is overlap in the photos between the different chunks, so several photos at the edges will appear in two chunks.

2. For each chunk:
  - chunk.matchPhotos(generic_preselection=False)
  - chunk.alignCameras()
  - After some testing, I decided at this point to do some additional things that may or may not be helping things...:
    -  If after aligning the chunk, the chunk is aligned, but a section of at least 4 images in a row (which due to my naming means they would be near each other) is not aligned (says 'NA' in the gui), I would move those photos out of that chunk and into a new chunk. Then I align those new chunks, and do the same if needed, so that wherever possible I don't have large groups of unaligned photos. This was supposed to get as many photos aligned as possible...

3. For each chunk/new partial chunk:
  - Check the total error of the chunk by using the math described here:
  - If the total chunk error is less than 10m, accept it, if not try again (a few times) to align that chunk, before giving up, and ignoring that bad chunk in the future.
    - I couldn't decide how to pick my error threshold, although usually I do not hit the 10m much smaller, like < 0.5

4. Merge good chunks:
  - doc.mergeChunks(goodChunks,merge_markers=True)
  - mergedChunk = doc.chunks[len(doc.chunks)-1]

5. Build mesh:
  - mergedChunk.buildModel(surface=Metashape.Arbitrary, interpolation=Metashape.EnableInterpolation,face_count=Metashape.LowFaceCount)

6. Build orthomosaic:
  - mergedChunk.buildOrthomosaic(surface=Metashape.ModelData,blending=Metashape.MosaicBlending,projection=Metashape.CoordinateSystem("EPSG::4326"))

My reasoning for splitting it up into the chunks was that because I had such a long varying flightline, when I tried to run it all in one model the results were no good, and I thought that might be because the program was creating a model over a long area (?) . Sometimes, this method described above has produced good results, but not consistently enough. If I ever have an area with a LOT of overlap (when the flight is more of a grid pattern instead of a line), the results are perfect.

Some of the "bad" results are like these:

You can see the roads completely warped in one, and the rim of a mountain disconnected in another.

I've written the following function:

Code: [Select]
def sortChunks(doc):
    """Sorts chunks in alphabetical order by title. Chunks beginning with "Merged" will be placed at the bottom."""

    chunkDict = {}
    mergeDict = {}
    for chunk in doc.chunks:
        if chunk.label.startswith('Merged'):
            mergeDict[chunk.label] = chunk
            chunkDict[chunk.label] = chunk
    labels = sorted(chunkDict.keys())
    mergeLabels = sorted(mergeDict.keys())
    newChunks = []
    for label in labels:
    for label in mergeLabels:
    for i in range(len(doc.chunks)-1):
        print(doc.chunks[i].label + ' -> ' + newChunks[i].label)
        doc.chunks[i] = newChunks[i]  #NO EFFECT!

Unfortunately the assignment

Code: [Select]
doc.chunks[i] = newChunks[i]

has no effect. Is there any way to reorder chunks in a script?

I'm creating an orthomosaic of roughly 7000 images, with 90% overlap at most points.
In the past, I've run into issues when running all images as one chunk (especially when they were in long single-image-width lines), so I decided to split them into smaller chunks (in a format to match the rest of my data, usually 50-200 images per chunk).

I split the images, with some overlap for those that intersected several of these chunk boundaries I had decided on. Align images, create low surface mesh, then merge all. In the past I have had the best/quickest results with a low face count mesh as the input for ortho photo.

When I transfer my models, attachment 1 is what the mesh looks like (you can practically see the outline of my chunks in it).
If I recreate a low surface mesh in my merged chunk, the result is image 2 (nm_new_mesh).

Before I continue with the process of creating an orthomosaic, I'd like to know:

1) Of the two meshes, is any one more suited for creating the orthomosaic?
2) Is splitting into chunks totally uneccessary? Will it help or hurt my output?

General / What graphics card to buy for Linux CentOS?
« on: March 14, 2019, 05:43:20 PM »
How should I decide what graphics card to buy in order to use GPU acceleration with Metashape on Linux CentOS? I know the manual says there are no guarantees beyond the list of cards used in Windows, but if anyone has experience with others or recommendations for a good one to try....

I am processing aerial survey photos in long tracks and frequently taking at least 20 hours for alignment and mosaicking (1000+ images), would really like to speed this process up.

The otuput of lsb_release -a :

LSB Version:   :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID:   CentOS
Description:   CentOS Linux release 7.6.1810 (Core)
Release:   7.6.1810
Codename:   Core

The output of lscpu:

rchitecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                72
On-line CPU(s) list:   0-71
Thread(s) per core:    2
Core(s) per socket:    18
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 79
Model name:            Intel(R) Xeon(R) CPU E5-2695 v4 @ 2.10GHz
Stepping:              1
CPU MHz:               1200.988
CPU max MHz:           3300.0000
CPU min MHz:           1200.0000
BogoMIPS:              4200.12
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              46080K
NUMA node0 CPU(s):     0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70
NUMA node1 CPU(s):     1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47,49,51,53,55,57,59,61,63,65,67,69,71
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb cat_l3 cdp_l3 intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdt_a rdseed adx smap xsaveopt cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts

Bug Reports / Export Orthomosaic TIF with JPG compression no alpha channel
« on: December 04, 2018, 02:00:18 AM »

I'm trying to export an orthomosaic. I am using photoscan 1.4.1. The method I am using is the same that previously worked for me on 1.3, but now I am having issues.

When I use the settings shown in that image (export as .tif with jpg compression), the alpha channel is not created in my output .tif files. If I change it to lzw compression, I do get the alpha channel.

Is this expected behavior, or a bug?

Feature Requests / Re: adding new export options for orthomosaic
« on: July 11, 2018, 08:52:05 PM »
If you still have that code, would be great to see it!

Pages: 1 ... 3 4 [5] 6 7