# MicMac: building photogrammetry 3D models from imagery, at your own expense > MicMac is a free open-source photogrammetry suite for 3D reconstruction, developed at the French mapping agency IGN and the national school of geographic sciences, with a CECILL-B licence and a build process that pulls in PROJ, ImageMagick, exiftool and Qt. It fits research and public-sector mapping work, and it is a poor fit when you need a Windows binary in ten minutes. **micmacIGN/micmac** — Free open-source photogrammetry software tools - Repository: https://github.com/micmacIGN/micmac - Website: http://micmac.ensg.eu - Stars: 936 · Forks: 186 - Language: C++ - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/micmacign-micmac ## Photogrammetry from a French mapping agency, free and copyleft MicMac is a free open-source photogrammetric software package for 3D reconstruction. It is developed at the National Institute of Geographic and Forestry Information, the French mapping agency IGN, and at the National School of Geographic Sciences ENSG, both within the LASTIG laboratory, which is why the project has a different shape from a typical open source tool. This is institutional software with a public body behind it, not a hobby project with a single maintainer. The codebase is C++, and the repository layout is the layout of a mature research codebase: src for the library, applis for the applications, CodeExterne and CodeGenere for external and generated code, ExtDataPrep for data preparation, plus a series of build scripts for Unix, Windows and macOS. A second line of the documentation says that MicMac is distributed under the CECILL-B licence since 2007. The licence field on the repository carries a custom classification that GitHub cannot label, so the authoritative text is the LICENSE.md file in the repository root. CECILL-B is a French copyleft licence with an attribution requirement, which is a real consideration for a public body redistributing derived software, and it is a note about terms rather than advice. ## PROJ, ImageMagick and exiftool are part of the real dependency set The prerequisites list is longer than a C++ library usually requires, and reading it tells you what the tool does with your imagery. ImageMagick handles image format conversion. exiftool and exiv2 read and write image metadata, which matters because photogrammetry depends on the camera geometry stored in the image files. PROJ is listed for coordinate system conversion and coordinate reference system transformation, so if your images carry georeferencing, PROJ is what interprets it. Git, CMake and make are the toolchain, Xlib is needed to launch the GUI tools built on the X window system, and ccache is optional but listed for recompilation optimisation. Qt is also optional and needed only for the Qt based graphical tools. The practical implication is that MicMac does not hide its dependencies behind a self-contained installer. On Linux the same packages are installed by apt-get and by the Dockerfile, and on macOS by Homebrew, so the environment is reproducible once you know the list. ## Building from source on Linux takes five commands after the dependencies The Linux path is the shortest of the three and the best place to start. The dependency install is a single apt-get line covering the same tools as the prerequisites list. ```bash sudo apt-get install git cmake make ccache imagemagick libimage-exiftool-perl exiv2 proj-bin libx11-dev ``` After that, the repository is cloned, a build directory is created, and CMake generates the makefiles. ```bash git clone https://github.com/micmacIGN/micmac.git cd micmac mkdir build && cd build cmake .. ``` Compilation is parallel and the documentation asks you to set the job count to the number of CPUs, which the same page says you can read with nproc --all. ```bash make install -j N ``` The install target places the binaries in the project's bin directory, so the last step is a PATH entry. The path in the example has to be adapted, since it refers to where you cloned the source. ```bash echo 'export PATH=/home/src/micmac/bin:$PATH' >> ~/.bashrc ``` Pre-compiled binaries are also published on the releases page of the repository, which is the faster route when you only need to run the tools and do not need to change the code. ## Windows pulls in vcpkg and a Qt5 build, macOS only needs a flag Windows and macOS diverge mostly in how the Qt tools arrive. On Windows the documentation asks for the Visual Studio Build Tools, Git and CMake, with cmake.exe on the %PATH%, and a Git Bash terminal for the commands. The optional Qt5 route installs vcpkg into a general directory and integrates it, after which the configure step asks CMake to use that toolchain file. ```bash cmake .. -DWITH_QT5=1 -DCMAKE_TOOLCHAIN_FILE=c:/pgms/vcpkg/script/buildsystem/vcpkg.cmake ``` The documentation warns that this downloads and compiles Qt5 and that it takes a very long time. That single warning is the deciding factor for most Windows users: the graphical tools are the optional part of the project, and paying a long compile for them changes the cost calculus. On macOS the dependencies come from Homebrew, and the Qt flag is the same one used on Linux. ```bash cmake ../ -DWITH_QT5=1 ``` If CMake complains about a missing Widgets library, the documented fix is to set CMAKE_PREFIX_PATH to the Qt installation, and on Linux and macOS it is sometimes necessary to append the lib directory to LD_LIBRARY_PATH for the Qt tools to start. In other words, the Qt path has three separate failure modes documented, while the plain build has none. ## The Docker image compiles MicMac too, it does not ship a binary The repository contains a Dockerfile, and the detail worth knowing is that it builds the project from a clone rather than copying in a prebuilt package. ```dockerfile FROM ubuntu:latest RUN apt-get update && apt-get install -y \ build-essential \ make \ cmake \ git \ proj-bin \ exiv2 \ exiftool \ imagemagick \ xorg \ openbox \ qt5-default \ meshlab \ vim ``` The build stage clones the repository, creates a build directory and compiles with a fixed parallelism. ```dockerfile RUN git clone https://github.com/micmacIGN/micmac.git WORKDIR micmac RUN mkdir build WORKDIR build RUN cmake ../ && make install -j8 ``` Two consequences follow. First, an image build is a full source compile, so a Docker deployment is not faster than a native build even though it is more reproducible. Second, the job count is hard coded at 8, which is a poor fit for a machine with fewer or more cores. The image also carries the Qt and Xorg packages and MeshLab, and it adds the built bin directory to PATH through an environment variable. ## The v2 rewrite lives in another repository, and the release history has a three year gap The first line of the README redirects anyone who wants MicMac v2, designated MMVII, to a separate repository, and the description of this repository covers the earlier architecture. That is a significant fork in the road: the mature codebase described here and the current architecture are not in the same tree, so choosing which one to build is a decision about the project, not just about a version number. The version history has a similar shape. Tagged releases are v1.2.0 from 2026-06-10, v1.1.1 from 2023-03-30 and v1.0.beta14 from 2021-05-17. Three years separate v1.1.1 and v1.2.0, so the release numbering hides a long period of development and probably an architecture change between the two. The last push was on 2026-06-19, and the repository is not archived. So the code is receiving work, but the visible release markers are sparse, and the presence of a .travis.yml, an appveyor.yml, a pom.xml for the PSMNet side and a set of bespoke scripts for Unix, Windows and macOS packaging shows a project with a wide build matrix to keep consistent. ## What the toolchain implies about the intended use Reading the installation section as a whole gives a fair picture of who this is for. The project expects a machine with a C++ toolchain, georeferencing libraries and optionally a full Qt development environment, and it asks the user to run a parallel make install and then fix PATH entries by hand. A C++ project built by a research lab is not going to hide those steps, and the instructions do not try to. The alternative approach is the one most users should consider first: take the pre-compiled binaries from the releases page and skip the toolchain entirely. The difference is straightforward. Building from source gives you the ability to change the code, to pick the Qt configuration, and to build the graphical tools for your own platform, at the cost of a full dependency stack and a compile that scales with the number of cores. Using the binaries gives you a working installation in minutes and freezes you to whatever the build host was, with no source level changes and no ability to rebuild the optional tools. For a team that only needs to run 3D reconstruction on imagery they already have, the binaries are the sane choice. For a team that needs to modify the pipeline or add a module, the source build is the only option, and the cost is the price of admission. ## Conclusion Adopt MicMac when you need photogrammetric 3D reconstruction without a commercial licence, when your imagery has real georeferencing that PROJ can transform, and when you are prepared to maintain a C++ toolchain. Do not adopt it if you need a turnkey installer on Windows, since that route adds vcpkg and a long Qt5 compile, or if you need the newest architecture, because the v2 codebase lives in the separate MMVII repository rather than in this one. Before the first build, install the listed prerequisites including proj-bin and exiftool, decide whether you want the Qt tools at all, and check the CECILL-B text in LICENSE.md against your organisation's distribution rules, since the licence field on the repository carries a custom classification that GitHub does not recognise. ## FAQ ### How do I build MicMac on Linux? Install the dependencies with apt-get, clone the repository, create a build directory, run cmake .. there and then compile with make install -j N, where N is the number of CPUs. Finally add the project's bin directory to your PATH, since the install target does not do it for you. ### Which licence does MicMac use and can I use it commercially? The project states that MicMac is distributed under the CECILL-B licence since 2007, and the authoritative text is the LICENSE.md file in the repository root. The licence field on the repository carries a custom classification that GitHub cannot label. ### Do I need Qt to use MicMac? Qt is optional and is needed only for the Qt based graphical tools. When you do want them, the configure step needs the WITH_QT5=1 flag, and on Windows that route also installs vcpkg and compiles Qt5, which the documentation warns takes a very long time. ### Where do I find MicMac v2? MicMac v2, designated MMVII, is not in this repository. The README points to a separate repository for that version, so the architecture and the codebase differ between the two. ### Are pre-compiled MicMac binaries available? Yes, the installation section states that pre-compiled binaries are published on the releases page of the repository. Using them avoids the dependency stack and the source compile entirely, at the cost of not being able to change the code. ## Sources - [Issues](https://github.com/micmacIGN/micmac/issues) - [micmacIGN/micmac on GitHub](https://github.com/micmacIGN/micmac) - [Project website](http://micmac.ensg.eu) - [README](https://github.com/micmacIGN/micmac/blob/master/README.md) - [Releases](https://github.com/micmacIGN/micmac/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/micmacign-micmac