both are files containing geoidal undulation data. these data are usually the ones used to convert ellipsoid heights to orthometric heights the main difference between these two is that GGF are binary files exclusive to trimble grid factory while BYN files are binary files as well but developed by NRCan (Natural resources Canada) The usual form of data inside these files are in a grid style: Geoidal undulation values
Learned that there are wheel file types that are usually packages that need to be unpacked for easier use for codes that need dependencies. can be helpful in visual studio code when pip install fails to install libraries that need significantly more dependencies compared to usual ones. e.g. GDAL Discovered the repositories of Christopher Gohike - is a researcher based in Irvine, California, who is well-known in the Python community for providing a vast collection of pre-compiled Python "wheel" files for Windows. 1 These wheels are particularly helpful for installing Python packages that have C or C++ dependencies, as they often bypass the need for users to have compilers and build tools installed on their systems. Christoph Gohlke's significant contribution is in providing pre-compiled Python "wheel" files for Windows. EPSG 4955 vs EPSG 4617
Dimensionality: The most significant difference is that EPSG:4955 is a 3D CRS, including ellipsoidal height, while EPSG:4617 is a 2D CRS, dealing only with latitude and longitude. Scope: EPSG:4955 is used for geodetic applications where precise 3D positioning is required. EPSG:4617 focuses on the horizontal component and is suitable for mapping and applications where height is either not needed or is handled separately. Base CRS: EPSG:4617 is considered the base 2D CRS from which the 3D geocentric CRS EPSG:4955 is derived. Regularized vs Full Rolling shutter compensation
Regularized Rolling Shutter Compensation: This is a more simplified approach. It uses a mathematical model to estimate and correct the rolling shutter effect based on the camera's motion and the image data. It aims to reduce the distortion while maintaining computational efficiency. It might not fully correct for complex or rapid motions, but it can significantly improve the accuracy of the reconstruction in many cases. It's often a good balance between speed and accuracy. Full Rolling Shutter Compensation: This is a more sophisticated and computationally intensive approach. It analyzes the image data more thoroughly to determine the precise movement of the camera during the capture of each individual line of the image. It attempts to model and correct the distortion on a pixel-by-pixel or line-by-line basis. This method can provide more accurate results, especially when dealing with significant or complex camera motion. It generally requires more processing time and computational resources. Key Differences Summarized In essence:
Regularized compensation is a faster, more general correction. Full compensation is a more accurate, but computationally demanding, correction. The choice between the two depends on the specific requirements of your project: If you need a quick result and the camera motion was relatively smooth, regularized compensation might be sufficient. If you need the highest possible accuracy, especially with fast-moving drones or subjects, full rolling shutter compensation is generally preferred, despite the increased processing time.
CX CY in Camera Calibration
In Agisoft Metashape, CX and CY are camera calibration parameters that represent the principal point coordinates in pixels. Principal Point: The principal point is the point where the optical axis of the camera lens intersects the image sensor plane. Ideally, this would be exactly at the center of the image. However, due to manufacturing imperfections or lens distortions, it's often slightly offset. CX (Principal Point X-coordinate): This parameter defines the horizontal (column) coordinate of the principal point on the image sensor, measured in pixels. CY (Principal Point Y-coordinate): This parameter defines the vertical (row) coordinate of the principal point on the image sensor, also measured in pixels. How are CX and CY values interpreted in Metashape?
Unlike some other photogrammetry software that might report these values relative to the top-left corner of the image, Metashape reports CX and CY as offsets from the image center.
This means that:
A CX value of 0 indicates that the principal point has no horizontal offset from the center of the image. A positive value means it's offset to the right, and a negative value means it's offset to the left. A CY value of 0 indicates no vertical offset. A positive value means the principal point is offset downwards, and a negative value means it's offset upwards from the image center. Therefore, to get the absolute pixel coordinates of the principal point from the top-left corner, you would use the following formulas, where (w) is the image width and (h) is the image height in pixels:
Principal Point X (from top-left) = ( \frac{w}{2} + CX ) Principal Point Y (from top-left) = ( \frac{h}{2} + CY ) Why are CX and CY important?
CX and CY are crucial parameters in the camera calibration process because they help to model and correct for lens distortions. Accurate knowledge of the principal point allows Metashape to:
Improve the accuracy of the 3D reconstruction: By accounting for the offset of the principal point, the software can more accurately project image points into the 3D space. Correct for radial and tangential lens distortions: These distortions are often modeled as a function of the distance from the principal point. Therefore, knowing the correct principal point is essential for accurate distortion correction. Where can you find CX and CY in Metashape?
You can find the adjusted values of CX and CY in the Camera Calibration dialog box after processing (Tools > Camera Calibration...). They are typically listed along with other calibration parameters like focal length (f), distortion coefficients (k1, k2, k3, k4), and tangential distortion coefficients (p1, p2).
In summary, CX and CY in Metashape define the horizontal and vertical offset of the principal point of the camera lens from the center of the image, measured in pixels. They are essential parameters for accurate camera calibration and subsequent 3D reconstruction.
Rolling shutter correction model analysis
The conclusion strongly suggests that if your dataset incorporates a sufficiently dense network of Ground Control Points (GCPs), the necessity of explicitly applying rolling shutter (RS) correction models diminishes significantly.
GCPs as Constraints: GCPs act as highly accurate spatial anchors within your photogrammetric block. They directly constrain the geometry of the reconstructed 3D model. When you have many well-distributed GCPs, they effectively absorb and compensate for the geometric distortions introduced by the rolling shutter effect. The software, during the bundle adjustment process, will adjust the camera parameters and image orientations to fit these fixed control points, implicitly mitigating the RS distortions. Error Distribution: The paper notes that with a dense enough ground control, all the tested correction models resulted in practically the same mean error on the checkpoints. This implies that the dense GCP network achieved a similar level of accuracy as when specific RS correction models were applied. The errors caused by the uncorrected rolling shutter are essentially being minimized by the strong geometric constraints imposed by the GCPs. Focus on Horizontal Accuracy: The paper also highlights that RS primarily affects horizontal coordinates. A dense and well-distributed GCP network provides strong horizontal control, thus effectively minimizing these RS-induced horizontal errors. However, it's important to consider the trade-offs and nuances:
Cost and Time of GCPs: Acquiring and accurately measuring a large number of GCPs can be time-consuming and expensive. In situations where deploying many GCPs is impractical or cost-prohibitive, applying an appropriate RS correction model becomes much more critical to achieve accurate results, especially when using fewer GCPs or relying more on direct georeferencing (GNSS-determined camera stations). Platform Dependency: The paper also points out that the impact of RS varies between different UAV platforms. Some cameras and scanning mechanisms might exhibit more severe rolling shutter distortion than others. In cases with significant RS effects, even a moderate number of GCPs might benefit from the application of a correction model. Accuracy Requirements: The level of accuracy required for your specific application also plays a role. If you need very high precision, especially in horizontal measurements, even with a decent number of GCPs, applying an RS correction might still yield a slight improvement. In summary:
The paper's conclusion indicates that a dense GCP network can be a powerful tool in mitigating the impact of the rolling shutter effect in UAV photogrammetry. While RS is a geometric distortion that needs consideration, especially when using fewer GCPs or aiming for very high accuracy, a robust network of ground control can, to a large extent, compensate for it, making explicit RS correction less crucial in such scenarios. However, the practicalities of deploying GCPs, the specific UAV platform used, and the required accuracy level should all be considered when deciding whether or not to apply a dedicated RS correction model.
Full Frame Sensors and Focal Plane shutter type
Focal plane - uses two curtains that move across the sensor. The exposure time is determined by the gap between these curtains. The entire sensor is exposed for the same duration, albeit sequentially. This mechanism significantly reduces or eliminates the typical rolling shutter distortions. LUREF CRS Request Learnings
EPSG 2169 - LUREF / Luxembourg TM Based on Luxembourg Reference Datum LUREF datum is related to ITRF2000 and ETRF2000 ETRF2000 is the ITRF2000 based realization of ETRS89 LUREF to ETRF/ITRF2000 conversion can be done using Modolensky and Bursa Wolf transformation parameters LUREF is the localized version of ETRS89 specific to Luxembourg so it’s not 1:1 equivalence in elevations CRS request framework here: Does supporting a crs mean that we can immediately use the CORS nearby
that uses this CRS? why cant I add a new datum? the crs admins is not just done yet datum viewer is broken too When does a request really need a dev work? if we were to add CORS stations to our system and those stations does
not provide coordinates for the desired site crs (gda94 to gda2020 case since
base stations stopped providing gda94 coordinates) Given that the stations have ETRF2000 AND luref LTM coordinates, does it mean that we can immediately use this for cors? Technically yes, as long as we have the CRS in admin Propeller only support two transformations. Thus knowing how coordinates can be transformed is not actually important
for us, we only really need the wkt and proj4 strings really and just
a matter of adding datum for crs when needed Coordinate transformation Propeller does, : CRS-admin do not have a look up table for the sphroids, so if adding proj4 string is needed make sure that +ellps => +a= and +rf= are provided Aside from test points in crs-admin checking if GDAL can handle the transformation is also important to know what’s really needed for the proj4 strings try transforming coordinates using gdal first