Hi and thanks for making this code available.

How can i use general camera intrinsics(fx,fy,cx,cy) with this code?

I see the camera is setup with:

    std::vector<float> distortionCoefficients(5, 0);
    distortionCoefficients[0] = 0.094f;
    distortionCoefficients[1] = -0.35f;
    distortionCoefficients[2] = 0.42f;
    mage::calibration::LinearFocalLengthModel model{ 
        mage::calibration::Line{ -0.000111f, 0.81878f },
        mage::calibration::Line{ -0.000188f, 1.4517f },
        0.5064f,
        0.5115f,
        mage::calibration::Bounds{ 550, 700 }, 
        mage::Size{ 1920, 1080 },
        distortionCoefficients };
    std::shared_ptr<const mage::calibration::Poly3KCameraModel> cameraModel =
        model.CreatePoly3kCameraModel(650, 320, 180);

Can you please explain how I would pass fx,fy,cx,cy into this function?

Thank you!

At present, there's no provided way to visualize the output of a MAGE-SLAM track in order to sanity check it (as a separate issue from GT). A simple visualization app should be provided to serve this function.

Current considerations:

• Babylon Native may provide the easiest integration point for creating a visualizer.
• Depending on the number of dependencies (for example, Babylon Native has quite a few), it may be preferable for the visualizer app to exist in a separate repository as opposed to being checked into the MAGE-SLAM repository itself. In this way, the visualizer could also serve as an example integration without cluttering other integrations that want to use MAGE-SLAM with different technologies.

The term mira as a namespace is not meaningful. Replace this namespace with one that more clearly indicates what sort of implementation resides in the namespace.

This is an outdated requirement and should be removed, possibly as part of a larger overhaul of Settings import/export/serialization.

The version of Arcana currently in MAGE-SLAM is an older (and larger) version of arcana.cpp. MAGE-SLAM should be changed to take arcana.cpp as a dependency and use the implementation there; redundant implementations should be removed, and missing features should be either added to arcana.cpp or separated out in this repository.

MAGE-SLAM supports several outdated and unused serialization formats; we should resolve on one and remove the support for the others. BOB, I believe, is the most modern and robust of the formats, and so is almost certainly the one we should reduce down to.

The bug referred to by this line actually manifests as coming from Runtime.cpp, where a timing issue allows TrackingData.IsLost to be true while m_trackLocalMapWorker->GetHistory() is still empty, sending the program down the wrong side of a conditional statement that ultimately crashes when it tries to use information from the empty pose history.

The correct solution to this problem is likely to revise either the task chain or the scheduler to ensure that the pose history must be updated before IsLost is set to true. However, a quicker workaround that simply checks the history size when it checks IsLost can prevent crashes immediately and thus may be worth adding in the short term.

The following files have been identified as possible legacy code and might should be separated out and/or removed.

• collection.h
• date_assert.h
• DeNoising.cpp
• DeNoising.h
• FormatString.inl
• Plat/*
• ValidateBuildFlavor.cpp
• ValidateBuildFlavor.h
• VolumeOfInterest.cpp
• VolumeOfInterest.h

This will allow the replacement of several Boost types with STL equivalents: most notably, optional. This may also be necessary in order to make use of arcana.cpp, as described in #4.

Map initialization contains a partially-implemented cheirality constraint with pieces commented out. This implementation should either be completed and enabled or removed entirely.

Consider adding clang format or equivalent to ensure consistency throughout the repository.

At time of writing, the only version of Visual Studio supported by the build instructions is 2017. The only (known) reason for this is the use of OpenCV 3.4 binaries, which are provided with implementations up to, but not beyond, VS 2017, and the CMake package therefore fails if the generator is targeting VS 2019. There are likely a number of viable solutions to this: upgrading OpenCV, building a custom OpenCV install, tweaking the build to simply not fail and link against the older DLL, etc. These options should simply be explored, evaluated, and implemented/documented appropriately to enable the use of newer versions of Visual Studio.