cianmawhinney / visca-camera-controller Goto Github PK

Additional presets defined by storing the camera's position, focus etc in the software rather than on camera

Allow mapping axis and buttons of joysticks to camera functions.

Tie in with #24, ideally the web interface could be used to configure this. Potential flow:

1. Start editing joystick configuration
   • Specify either for joystick type (manufacturer id etc) or specific joystick (serial number etc)
2. Select functionality to be added
3. Have server watch for movement on an axis or button presses on that joystick
4. Next button press gets mapped to that functionality

• Make it prettier
• Support changing settings

• Update dev container definition
• npm scripts

Hi there, 1st of all thanks for your (voluntary) work !

In order to push the PTZ controller-software evolution, we're collecting/doxing related projects (yours too) in our HyMPS project (under a dedicated page), can you please fix - at least - licensing terms for it ?

Our "problem" is that the relative license badge isn't generated correctly, as you can see:

(generator URL: https://flat.badgen.net/github/license/cianmawhinney/visca-camera-controller)

This could be easily fixed by choosing a "correct" license file through the GH's wizard.

Although it may sounds like a minor aspect, this may help other devs to understand how reuse code in their projects which is a determining factor for the success and longevity of any open software.

Last but not least, we've recently opened a discussion about "near-zero latency multiple (IP) video-streams playing" - that could be useful for PTZ-control softwares too - to stimulate the confrontation on the topic between developers/maintainers.

Hope that inspires !

Balena is used to deploy application to devices, this should be added to the devcontainer with a bind mount to persist the config and auth.

Camera is very trigger happy to zoom in and not zoom back out - need to investigate this

Cameras have different capabilities depending on the model, affecting the interpretation of values in the VISCA packets.

Proposal is to create a generic implementation, then extend it to customise it for each camera. The generic implementation should check the limits of the protocol itself, rather than being based on any hypothetical camera.

May also be better to define a single object for all of these constants so that defining new models can be easier in the future, rather than the current approach of defining them separately?

Camera models currently available for testing:

• PTZOptics PT20X-NDI
• PTZOptics PT20X-SDI
• PTZOptics PT30X-SDI
• Sony BRC-300P

Camera specific properties

• Pan angle multiplier
• Pan angle limits
• Tilt angle multiplier
• Tilt angle limits
• Zoom multiplier
• Zoom limits
• Iris stops
• Shutter speed values
• Gain values
• White balance presets

Probably some kind of database would work best, though not sure what one exactly? Maybe a NoSQL one like Mongo?

Would be pretty handy to also be able to serialise the config to a file format like JSON though to allow for backups and import/export

Want to be able to make changes to the code, though it's been a long time since I've read through it

Unit tests should give me a chance to review the code & give me confidence in the future

In particular, the input classes could do with being an interface, checked by a compiler

Progress tracked in README.md

Side note: may want to move the resulting work into its own module/repo