# digiCamControl turns a tethered DSLR into a scripted remote > digiCamControl is a C# remote control for DSLR cameras, split across three Visual Studio solutions, a device layer packaged as versioned NuGet packages, and a plugin and workflow framework. Its published releases stop in 2016 while the repository was pushed in October 2026, and the README is little more than a licence notice and a pointer to external developer docs. **dukus/digiCamControl** — DSLR camera remote control open source software - Repository: https://github.com/dukus/digiCamControl - Website: http://digicamcontrol.com/ - Stars: 733 · Forks: 240 - Language: C# - License: NOASSERTION - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/dukus-digicamcontrol ## A Windows desktop remote, with a library hiding inside it digiCamControl is described in one line as DSLR camera remote control open source software, and the primary language is C#. What sits at the top level of the repository is broader than that line suggests. There is an application area, a core library, a devices area, a plugin manager with a matching plugins area, a command line project, a remote command project, a trigger project, a workflow family split into core, data, plugins and setup, a PhotoBooth project and a Web project. The README's first line points developers to a separate developer documentation page under the project site, which implies that the library interface is meant to be consumed from your own code and not only through the bundled desktop program. That distinction matters when you choose this project: the interesting half may be the pieces you can call from code. ## The code started life as a Nikon camera control project The README states plainly that the code was transfered from a Google Code project named nikon-camera-control, and the copyright line reads Copyright (C) 2014 Duka Istvan. That origin explains several traits of the tree. The naming is prefixed with CameraControl throughout, and there is a Canon.Eos.Framework project sitting next to it, so the lineage is a single vendor control effort that grew rather than a suite designed from scratch for many brands. The README also carries the full permission notice, the MIT style text granting use, modification, distribution and sublicensing without restriction, together with the warranty disclaimer. GitHub could not classify the repository licence automatically, so the LICENSE file in the root is the authoritative text and the notice in the README is a summary of it rather than a replacement. ## Three solutions and a batch driven build The repository is a Visual Studio workspace rather than a single project. There are three solution files at the top level: CameraControl.sln, CameraControlDevices.sln and Capture.Workflow.sln, which mirror the three concerns in the product, the device layer and the capture workflow. Alongside them sit build.bat, PostBuild.Bat and PostBuild64.Bat, so the build is driven by batch scripts on Windows rather than by a CI definition in the repository. There are also Rider and ReSharper artefacts, the DotSettings files next to two of the solutions, and a GhostDoc documentation file, CameraControl.sln.GhostDoc.xml, which points to XML doc comments as the documentation source. An FxCop directory appears for static analysis. The result is a build that expects a Windows development environment with Visual Studio tooling, and a documentation strategy that is generated from the code rather than written beside it. ## The device layer ships as its own versioned package Camera support is separated into a CameraControl.Devices project, and the top level carries five prebuilt packages for it: CameraControl.Devices.1.2.0.nupkg, CameraControl.Devices.1.2.1.nupkg, CameraControl.Devices.1.2.2.nupkg, CameraControl.Devices.2.0.73-beta.nupkg and CameraControl.Devices.2.1.0-beta.nupkg, with a CameraControl.Devices.nuspec describing the package. Checking those artefacts into the repository is an unusual choice, and it has a practical effect: the device layer can be consumed from another project without building the whole solution, and the historical versions document how the compatibility surface evolved across the 1.2 and 2.x lines. The repository also contains a CameraControl.Devices.Example project, a PortableDeviceLib directory, an MtpTester project and the Canon.Eos.Framework, so the transport and protocol code is visible as separate pieces. ## Extension points and capture automation live in separate projects Several top level entries point at an extensible architecture. There is a CameraControl.PluginManager with a CameraControl.Plugins area and a separate Plugin.DeviceControl project, which together describe a plugin model with its own manager and a device control plugin. Capture.Workflow is spread across Capture.Workflow.Core, Capture.Workflow.Data, Capture.Workflow.Plugins and Capture.Workflow.Setup, a four part split that separates the workflow engine, its data model, its plugins and its installation. A CameraControl.Trigger project suggests capture triggered by events rather than by a click, and the CameraControlCmd and CameraControlRemoteCmd projects are the command line and remote control entry points. The README does not describe the interfaces any of these expose, so treat the names as a map of the architecture and confirm the actual API in the developer documentation the README links. ## Examples reach beyond the PC, to Arduino and MSP430 The examples directory is where the project's scope becomes clearer than the README manages to say. It holds three subdirectories: Examples/Arduino, Examples/MSP430 and Examples/Tcl scripts. Two microcontroller platforms and a scripting language, next to a DSLR remote control, points at a workflow where the camera is triggered by an external device rather than by the desktop application, and where scripting is the intended way to drive sequences. A DccObsPlugin project at the top level fits that picture as an observer or observation plugin. The repository also carries a Transifex directory, which points at the translation platform used for localisation, an UpgradeLog.htm that records upgrade notes, and a Docs directory. For a photographer building a lighting rig, a microscope rig or a copy stand, this hardware angle is likely the reason to choose the project at all. ## Releases stopped in 2016 while commits carried on The version history is the part that needs careful reading. The two GitHub releases are 2.0.0, labelled a stable release, on 2015-12-24, and 2.0.26, labelled a beta, on 2016-05-06. The repository is not archived, and the last push was on 2026-10-15, so work has continued on the default branch for a long time after the newest tag. The practical reading is that there is a stable public build from December 2015 and a beta from May 2016, and a decade of subsequent development that has not been cut into a release. The build and packaging scripts at the top level, PostBuild.Bat and PostBuild64.Bat, are the route to producing a build yourself, and the repository ships setup artefacts under a Setup directory. The homepage at digicamcontrol.com is the place to find packaged installers, since the repository itself does not document installation. ## Conclusion Adopt digiCamControl if you need to drive a tethered DSLR from Windows or from your own code and you are willing to work from a repository whose published releases stopped at 2.0.26 in 2016 while the last push was on 2026-10-15. Do not adopt it expecting a documented, current installer path, because the README carries no installation instructions and points developers to a separate documentation site. Before you commit, check the camera models your own hardware needs against the device layer, read the LICENSE file directly since the licence field could not be classified by GitHub, and confirm that the CameraControl.Devices package version you depend on is one you can build from this tree. ## FAQ ### How do I install digiCamControl? The README does not give installation steps. It points developers to the documentation site at www.digicamcontrol.com/doc/development/lib, and the project homepage at digicamcontrol.com is where the packaged application is presented, while the repository itself carries the build scripts and a Setup directory for producing a build locally. ### What is the latest release of digiCamControl? The two GitHub releases are 2.0.0, a stable release from 2015-12-24, and 2.0.26, a beta from 2016-05-06. The repository is not archived and its last push was on 2026-10-15, so the default branch is ahead of the newest tag. ### Can I use digiCamControl as a library from my own code? The repository separates the core library, the device layer and the capture workflow into distinct projects and three solutions, and the README directs developers to a developer documentation page for the library interface. The device layer is also published as versioned packages, including CameraControl.Devices.2.1.0-beta.nupkg. ### Which cameras does digiCamControl support? The README does not list supported camera models. The repository contains a Canon.Eos.Framework project, a PortableDeviceLib directory, an MtpTester project and a CameraControl.Devices project packaged at versions from 1.2.0 through 2.1.0-beta, so the supported set has to be confirmed in those sources or in the project documentation. ### What licence is digiCamControl released under? The README embeds an MIT style permission notice for Copyright (C) 2014 Duka Istvan, granting use, modification, distribution and sublicensing without restriction. GitHub could not classify the licence automatically, so a LICENSE file at the repository root is the authoritative text to read before redistributing. ## Sources - [dukus/digiCamControl on GitHub](https://github.com/dukus/digiCamControl) - [Issues](https://github.com/dukus/digiCamControl/issues) - [Project website](http://digicamcontrol.com/) - [README](https://github.com/dukus/digiCamControl/blob/master/README.md) - [Releases](https://github.com/dukus/digiCamControl/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dukus-digicamcontrol