Added blackfly support to FLIR camera class

[jeffmoffitt]

The blackfly and grasshopper cameras have a slightly different parameter sets and handle exposure times differently. I made the following changes to address these issues:

1) Camera-specific values are now set by a element in the config.xml file. I have provided an example for a blackfly and for a grasshopper.

2) There is a parameter that controls how the camera sets its maximum exposure time.

3) Different valid values for 'LineSource' are handled by checking a camera-specific parameter. There is probably a more elegant solution to this issue.

I also fixed a minor 'bug' in the maximum frame rate wherein the cameras can crash the first time a frame rate is requested if it is larger than the hardware maximum.

All changes were tested with a grasshopper and a blackfly camera.

[HazenBabcock]

I think your changes regarding AcquisitionFrameRate are as problematic as the current approach. By setting max_value to the maximum value of the current frame rate you have essentially set the default maximum value for this parameter to 30 fps. I believe that if you now drag in a parameters file for a smaller ROI that specifies a higher fps (like 100) you will find that the fps silently and unexpectedly gets changed to 30 fps. I don't have any good ideas on how to fix this, but I prefer the way that it is now because at least the failure is obvious, or at least obvious up to 500 fps at which point the current approach fails in both ways..

[jeffmoffitt]

I see your point. However, in this case, I find that the situation you propose is actually not a problem. If load a parameter with a high frame rate and small ROI (say 100Hz and 1024x1024), hal properly configures these values for both the grasshopper and blackfly. I suspect that this behavior arises because of the order in which parameters are updated: ROI first, then frame rate.

However, there is still a problem with the proposed solution, as the maximum frame rate used to set the limit on the parameters editor when hal loads is set by the prior configuration of the camera, which, if the ROI was smaller, will allow the user to request a frame rate that is not possible and crash hal.

It might be possible to fix this problem by setting the 10Hz frame rate in the initialization of the pointGrey camera class prior to configuring the range of the frame rate.

However, I am also happy to switch back the class to set the default frame rate max at 500Hz, which will be overwritten once the user sets the frame rate or another camera parameter once.

What do you prefer? (And thanks!)

On Thu, Jun 18, 2020 at 10:23 AM Hazen Babcock notifications@github.com wrote:

I think your changes regarding AcquisitionFrameRate are as problematic as the current approach. By setting max_value to the maximum value of the current frame rate you have essentially set the default maximum value for this parameter to 30 fps. I believe that if you now drag in a parameters file for a smaller ROI that specifies a higher fps (like 100) you will find that the fps silently and unexpectedly gets changed to 30 fps. I don't have any good ideas on how to fix this, but I prefer the way that it is now because at least the failure is obvious, or at least obvious up to 500 fps at which point the current approach fails in both ways..

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ZhuangLab/storm-control/pull/108#issuecomment-646051986, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAUJAXEGIDYFP47KJQUBFODRXIPO7ANCNFSM4OBS4NFQ .

[HazenBabcock]

I just checked this and the problem is as I described. The initial parameters are the default parameters. When you drag in a new set of parameters the proposed new value of AcquisitionFrameRate is compared to the max_value of the default parameters, and if it's higher than max_value it is set to max_value even if this inaccurate. Yes once the parameters are loaded you can edit them and change AcquisitionFrameRate as you expect because HAL has had a chance to update the allowed range (which is only done for the current parameters and not the default parameters).

Anyway a hack fix that is probably "good enough" is to set the initial max_value to some really large number like 5k and then explicitly check that the new parameter value is in range in the camera driver or in the newParameters() method.

[jeffmoffitt]

Interesting, I ran what I think is the same check. I created a new parameters file with a small ROI (1024x1024) and a frame rate allowable with this small ROI but faster than is possible with the default ROI. I restarted hal and added this parameter file via drag/drop. When I select this new parameter, the frame rate is set properly without any intervention by me. Moreover, the camera collects frames at the expected rate, not the previous maximum value.

Nonetheless, in lieu of a better idea, which I don't have, I like your fix. I'll implement and revise the pull request.

Any comments on the other aspects of this pull request before I do so?

Thank you!

On Thu, Jun 18, 2020 at 4:03 PM Hazen Babcock notifications@github.com wrote:

I just checked this and the problem is as I described. The initial parameters are the default parameters. When you drag in a new set of parameters the proposed new value of AcquisitionFrameRate is compared to the max_value of the default parameters, and if it's higher than max_value it is set to max_value even if this inaccurate. Yes once the parameters are loaded you can edit them and change AcquisitionFrameRate as you expect because HAL has had a chance to update the allowed range (which is only done for the current parameters and not the default parameters).

Anyway a hack fix that is probably "good enough" is to set the initial max_value to some really large number like 5k and then explicitly check that the new parameter value is in range in the camera driver or in the newParameters() method.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ZhuangLab/storm-control/pull/108#issuecomment-646277773, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAUJAXFT267AT6NVGMYAKITRXJXHXANCNFSM4OBS4NFQ .

[jeffmoffitt]

Thanks for your off-line comments! I have incorporated the changes we discussed into an additional commit. I've tested with both a grasshopper and blackfly camera. Indeed the parameters editor allows one to select an invalid parameter initially, but when you update this value is coerced to range properly.

[HazenBabcock]

Thanks!