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 - March Castle

Pages: [1]
1
I am having issues with certain datasets when a portion of the images won't align.

I split the un-aligned images into a separate chunk and align them with the aim of aligning and merging the chunks together.


Unfortunately, after alignment the images appear tilted to the side in relation to the other chunk, and after aligning and merging the chunks, the tilted data remains (see attached)

Can this be solved, or is this caused by having a single line of GCPs along the edge of the dataset which has a strong bias along one axis?


I have tried reprocessing this, but the same issue persists whether I identify the GCPs before or after processing.

Thanks for your help.

2
General / Partial dataset with missing GCPs causing tilted model
« on: November 21, 2023, 01:31:26 PM »
Hello,

I am having problems processing an incomplete dataset. This only features 4 GCPs in a straight line along the same axis, which I think is causing the model to be tilted - see screenshot.

The images were collected with a low resolution thermal camera (382x288 px) with an 8mm lens.

I have tried calibrating the camera and entering the lens and sensor values, but this did not solve the issue.

There is no GPS data in the image metadata, but they have aligned very well - the only issue is the projection.

 
The GCP locations were logged with a centimetre accurate GPS receiver, and I have verified that data is reliable.

Is there any way to correct this, or is the lack of GCPs on the other axis impossible to overcome?

Thanks for your help, March.

3
Bug Reports / Orthomosaic Export Error: Unsupported Data Type: Float 16
« on: December 22, 2020, 01:50:54 PM »
When attempting to export an Orthomosaic as a TIFF, I receive the following error:

'Unsupported Data Type: Float 16'

Does this refer to the source images, or the TIFF i'm exporting?

I've always used 16 bit TIFFs as the source images used to generate the Orthophoto and they have not created errors before - but I have recently updated to a later version of Metashape (1.6.5 / 11249) so perhaps there has been a change in the software?

Thanks for your help.


4
Bug Reports / 'context mismatch in svga_sampler_view_destroy' Error.
« on: March 20, 2020, 04:55:12 PM »
Hello,

One of my copies of Metashapes frequently freezes between workflow processing steps and I am forced to close the program.
When I do, the console prints the following: 'context mismatch in svga_sampler_view_destroy' - see attachment for screenshot.

I think this is related to the graphics card, but i'm not sure which steps to take to avoid this happening.
Has anyone else had this come up?

Thanks for your help, March.

5
General / Problem with changing image paths to avoid reprocessing.
« on: February 07, 2020, 03:50:19 PM »
I am having trouble using a workaround I thought could save me having to repeat the align, dense point cloud and mesh workflow stages.

I have an existing project which I have already fully processed all the way from alignment to generating Orthophotos. This was done using corrected images for data extraction.

Now I want to produce a second Orthophoto from the same set of images, but this time I want to use non-corrected images - i.e straight out of the camera.

I want to avoid repeating the align, dense point cloud and mesh workflow stages, and as the images are essentially identical I thought this could be easily achieved by substituting the uncorrected images for the corrected ones in the existing file and simply repeating the 'build Orthophoto' and 'generate Orthophoto' stages.

I have tried using the 'change path' command to update the filepath from the corrected images to the non-corrected versions.

This seems to work, except for the fact that some of the images are a different orientation within the set - i.e a mix of portrait and landscape. So despite being the same resolution, the portrait images are being flagged as missing (reason: resized) when I attempt to initiate 'build orthomosaic'

I have tried rotating the portrait images in Photoscan, but the problem persists.

Strangely, the image shows as being portrait in the 'Photos' pane, but is landscape in the main window. If you rotate the image 90 degress, then it appears to be landscape in the 'photos' pane, but portait in the main window.

Is there a workaround for this problem?

Thanks for your help.


6
Hello,
I am attempting to export an Orthophoto using data from a Optris PI 450 Thermal Camera. The project consists of 204 Images with 12 GCPs. The Images alligned successfully with very little GCP error and the view in the model workspace appears to be good.

But when I export the orthophoto as a TIF I get a severly distorted image with 95% of the pixels missing.
Can anyone shed any light on any settings I can alter the correct this? Due to small size of the images this project can easily be processed in a short time, so feel free to look at the other project files.

Thanks, March Castle.


7
My work consists of two workflows:

One is to extract crop height data from Dense point cloud data using out of camera Jpegs.

The other is to use the orthophoto to extract purely visual data using minimally processed RAW files- so that crop colour and NDVI can be properly calculated.

I am working with approx 700 images, each are 130mb Raw files - looking for 1cm/Pixel resolution.

If I want to generate an orthophoto from these RAW files to create a purely top-down 2D Image, would it decrease the accuracy of the orthophoto if I use the absolute minimum settings for Dense Point Cloud generation?

The motivation for this is that I want to cut down the processing time - I would like to skip this step entirely but it seems that generating a point cloud is a necessary step even if you are only interested in a top-down two dimensional image.

I understand that some height data is necessary even for a a flat image, as the land and crop itself is not flat, but is enough data gathered during the alignment / sparse cloud generation steps that only a minimal point cloud will be sufficient to retain our current 1cm/pixel resolution?

Thanks for your help, and forgive any ignorance on my part! March Castle.

8
General / Gap in Alignment of Orthophoto.
« on: February 08, 2016, 01:07:21 PM »
Hello,

I am having problems eliminating a gap in my Orthophoto - I have repeated the alignment several times using different settings. This example requires the alignment of 681 images using High accuracy, Disabled Pairs with a 40,000 Key point limit and a 10,000 Tie point Limit. Are these settings suitable?

I calculated the flight to include the recommended amount of overlap and the GCP Locations are accurate to within 2cm accuracy.

The images appear in the photos pane but they do not appear in the model view after the alignment process - see screenshot below. The missing images do not appear to have any more blur or distortion than any of the others in the set.

I have attached the Log if that helps.

Has anyone got any suggestions?
Thanks, March.

9
The Dense Point Cloud option is not available in the 'Source Data' Dropdown within the 'Build Mesh' dialogue box (example attached - although this is not mine) - I can only select 'Sparse Cloud' Can anyone tell me why this is?

I am not entirely sure what defines a Sparse or Dense Point cloud.

The aim is to save the data as a LAS file so that it can be used in ARCGIS.

I have aligned the images (around 500) using High accuracy settings and the Point Cloud was generated using Medium settings using Mild depth filtering.

Thank you for your help, March Castle.

10
General / Severely Flattened Orthophoto
« on: December 03, 2015, 03:05:41 PM »
Hello,

I am having problems creating Orthophotos - they are coming out severely flattened. I have managed to get good results with these images in the past and I don't think I have changed any of the default settings I used then.

I have aligned the images successfully and I know the GCP GPS data is accurate to within 2cm.
The Co-Ordinates system I am using is OSGB 1936 / British National Grid (EPSG:27700) - But I have tried with WGS84 and I get the same results.

Thank you for your help, March Castle.



Pages: [1]