Fixed the trivial bug: False ->0, and I added some functionality to t…

[aglinn]

…he boson necessary for correctly operating it in manual FFC mode. I also added the code necessary to turn on the smart averager function, and I believe your code previously did not allow me to connect to a specific BOSON camera based on the port, whereas now, if you pass a port to the BOSON object, it should connect to that particular BOSON, which is important for people like me connecting two cameras.

[jveitchmichaelis]

Awesome, thanks very much for this. Only a couple of things - could use logging rather than print statements? And maybe add some test cases for the get/set methods (I'm not sure how we can test the power-on defaults reliably).

[jveitchmichaelis]

I have some other modifications to make with how we check return values after receiving data so I'll get that in first and then I can make the adjustments to your PR.

Also tests should go in ./test/test_boson.py but let's maybe add that as another issue. We should make sure that the test doesn't get run if there is only one Boson attached, which isn't trivial.

[jveitchmichaelis]

Existing test suite passes for me, so good to merge - thanks!

[aglinn]

Thank you for cleaning up and finalizing my pull request! One other thing that has come up when working with two cameras: your find_cameras cpp code appears to find all device ids corresponding to Flir Video devices; however, the cpp code appears to return 0 in all cases, whereas I feel like the code should return the device id that was found to correspond to the FLIR video device. However, note I have never coded in cpp; so I may be misunderstanding the goal of your code, and I also could not figure out whether you find a list of multiple device ids if there are multiple Flir video devices or simply the first Flir video device's device id. Anyway, when using two devices, I needed two separate device ids and two separate ports. So, I fixed the python code to handle the ports correctly, but I could not get my corrections to your c code for the find video device to compile correctly; so instead I defeated your code and allowed myself to specify the device id rather than find it manually. This works, and I can use two cameras, but the more elegant solution would be to fix the actual c code to return all device ids associated with Flir devices. You may want to make that change. I could push my changes as well; so you can see where the problems are, if you want? But, I would not recommend using my work around as the most ideal solution.

Thank you again! You making this code base made my project feasible!

[jveitchmichaelis]

Not at all, thanks for contributing! I'll put this up on pypi shortly (should be live v0.2.2)

Yeah one thing I thought is that we should provide a method to enumerate the different cameras connected to the system. As you suspect, I currently just return the first ID that's detected. You do have the option of overriding here, when you call setup_video you can specify the device ID manually. But as you say it's not elegant.

But it shouldn't be difficult to modify the cpp code to spit out a list of valid cameras, rather than just the first one - ditto on Linux. This is actually a lot easier on Linux as querying the OS is more sane. On Windows we need to access dshow and I have no idea how to do that in Python.

Out of interest, what's your project? If you're able to share :)

If you're running multiple cameras, you might also be interested in some code I'm pushing to start the cameras in their own threads. That will potentially give you much better software sync, but obviously hardware triggering them would be best.

Take a look - https://github.com/LJMUAstroecology/flirpy/blob/master/flirpy/camera/threadedcamera.py

It's reasonably powerful, you can also add timers and pre/post functions that will run when frames are captured. Usage is simple:

from flirpy.camera.threadedboson import ThreadedBoson

camera = ThreadedBoson(device_id, port)
camera.start() # start running in a thread

... do your thing
camera.latest() # returns latest image
camera.camera.whatever() # access the underlying Boson class

camera.stop() # terminate thread

[jveitchmichaelis]

How do you figure out the port numbers at the moment? One thing that occurs to me is that it's not guaranteed (at all) that camera devices will enumerate in the same order as the COM ports do.

[aglinn]

Yeah, that is definitely not guaranteed. I figured it out manually, and I passed in the port for the camera, rather than finding it automatically. I think I made that change when I submitted the above pull request. Now, you can instantiate the Boson object with a specific Port. If the Port is None, then it defaults to your automatic algorithm for finding the port, but if the Port is specified, then I just connect to that port.

[jveitchmichaelis]

If you fancy being a guinea pig I can probably send you some test code to separately enumerate ports and cameras. Unfortunately I don't have access to two Bosons that often so it's very difficult to check this stuff!

[aglinn]

Yeah, if you send it over, I can test it out. It may take me some time, because I’m headed on vacation, but I’ll check when I return.

G

Sent from my iPhone

On Sep 3, 2020, at 1:48 PM, Josh Veitch-Michaelis notifications@github.com wrote:  If you fancy being a guinea pig I can probably send you some test code to separately enumerate ports and cameras. Unfortunately I don't have access to two Bosons that often so it's very difficult to check this stuff!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.