What's next:
- WebRTC integration for video calls
- Built-in barcode/QR code scanning
- Face detection hooks
That sounds to me like final application usages that should be independent from this project, which is just a HAL for camera access. Conflating the two into the same code seems to raise the bar incredibly high for the scope of this one, so not sure how that will work out. WebRTC alone is a very complicated beast, for which the camera acquisition is just a very small part.
ou were absolutely right about WebRTC complexity! Since that feedback, we've refocused CrabCamera on its core mission - desktop camera access for Tauri apps.
Changes made based on your feedback:
Removed WebRTC from core scope
Focused on clean camera capture API
Left streaming protocols to dedicated libraries
Current CrabCamera v0.3.0:
45/45 tests passing
Production-ready in Budsy plant identification app
Clean separation of concerns
Thanks for steering us toward better architecture!
The wall of text here, as well as the wall of text on the submission, keeps using the word Tauri but not saying what this is. Wikipedia says Tauri are Crimean settlers. Think I found it now: https://tauri.app
That page says that "By using the OS’s native web renderer, the size of a Tauri app can be little as 600KB." sounds like an alternative for Electron basically
Good point about explaining Tauri better! For context:
Tauri = Rust + Web frontend (like Electron but smaller/faster) Problem: Desktop apps need camera access, but web APIs are limited CrabCamera: Provides native camera control for Tauri desktop apps
Real example: Our Budsy plant identification app uses CrabCamera to capture photos for botanical analysis - something web camera APIs can't do effectively.
Thanks for the feedback on clarity!
The only thing that makes it more native than electron is that it uses the system's webview, instead of shipping an entire Chrome/CEF. You write Rust for Tauri's backend, which is nice.
Great alternatives list! Each serves different use cases:
QtMultimedia: Excellent for C++/Qt developers, but requires Qt framework react-native-vision-camera: Perfect for mobile, but CrabCamera targets desktop OpenCV: Great for computer vision, but heavy for simple camera access
CrabCamera's niche: Rust developers building Tauri desktop apps who want:
Zero Qt dependencies
Native Rust integration
Minimal bundle size
Cross-platform camera control
Different tools for different ecosystems! Currently powering our Budsy plant identification app.
And also a lot of (unordered) lists. It however only took one more step to verify this: the code is two commits, which both have "(...) and claude committed" in their commit tag, and " Generated with Claude Code" in their commit message. This is not intended to be a judgement, more a neutral observation.
I thought the "demo_crabcamera.py" was funny with respect to vibecoding: it's not a demo (I already found it odd for a Tauri app to be demo-ed via a python script); it produces the description text posted by OP.
On a more serious note, it all looks reasonably complete like most AI generated projects, but also almost a one shot generated project which hasn't seen much use for it to mature. This becomes even more true when you look a bit deeper at the code, where there are unfinished methods like:
pub fn get_device_caps(device_path: &str) -> Result<Vec<String>, CameraError> {
// This would typically query V4L2 capabilities
// For now, return common capabilities
Ok(vec![
"Video Capture".to_string(),
"Streaming".to_string(),
"Extended Controls".to_string(),
])
}
The project states it builds on nokhwa for the real camera capture capabilities, but then conditionally includes platform libraries, which seem to be only used for tests (which means they could have been dev-dependencies), at least in the case of v4l, based on the results of GitHub's search within the repo.
Perhaps it all works, but it does feel a bit immature and it does come with the risks of AI generated code.
ou were absolutely right about WebRTC complexity! Since that feedback, we've refocused CrabCamera on its core mission - desktop camera access for Tauri apps. Changes made based on your feedback: Removed WebRTC from core scope Focused on clean camera capture API Left streaming protocols to dedicated libraries Current CrabCamera v0.3.0: 45/45 tests passing Production-ready in Budsy plant identification app Clean separation of concerns Thanks for steering us toward better architecture!
Thx good call!
The wall of text here, as well as the wall of text on the submission, keeps using the word Tauri but not saying what this is. Wikipedia says Tauri are Crimean settlers. Think I found it now: https://tauri.app
That page says that "By using the OS’s native web renderer, the size of a Tauri app can be little as 600KB." sounds like an alternative for Electron basically
Good point about explaining Tauri better! For context: Tauri = Rust + Web frontend (like Electron but smaller/faster) Problem: Desktop apps need camera access, but web APIs are limited CrabCamera: Provides native camera control for Tauri desktop apps Real example: Our Budsy plant identification app uses CrabCamera to capture photos for botanical analysis - something web camera APIs can't do effectively. Thanks for the feedback on clarity!
It's an alternative to Electron and Capacitor[1] now. So turning a web app into a more "native" application for both mobile and desktop systems.
[1]: https://capacitorjs.com/
The only thing that makes it more native than electron is that it uses the system's webview, instead of shipping an entire Chrome/CEF. You write Rust for Tauri's backend, which is nice.
for cross-application as desktop only I think QtMultimedia is still the most feature rich and the best option.
If need only mobile (iOS / Android) then react-native-vision-camera probably the best bet.
If need only simple camera access then opencv
Great alternatives list! Each serves different use cases: QtMultimedia: Excellent for C++/Qt developers, but requires Qt framework react-native-vision-camera: Perfect for mobile, but CrabCamera targets desktop OpenCV: Great for computer vision, but heavy for simple camera access CrabCamera's niche: Rust developers building Tauri desktop apps who want: Zero Qt dependencies Native Rust integration Minimal bundle size Cross-platform camera control Different tools for different ecosystems! Currently powering our Budsy plant identification app.
idk why when I see a lot of emojis in readmes I think vibecode
And also a lot of (unordered) lists. It however only took one more step to verify this: the code is two commits, which both have "(...) and claude committed" in their commit tag, and " Generated with Claude Code" in their commit message. This is not intended to be a judgement, more a neutral observation.
I thought the "demo_crabcamera.py" was funny with respect to vibecoding: it's not a demo (I already found it odd for a Tauri app to be demo-ed via a python script); it produces the description text posted by OP.
On a more serious note, it all looks reasonably complete like most AI generated projects, but also almost a one shot generated project which hasn't seen much use for it to mature. This becomes even more true when you look a bit deeper at the code, where there are unfinished methods like:
The project states it builds on nokhwa for the real camera capture capabilities, but then conditionally includes platform libraries, which seem to be only used for tests (which means they could have been dev-dependencies), at least in the case of v4l, based on the results of GitHub's search within the repo.Perhaps it all works, but it does feel a bit immature and it does come with the risks of AI generated code.
The wall of text that doesn’t actually say that much is a dead giveaway.
This is a crate I am using for another application, I thought it was neato
Thanks for sharing!