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.


Messages - GGR

Pages: [1] 2
1
General / Re: Cameras positions and EO for multi-cameras layouts
« on: September 06, 2023, 05:23:45 PM »
Thank you JMR! I will try very soon this workflow and will let you know if it solve this out.

Best Regards

2
General / Re: Normals in laz export
« on: September 06, 2023, 05:14:15 PM »
Thank you Jochemla for this answer!

Indeed, a simple space can have a lot of impact! A colleague had put me on this path at the beginning of the week.

I totally agree with your proposal for bug reports. I'll post one that will point to this thread.

3
General / Cameras positions and EO for multi-cameras layouts
« on: August 03, 2023, 05:15:46 PM »
Hey every one,

I can't find a way to import cameras (Inpho Project File) in a multi-cameras layouts chunck.

My data is maid of RGB files and NIR files in separated folders. When I import my RGBs photos, I can import locations and EO contanied in an Inpho file. But when I create a multi-cameras layouts chunck, this same Inpho file cannot be imported succesfully.

I also tryed to export the references imported from the Inpho file in a RGB chunck to a multi-cameras layouts chunck but without much more success.

Does anyone have an idea to solve or subvert this ?

4
General / Re: How to export variance of tie point?
« on: July 19, 2023, 05:50:11 PM »
Hey,

If it's only because of an accuracy matter, you can produce a dense cloud with the confidence index option enabled and then, export it as laz. The laz format will allow you to import it in Qgis to perform your accuracy presentation.

5
General / Re: Extreme Overlap Stitching Question
« on: July 19, 2023, 04:52:07 PM »
Hello,

In my opinion, it's not relevant to formulate overlapping in seconds. It depends on the speed of the UAV, height of fly and sensor used for the survey.

With DJI Pilot 2 (used for M300), side and front overlapping can be expressed in percentage, which is far more accurate. Because we also faced to problem, contractors often try to lower the overlapping rate. It allows smaller flies and amount of photos to deal with, but you will be facing more masks during the reconstruction process.

The overlapping rate we use in urban areas is 75% front and 70% side.

6
General / Normals in laz export
« on: July 18, 2023, 04:31:19 PM »
Hello there,

I'm pretty interested in exploiting normals calculted in AM for future analysis, such as ground segmentation, with PDAL.

As far as I know, laz spec are not designed to embed normals data. But it is possible to export those from AM point cloud interface.

Because I can't find where and how are they stored, does anyone can help me on this ?

Cheers

7
General / Re: Problems aligning big Dataset in one aligment
« on: August 05, 2022, 09:35:38 AM »
You can try to place markers and align your chunks with those. Or to register your clouds with the ICP tool implanted on CloudCompare.

8
General / Re: Hiding camera groups
« on: August 05, 2022, 09:27:28 AM »
What about moving these to an other chunk ?

9
General / Re: Large Area Ortho Help PLEASE!!!!
« on: July 19, 2022, 05:33:38 PM »
Just in case, it should be due to the fact that your GPU isn't enabled. To check it out, in the preference pane and the GPU tab, you could enable it if it isn't.

10
Assuming you are planning a single ortho fly (pitch and roll to 0°), in my opinion the two options you have would be to plan an oblique survey in addition to the ortho or increase the overlap setting. Both of these options will make you use more battery anyway.
Could you also share your workflow's settings?

11
Hey Dukytony,

In my opinion, gaps in your attachment points are not a real problem. If all of your cameras are aligned and the overall accuracy meets your needs, the next steps will "close" those gaps. As for your flight parameters, a few meters higher could help increase your forward and sideways overlap from 75/65 to 80/70 without using more battery. This should help you avoid alignment issues while maintaining high resolution.

Cheers

12
General / Exporting camera calibration to Inpho
« on: September 22, 2021, 12:35:30 PM »
Hey there,

While I was controling an export of a camera calibration in Inpho format made on a 1.7.4 release, I noticed significants differences between the floatings displayed on the camera calibration tool (which are the same as stored in an Agisoft xml export) and the values stored on the Inpho txt file.

The following values are the adjusted ones of a CityMapper. The distortionlessness of this sensor is traducted by the lack of k1,k2,etc and p1 and p2 values.
Code: [Select]
<?xml version="1.0" encoding="UTF-8"?>
<calibration>
  <projection>frame</projection>
  <width>10336</width>
  <height>7788</height>
  <f>15963.115384616023</f>
  <cx>-1.3333000000002044</cx>
  <cy>-4.7148000000001868</cy>
  <date>2021-09-22T08:40:25Z</date>
</calibration>

The table below is the export of the same calibration (adjusted) in Inpho.
Code: [Select]
$CAMERA
  $TYPE : unknown
  $DATE : 10:43:20 22/09/2021
  $BRAND : Custom
  $KIND : CCDFrame
  $CCD_INTERIOR_ORIENTATION :
     299.114       -0    5166.17
       0.0000000000    -299.114    3888.79
  $CCD_COLUMNS : 10336
  $CCD_ROWS : 7788
  $PIXEL_REFERENCE : CenterTopLeft
  $FOCAL_LENGTH :    53.3681
  $PRINCIPAL_POINT_PPA :     0.000000     0.000000
  $DISTORTION_TYPE :  Polynomial
  $RADIAL_COEFFS :
                      0             -7.25205e-19                  6.26401e-22                  7.52744e-24
                      -1.34583e-26                  0                  0                  0
  $DECENTRE_COEFFS :
                      3.46799e-19                  1.68792e-19                  0                  0
  $GPS_ANTENNA_OFFSET :     0.000000     0.000000     0.000000
  $CAMERA_MOUNT_ROTATION :     0.000000

As you can notice, principals points coordinates ($PRINCIPAL_POINT_PPA) are set to 0 and radials ($RADIAL_COEFFS) as well as tangentiels ($DECENTRE_COEFFS) distortions are not set to 0.
Actually, I was expecting the exact opposite result.

Is this way of converting values is the regular one ? Along my research on this topic I noticed ways to convert values but the difference here seems to be too significant.

Best regards
Gabriel

13
Hey Alexey,

The problem is solved. This wasn't a python scripting issue but a stupid mistake in my workflow.

Nevertheless, thanks !

14
Hey there,

I've been using on the 1.7.3 release a python script to orient cameras based on a csv containing EO. Here is this script (by the way, thanks to Alexey and Paulo) :
Code: [Select]
import Metashape

chunk = Metashape.app.document.chunk
crs = chunk.crs
T = chunk.transform.matrix

origin = None
for camera in chunk.cameras:
if not camera.type == Metashape.Camera.Type.Regular:
continue
if not camera.reference.location:
continue
if not camera.reference.rotation:
continue

pos = crs.unproject(camera.reference.location)
m = crs.localframe(pos)
rot = Metashape.utils.opk2mat(camera.reference.rotation) * Metashape.Matrix().Diag([1, -1, -1])
R = Metashape.Matrix().Translation(pos) * Metashape.Matrix().Rotation(m.rotation().t() * rot)

if not origin:
origin = pos
chunk.transform.matrix = Metashape.Matrix().Translation(origin)
T = chunk.transform.matrix

camera.transform = T.inv() * R
chunk.updateTransform()

The problem is, since I moved from 1.7.3 to 1.7.4, this script don't works any longer.

Is there any change in the way to script python commands ?

15
Bug Reports / XML Blocks Exchange import issue
« on: January 05, 2021, 02:25:27 PM »
Hey !

I'd like to import cameras positions and calibrations data produced by ContextCapture so I managed to get an XML Blocks Exchange file as well as the concerned cameras. I precise that I've loaded NGF-IGN69 geoid model (EPSG::5119) which is used as coordinate system in my project.

As an example, here is a part of the XML Blocks Exchange :
Code: [Select]
        <Photo>
          <Id>55610</Id>
          <ImagePath>D:/IMAGES/Left/09_137_124824_203_Left.jpg</ImagePath>
          <Component>1</Component>
          <Pose>
            <Rotation>
              <Omega>-44.2294659638294</Omega>
              <Phi>-8.98957986763937</Phi>
              <Kappa>-81.0641551920933</Kappa>
              <Accurate>true</Accurate>
            </Rotation>
            <Center>
              <x>705884.750718091</x>
              <y>7061439.17630715</y>
              <z>773.699714511843</z>
              <Accurate>true</Accurate>
            </Center>
            <Metadata>
              <SRSId>0</SRSId>
              <Rotation>
                <Omega>135.77379</Omega>
                <Phi>8.97211999999996</Phi>
                <Kappa>81.04876</Kappa>
                <Accurate>true</Accurate>
              </Rotation>
              <Center>
                <x>505872.457</x>
                <y>5610891.335</y>
                <z>773.346</z>
                <Accurate>true</Accurate>
              </Center>
            </Metadata>
          </Pose>
          <NearDepth>587.593386139714</NearDepth>
          <MedianDepth>1131.75971060136</MedianDepth>
          <FarDepth>1382.12451767816</FarDepth>
          <ExifData />

Here is now the export of the estimated view reference pan of Metashape after importing XML :
Code: [Select]
09_137_124824_203_Left.jpg
x : 705884.750718
y : 7061439.176307
z : 817.664289
omega : -179.987093
phi : 0.012384
kappa : 0.000929

Regarding planimetrics data, the three lasts decimals are skipped, which is right.
The altimetric value seems to be modified, it passes from around 773 to 817m. Omega, phi and kappa data are also modified. Basically, cameras orientations are inverted upward instead of being downward (see attachment).
Cameras calibrations groups (obliques and nadirs) are also skipped.
For further investigations, I could also attached the XML concerned.

Could you precise how data are converted from the XML Blocks Exchange to the Metashape so I could figure if the issue comes from natives data, transformations applied, or my workflow.

Thanx by advance.

Pages: [1] 2