Possible Reprojection Issue in v 1.8.0

[Robert Dzur]

Hello,

I’m running an orthorectification script which orthorectifies a selection of photos in the UTM coordinate system defined in the project and then exports the orthomosaic in a different (neighboring UTM) coordinate reference system.  This script was run in headless mode on MacOS and I am now attempting to replicate through the GUI, although it's slow going as I mention below with relation to the estimation of tile boundaries. Still I did notice that in the console with the GUI the buildOrthomosaic line prints “projection = NAD83 / UTM zone 5N”

I believe I have the projection defined properly in the script, however in headless mode the script does not print the projection in the terminal per this pertinent section of the script as it does in the GUI.

projection = Metashape.OrthoProjection()
projection.type = Metashape.OrthoProjection.Type.Planar
chunk.buildOrthomosaic(surface_data=Metashape.ElevationData, blending_mode = Metashape.MosaicBlending, fill_holes = True, ghosting_filter = False, refine_seamlines = False, resolution_x=1.0,resolution_y=1.0, projection = projection)

Instead, it prints the following to the terminal without the projection information, although I think it's still creating the orthomosaic in the defined project coordinate system.

BuildOrthomosaic: surface = DEM, blending mode = Mosaic, refine seamlines = 0, ghosting filter = 0, pixel size = 1 x 1

After the orthomosaic is built at the end of the script is an exportRaster statement that reprojects the data to the neighboring UTM zone on export to GeoTIFF.

v_projection=Metashape.CoordinateSystem('EPSG::26906')
projection = Metashape.OrthoProjection()
projection.crs=v_projection
chunk.exportRaster(path = pathOrtho, projection = projection, source_data=Metashape.OrthomosaicData, image_compression = compression, resolution_x=1.0,resolution_y=1.0, save_alpha=True, white_background=False)

In the terminal the operation seems to be performing the proper operation as expected with ExprotRaster reporting the proper projection however with a shift in the exported result.

projection = NAD83 / UTM zone 6N, resolution_x = 1, resolution_y = 1, white_background = off

The script seemed to work well in v1.7.5, however, now that I have upgraded to v1.8.0 the reprojection does not appear to provide the same result and instead appears to introduce a shift from where it should be and where the orthomosaic had been positioned appropriately in previous iterations of the script.  I don’t know if something may have changed in the api with regard to this reprojection issue or the version.  I also tried going back to 1.7.5, however, it looks like that version is also now yielding the same shifted reprojection results as generated with the upgrade to v1.8.0.  I thought I had read something in the 1.8 pre-release post about backwards compatibility issues from 1.8.0 back to 1.7x but I’m not sure about that.  I also notice that this can take an exceedingly long time (many hours) to “estimate tile boundaries” which I know is a separate issue.

Any guidance or advice about this reprojection issue would be appreciated.

Thank you.

Rob

[Paulo]

Hello Robert,

I have a queation: in the part of the script pertaining to OrthoMosaic building you define projection as Metashape.OrthoProjection() class. But do you define the projection.crs attribute?

Important to set the correct crs to use in the ortho...

Note: if your elevationdata (DEM) is defined in the desired crs, then you do not need to specify a projection in the BuildOrthomosaic....you only need the projection parameter when you want to create the ortho in a custom planar projection or in crs different from dem

Mybe this can be a path to solve issue...

[Robert Dzur]

Hi Paulo,

Thanks for your recommendations and in particular the note about the DEM projection which is in fact a match to the ortho projection that I wanted to achieve. So, I deleted the "projection = projection" portion of the chunk.buildOrthomosaic line with no additional modifications to the exportRaster portion and tested the headless script last night on a small test.  That test geotiff is now projected in the proper space without the shift that I described in my original post.  Today, I'll test some larger areas but I expect that they will also be have correct registration.  Thank you again for your prompt note. Best regards,

Robert
--