Skip to Main Content
Improve Capture One

Request a new feature, or support for a camera/lens that you would like to use in Capture One.

Status Awaiting review
Workspace Feature requests
Created by Henri-Marcel Hoogewoud
Created on Apr 20, 2025

End support of windows 10 -> switch to linux

With the end of support of Windows 10, a lot of people should ditch their fine working PC because of compatibility requirements of Windows 11. A lot of people consider this as a huge environmental catastrophy and therefore are switching to Linux. There are a lot of programs that can replace Windows programs but not Capture One, a program which as a passionate amateur really appreciate. So please consider creating a linux version (even with no thethering...), it shoul not be too difficult as you have already windows, mac and tablet versions. So please....

Current workaround

none

  • matt windover
    May 24, 2026

    I did drop this in another thread but realized it was closed so I'll put it here.

    i think a lot of the discussion on linux in the forums misses the actual business case for a linux version. this isn't just about personal os preference or open-source philosophy; it’s about untapped b2b volume licensing and enterprise revenue. there are three distinct avenues where capture one is leaving money on the table:

    1. studio volume licensing: high-end vfx, 3d animation, and major film pipelines operate almost entirely on linux. right now, these studios are forced to maintain separate windows or mac machines just for artists to process raw photo references. if capture one supported linux natively, these studios would purchase volume licenses to integrate it straight into their centralized pipelines alongside tools like nuke and davinci resolve.

    2. enterprise e-commerce (headless server): if redesigning the ui for linux desktop environments is the main bottleneck, consider a headless linux version of the raw processing engine. massive e-commerce studios and commercial catalog companies use linux servers to automate and batch process tens of thousands of raw files daily. a cli or docker container for the capture one engine would let you capture that enterprise-tier server volume without needing a full graphical desktop port.

    3. the low-friction compromise (proton/crossover): if a native port is completely off the table due to dev resources, the easiest middle ground is valve's proton or codeweavers crossover. valve has already done the heavy lifting to make complex windows software run seamlessly on linux. spending minimal qa time to ensure the windows installer doesn't actively block proton/wine compatibility would take a fraction of the time of a native port, but it would completely remove the bottleneck for linux users who actually want to pay for a subscription.