Messages

1

Python and Java API / Re: Build Orthomosaic and buildOrthomosaic have different behaviors using network

« on: October 02, 2021, 02:56:03 AM »

Alexey,

Thank you for the prompt response. Is Metashape.Task.* able to be called within a script that is called from Batch Process (within the Metashape GUI)? I am asking because it has the following:

"
if process_network:
    network_tasks = []
    for task in tasks:
        if task.target == Metashape.Tasks.DocumentTarget:
            network_tasks.append(task.toNetworkTask(doc))
        else:
            network_tasks.append(task.toNetworkTask(chunk))

    client = Metashape.NetworkClient()
    client.connect(network_server)
    batch_id = client.createBatch(doc.path, network_tasks)
    client.resumeBatch(batch_id)

    print('Processing started, results will be saved to ' + output_folder + '.')
"

This would make me think this *.py file would be called from the CLI as within the GUI you setup 'network_server' and other network params in the toolbar.

If you CAN in fact call Metashape.Task within a *.py that is called within the Metashape GUI and used within a *.XML file, do you select 'Start on network?' or similar (I can't remember the exact language when you start a Batch Process).

But to answer your question, our *.py works just fine (i.e. calling buildOrthomosaic() and buildOrthophotos() within the same script). It is the Build Orthomosaic that is causing a 'null orthomosaic' error. Note that when I see 'Build Orthomosaic', it is the Batch Process step you can add to an XML using the dropdown toolbar (within Batch Process dialog).

Thanks!

2

Python and Java API / Build Orthomosaic and buildOrthomosaic have different behaviors using network

« on: October 01, 2021, 06:31:50 PM »

See following batch XML. The problem we are having is related to network processing. If we run only the first step 'BuildOrthomosaic' of METHOD 1 (i.e. Build Orthomosaic) using the 'native' Metashape call on our cluster of machines, the process completes, saves and builds fine. We can then run our custom script 'export_orthophotos.py'.

However, if we try to run both steps on the network, it appears the mosaics get built (takes long enough and shows it is building on the cluster), but shows an error for 'null orthomosaic' when it gets to our Step 2 ('export_orthophotos.py').

METHOD 1

<?xml version="1.0" encoding="UTF-8"?>
<batchjobs save_project="true" version="1.7.1">
  <job target="all" name="BuildOrthomosaic">
      <cull_faces>true</cull_faces>
      <projection>
          <crs>GEOGCS["WGS 84",DATUM["World Geodetic System 1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.01745329251994328,AUTHORITY["EPSG","9102"]],AUTHORITY["EPSG","4326"]]</crs>
          <transform>1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1</transform>
          <surface>0</surface>
          <radius>1</radius>
      </projection>
      <refine_seamlines>true</refine_seamlines>
  </job>
  <job name="RunScript" target="all">
      <path>../export_orthophotos.py</path>
      <args></args>
  </job>
</batchjobs>

We have save_project=True. What are we doing wrong? Further, if we modify 'export_orthophotos.py' to include the buildOrthomosaic, example:

"
export_orthophotos.py:

import Metashape
....
buildOrthomosaic()
...
exportOrthophotos()
..
"

and reduce our Batch Process to a single step such as in METHOD 2, such as:

METHOD 2

<?xml version="1.0" encoding="UTF-8"?>
<batchjobs save_project="true" version="1.7.1">
  <job name="RunScript" target="all">
      <path>../export_orthophotos.py</path>
      <args></args>
  </job>
</batchjobs>

Then the project builds the ortho and is able to export the orthophotos (i.e. no error of a missing ortho) using METHOD 2.

Where is this bug coming from using METHOD 1? I thought there could be a 'delay' in the native save call between Steps 1 and 2 and tried to build in a false time delay by calling 'Generate Report' (METHOD 3), but it still fails and I get 'null orthomosaic' when trying to export orthophotos. Note that when I do cancel the network process, there is in fact NO orthomosaic in the project using METHODS 1 and 3.

METHOD 3

<?xml version="1.0" encoding="UTF-8"?>
<batchjobs save_project="true" version="1.7.1">
  <job target="all" name="BuildOrthomosaic">
      <cull_faces>true</cull_faces>
      <projection>
          <crs>GEOGCS["WGS 84",DATUM["World Geodetic System 1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.01745329251994328,AUTHORITY["EPSG","9102"]],AUTHORITY["EPSG","4326"]]</crs>
          <transform>1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1</transform>
          <surface>0</surface>
          <radius>1</radius>
      </projection>
      <refine_seamlines>true</refine_seamlines>
  </job>
  <job name="GenerateReport">
  <path>../Desktop/tmp.pdf</path>
  </job>
  <job name="RunScript" target="all">
      <path>../export_orthophotos.py</path>
      <args></args>
  </job>
</batchjobs>

Another frustrating bug we continue to find.

3

Python and Java API / Naming RunScript within 'Batch Process' dialog to custom name field?

« on: October 01, 2021, 06:13:39 PM »

Proposal to add in capability of a 'name' or other field for a RunScript call. Currently, users will only see batches (.XML) appear with a series of 'RunScripts', without the ability to provide more verbose names (and see them within the dialog). Users can only recover some of the information they are looking for (e.g. what the script is doing) by selecting Edit, and looking at Path.

It would be beneficial if one could provide a 'name' field that appears in the Batch Process list instead of just seeing 'RunScript'. For example, I may want to have a series of steps that appear with our internal names such as 'Stitch w. match points' (path=.../stitch_w_pts.py), 'Write out and copy to local machine' (path=../write_out.py), etc vs. what we see, e.g. 'RunScript', 'RunScript'. See attached.

Thank you for the consideration.