Home
Home copied to clipboard
nanoframework
Feature request: Library for using some of the most common camera modules
nanoFramework area: Other tools
Is your feature request related to a problem? Please describe.
I wanted to create a relatively simple device that would use a ESP32-CAM module with a OV2640 camera to take a picture and send it to a server, but found that there are no libraries for these cameras available in NF.
Describe the solution you'd like
A wrapper/c# library for using the most common camera modules, simmilar to what the espressif offers: https://github.com/espressif/esp32-camera
Describe alternatives you've considered
Nothing really comes to mind. It can only be c# managed code or an interop.
Additional context
This has already been discussed with @Ellerbach and we have come to conclusion that this would be no easy task. That is also the reason why I am unable to do it myself.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
It would be amazing indeed, the only reason that I'm not using nanoframework with the ESP32-CAM
@Ellerbach @josesimoes What do you guys think? Is there anyone who can do this?
@Ellerbach @josesimoes What do you guys think? Is there anyone who can do this?
@Luk164 sure there is! And I totally get it that this will be a great library for .NET nanoFramework. The thing is that time it's a finite resource and, so far, no one has either volunteered to code this or to sponsor the development.
Please keep in mind that this is a project running based on the good will of a handful of individuals, an insane amount of work for free and some conscientious commercial users that sponsor a portion of what you see here...
@josesimoes Thought that would be the case. Unfortunately this is way too complicated for me to even attempt. And I know the backlog is enormous, but I still hope this could be done as it is one of the biggest lacking features right now.
@josesimoes Thought that would be the case. Unfortunately this is way too complicated for me to even attempt. And I know the backlog is enormous, but I still hope this could be done as it is one of the biggest lacking features right now.
If a company would sponsor it because they need that in their product, that would clearly be a best case scenario. Now, if this is not happening, there are low chances this will be implemented especially as native code and managed code will have to be involved for sure.
I am also very interested because I am currently using 3 x ESP32-CAM and plan to use 4 more in the next 4 months.
On the architecture\design side, do we have any official guidance on how to approach problem like these?
Do we have any official guidance on how to approach problem like these, architecturally? @Ellerbach, what are the aspect of this problem that make it difficult to resolve? Compared to other similar problems?
On the architecture\design side, do we have any official guidance on how to approach problem like these?
Yes. Basically following the general approach and design that's being used in all other class libraries. This, like SPI for example, requires a C# API that relies on native code.
As been agreed that this will become an official class library for nanoFramework, there is a repository and initial work being done. @CliffAgius as gave the step forward and has offered to tackle this. Maybe other interested developers can join the effort. Suggest that you head over to our Discord channels. There is a thread about this matter under peripheral-drivers channel.
what are the aspect of this problem that make it difficult to resolve? Compared to other similar problems?
Technical difficulties are on multiple layers: the native side that needs to be generic enough to have multiple drives sharing the same core infrastructure like for the video drivers.
Being able to setup the specific parameters of the camera on the manage side (pins, size, whatever else), so the exposed C# part has to be generic whatever the module is.
Cameras like graphic drivers are intense in terms of memory and processing power. You'll need to manage most of the elements on the native side.
Offering advanced features to save on the native side the pictures, expose them properly on the managed side.
Some open questions on what can be reused from the Graphic native (and managed) library. There are already existing elements on image manipulation, saving, loading, etc.