Forum

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.


Topics - sven_a

Pages: [1]
1
Python and Java API / Export DTYPE
« on: July 07, 2020, 03:12:46 PM »
We are currently exporting orthomsaics by using a band transformation and exporting the index value. We use of NoData value of -10000. This provide an tif with Floating point 32Bit. The original values easily fit in a smaller DTYPE. Is it possible to change this (with python?) Thanks! :)

2
Python and Java API / Export OrthoMosaic with nodata_value
« on: January 10, 2020, 03:20:17 PM »
Hi,

Maybe at the wrong location in this forum but I am now using this function to export an orthomosaic with a nodata value of -10000 in Python:
       
chunk.exportRaster(db.rgb_pg_path, nodata_value=-10000, save_alpha=True, white_background=False, source_data=Metashape.OrthomosaicData, image_compression=compression)

Sometimes when we have issues with the automatic processing we would like to export an orthomosaic with the normal user interface. However I cannot find an option to set the nodata_value there?

Kind regards,

Sven

3
In the processing report there is a nice table with X-Error, Y-Error, Z-Error, XY error and total error (m).
Is it possible to access this information with the python API?
We want to automatically check if the accuracy falls within the expected range (especially important for RTK flights).

Thanks in advance,

Sven

4
Python and Java API / buildOrthoMosaic/buildDEM projection Python v1.6
« on: January 07, 2020, 07:01:37 PM »
Hi,

I used to build the orthomosaic with the following line of code:

chunk.buildOrthomosaic(surface_data=data_source_ortho, projection=localCRS, progress=progress_print)

I get a Value Error: Invalid argement value: projection:

localCRS = Metashape.CoordinateSystem("EPSG::" + str(utm1))

in this case:

localCRS = <CoordinateSystem 'WGS 84 / UTM zone 31N (EPSG::32631)'>

How do I need to provide the correct coordinate system with the new API?

Thanks in advance,

Sven

5
General / radiometric jpgs from FLIR Vue Pro R alignment issues
« on: January 07, 2020, 12:03:26 PM »
I already processed many thermal flights as grayscale tifs and even though the temperature calibration is often quite hit or miss (but that is an hardware issue) I was able to create an Orthomosaic.

Now I received a dataset from a client that has been aquired as radiometric jpgs and I am stuck. The image alignment completely fails. Am I missing something if there a different workflow for radiometric jpgs compared with thermal images aquired as grayscale tif?

Kind regards,

Sven

6
Python and Java API / Metashape v1.6 downscale parameter
« on: January 07, 2020, 11:59:19 AM »
I am currently busy updating our headless scripts to work with the new Metashape 1.6 version. I feel like there are many changes in the API so this is probably the first of many small questions. :)

I used to work with accuracy=Metashape.HighQuality (For Dense Cloud) and Metashape.HighAccuracy (for Image Matching) and I see that this is changed to downscale=1

-----
For Image matching:
Metashape.HigestAccuracy correponds with downscale = 0.25 (because it is actually an 4 times upscale?)
Metashape.HighAccuracy corresponds with downscale = 1
Metashape.MediumAccuracy corresponds with downscale = 4
Metashape.LowAccuracy corresponds with downscale = 16
Metashape.LowestAccuracy corresponds with downscale = 64

For Dense cloud:
Metashape.HigestQuality which now corresponds with downscale=1
Metashape.HighQuality corresponds with downscale=4
Metashape.MediumQuality corresponds with downscale = 16
Metashape.LowQuality corresponds with downscale = 64
Metashape.LowestQuality corresponds with downscale = 256

is this correct?

Kind regards,

Sven

7
Python and Java API / Progress report from python
« on: July 22, 2019, 05:08:07 PM »
We are working with very large datasets that we are processing in the background with Agisoft. To get a time/progress estimate we would like to write this information to a file that we can open. To limit to amount of write actions and to keep a somewhat managble overview we would like to report the progress every 10% or 10 minutes. We are working with this code (somewhat adapted from a few lines of code found on this forum):

Code: [Select]
def progress_print(p):
    """
    MAKE COPY OF FILE BEFORE OPENING DURING ACTIVE RUN!
    :param p:
    :return:
    """
    global last_progress_percentage
    global last_progress_minutes

    elapsed = float(time.time() - start_time_processing_step)
    elapsed_min = elapsed / 60
    elapsed_progress = p - last_progress_percentage

    if p and (elapsed_progress > 10 or elapsed_min > 10):
        last_progress_minutes = elapsed_min
        last_progress_percentage = p
        sec = elapsed / p * (100 - p)
        hhmmss = datetime.timedelta(seconds=int(sec))

        with open(progress_status_path, "a") as file:
            dt_string = datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")
            progress_text = "{}; step: {} ({}/{}); progress: {:.2f}%; estimated time left (HH::MM:SS): {}\n".format(
                dt_string, processing_steps[processing_steps_counter], processing_steps_counter + 1,
                len(processing_steps), p, hhmmss)
            file.write(progress_text)

The issues is that the global variables do not seem to always update correctly (but weirdly sometimes it is updated) and consequently this code is triggered way too often (especially in the build depth maps and generate dense cloud steps). Any idea how we can succesfully update the variables last_progress_percentage & last_progress_minutes. Now it does not always update correctly. Any ideas or help would be really appreciated. :)


Pages: [1]