Shift all cameras without them changing relative to each other?

Comments

6 comments

  • Avatar
    cake_games

    can't I import a flight log with lon/lat/alt + omega/phi/kappa ?? the list of formats that include yaw/pitch/roll use X Y Z instead of lon/lat/alt.  what am I missing?

    muddling my way through - 

    0
    Comment actions Permalink
  • Avatar
    Ondrej Trhan CR

    Hi,

    if you want to do something like this the best way is using three points. You can also use something like GCP (ground control points), which you can create from Google Earth if you want to have big precision.

    There is more tutorials how to use GCPs on our YouTube channel.

    If you want to import flight log with Omega/Phi/Kappa you need to add it into flighlog.xml. Like:

    <format id="{97F08A22-F231-4AB4-A2FD-6FA42BB6D638}" descID="9436" desc="Name, X (East), Y (North), Alt, Omega, Phi, Kappa (character-separated)" reader="CapturingReality.Import.CSVFlightLog">
            <parser allowedSeparators=",; &tab;" comment="#" showIgnoreFirstline="true" qualifiers="&quot;optional">
                <Image index="0" format="name.ext"/>
                <X index="1" format="value"/>
                <Y index="2" format="value"/>
                <Altitude index="3" format="value"/>
                <Omega index="4" format="value"/>
                <Phi index="5" format="value"/>
                <Kappa index="6" format="value"/>
            </parser>
        </format>    

     

    1
    Comment actions Permalink
  • Avatar
    cake_games

    Thanks, I actually have a procedure that now works.

    As follows will not require rebuilding the mesh or textures.  it simple transposes everything perfectly to the correct gps coordinates.

    1) Create a single GCP somewhere that is easy to visually match to a point on satellite, or google earth

    2) Get the GPS coordinates that this GCP should have from google earth, satellite, etc.

    3) Set the coordinates of the GCP to match the real-world coordinates. Once this GCP has GPS data it will show the error tail.

    4) I then use my custom export format to export the single GCP (be sure to use project outpu for the projection). This GCP will be exported with lon, lat, alt, actualLon, actualLat, and actualAlt, and finally lon-actualLon, lat-actualLat, alt-actualAlt (last 3 are all that is required - the offset, however the extra data is good for troubleshooting)

    5) I export then the camera registration using another custom format with lon, lat, alt, yaw, pitch, roll

    6) I wrote a python script to process all points from the registration file and move them per the reference GPC transpose.

    7) Once all the cameras have been shifted import the adjusted csv file as "flight log" this moves the camera and zeroes their error.

    8) to get the GCP to move to the correct location, select the component, and click Alignment Update. All mesh and texture is un-touched, only the reference coordinate system moves.

    NOTE: if you want to re-run the alignment, it's best to disable the GCP since your cameras are in relatively perfect alignment. IT's one of those situations where a tiny error between camera positions and the GCP can cause things to wiggle or break.

    .... but that's it.  once the cameras are correctly where they are supposed to be, the model is moved in GPS coordinates.

    it is worth noting, if you export the 3D Model it will not actually move the Euclidean coordinates. the Grid projection 0,0,0 is relative to the reconstruction bounding box if I'm not mistaken.

    But if you e

    so: create a GCP, enter real world coords, export the vector that point is shifted. export the registration data, adjust all camera locations/registration, re-import.  update alignment. 

    these are NEW export formats. They have unique UUID codes I generated. descID="" eliminated the localizations. Which, if you're replacing another export format is good to know so YOUR description doesn't get replaced by the localization ui.xml.

    I named them (USER) to make them much easier to spot in the long list of similar export formats.

     

    Capturing Reality\RealityCapture\flightlogs.xml

    • importer for flight logs using lon, lat, alt, yaw, pitch, roll

     

        <format id="{4D6B0719-650E-48AC-ACEF-F7C5A42F96EB}" descID="" desc="(USER)name,lon,lat,alt,yaw,pitch,roll" reader="CapturingReality.Import.CSVFlightLog">
            <parser allowedSeparators=",; &tab;" comment="#" showIgnoreFirstline="true" qualifiers="&quot;optional">
                <Image index="0" format="name.ext"/>
                <Longitude index="1" format="degrees"/>
                <Latitude index="2" format="degrees"/>
                <Altitude index="3" format="value"/>
                <Yaw index="4" format="value"/>
                <Pitch index="5" format="value"/>
                <Roll index="6" format="value"/>
            </parser>
        </format>

    Capturing Reality\RealityCapture\calibration.xml

    • export format for camera registration using lon, lat, alt, yaw, pitch, roll
        <format id="{2A60DDA7-8B23-427D-8C74-8420BBD0FD26}" mask="*.csv" descID="" desc="(USER)Comma separated, Name, Lon, Lat, Alt, Heading, Pitch, Roll" writer="cvs" requiresGeoref="1" requires="component">
            <body EulerFormat="zyx">#cameras $(cameraCount)
    #name,lon,lat,alt,heading,pitch,roll
    $ExportCameras($(imageName)$(imageExt),$(lon),$(lat),$(alt),$(yaw),$(pitch),$(roll)
    )</body>
        </format>

    Capturing Reality\RealityCapture\controlpoints.xml

    • GCP export format, lon, lat, alt, actualLon, actualLat, actualAlt, lon-actualLon, lat-actualLat, alt-actualAlt
      technically the only 3 bits needed are the last 3 which are delta lon, delta lat, and delta alt.
      note:  $(lat-actualLat) for example - you can do math on exporting!!! that's cool. I WISH there was an import/export parameter API published.
        <format id="{8A97FD68-67BA-4678-B152-7DA028C4CF70}" mask="*.csv" descID="" desc="(USER)Comma Sep, ,name, map(lon,lat,alt), model(lon,lat,alt), vector(dLon, dLat, dAlt)" writer="CapturingReality.Export.ControlPoints" specificCoordSystem="1">
            <body>name,lon,lat,alt,actlon,actlon,actalt,dlon,dlat,dalt
    $ExportControlPoints($If( isGroundControl,$EscapeSpaces($(name)),$(lon:f),$(lat:f),$(alt:f),$(actualLon:f),$(actualLat:f),$(actualAlt:f),$(lon - actualLon),$(lat - actualLat),$(alt - actualAlt)
    ))</body>
        </format>

    If there's interest I could make a repository on github with the python but it's gross just hacked together to get the job done for ~10 or so sites (well actually I'll be using it in perpetuity. that said - I REALLY wish we could just enter the offsets and click a button and the gps coords would update to match the "real-world" singular gps coordinate.

    note I never had to reconstruct meshes or etc. it's just transposing the coordinate system.

    1
    Comment actions Permalink
  • Avatar
    Ondrej Trhan CR

    Hi, thank you for your workflow.

    If you know coordinates of one GCP, you can use more of them, place them over images, turn off camera priors for georeferencing and align images again. Then it will be in the GCP's coordinate system and you don't need export cameras and compute the transformation vector. 

    Also, if you have that vector computed, you can use it in export:

    0
    Comment actions Permalink
  • Avatar
    cake_games

    Thanks Ondrej,

    I tried what I think you suggested.

    I created a GCP on the model and set it's gps coordinate from the satellite map.

    I then adjusted the altitude manually to match the existing altitude, since the satellite provided an altitude of 1.

    Then I turned off camera prior settings -> use camera priors for georeferencing

    I then clicked update (alignment)

    the model rotated and shifted

    setup

    https://photos.app.goo.gl/yEsowSeogsvLUSkP6 

     

    result (settings, start, and finish)

    https://photos.app.goo.gl/4GVF6Qmfzu3WmMaY9

     

    I also tried the move x, y, z but it did not move as expected (move x, move y, and move z) either did nothing.  the vector computed is in GPS coordinates.

    My procedure outlined above seems to provide an reliable and exact solution which does not break reconstructions and does not rotate the ground plane.  in fact, the model does not move AT ALL on exporting to 3D software.  In other words the grid plane coordinate system did not change relative to the model/mesh.  Only the wgs84 gps reference coordinates have moved so model location = real world location.

    **I guess a  little background might be important as well. I have a script that needs to be able to use the epsg:4326 - GPS (WGS 84) coordinate that represents the Grid Plane at 0,0,0

    I export the model using grid-plane.  import that into my 3D software.  I need to know the lon, lat, alt at the model 0,0,0.  so I use the export rcinfo to import a single-vertex obj. which I then turn around and export using the project output (epsg:4326 - GPS (WGS 84)) which then gives me the GPS coords of 0,0,0

    with the gps coords, and the 3D model, I can make changes to the model and export all the points in GPS coords.

    0
    Comment actions Permalink
  • Avatar
    Ondrej Trhan CR

    You need to use minimally three GCP points to get the model to a correct position, not just one (if you want to get the model to that position).

     

    0
    Comment actions Permalink

Please sign in to leave a comment.