|
|
|
|
|
by adhesive_wombat
1465 days ago
|
|
If your software works only on Windows, you've written non-portable software. Likely, you have all your core logic mixed up with Windowsy UI and now you're stuck there. If it works on Windows and Mac, you've written portable software but just can't be bothered to support Linux. At a guess the problem is that you want to ship binaries only and don't want to deal with doing all the packaging and testing for Linux. For a consumer hardware company, one wonders what the benefit is to binaries-only unless you're hoping to charge a subscription for the software to run hardware you already bought. Or the software is such a mess internally that you'd feel ashamed of it were public (which I can understand, having seen commercial code). Or you have some security feature that you don't want to reveal (e.g. disallowing use of your software with third-party hardware). However, if someone wants to reverse your software methods, they'll find a way. Perhaps naively, my thought would be that if you want to sell hardware and not software, an excellent consumer-grade and consumer-priced camera platform with an open hardware interface and a decent reference implementation would actually find a lot of uses on embedded (i.e. probably Linux) platforms. |
|
The software postprocessing is a different question and could be more common... But you're still specialising it for DX / v4l2+gui / whatever macos uses. That said... I'd kill for an independent library for video processing that specialises in camera outputs - beyond different profiles, there's no technical reason that couldn't be used independently of hardware.