Hi,
I have an annoying problem in my Python/USB setup. (Python 3.8 with needed fixes)
My Python app works fine acquiring frames, except from the first run after a camera boot (USB cable unplugged/plugged). The first run always gives totally distorted frames with only diagonal lines in different colors. Stopping and restarting the application resolves the problem. No problem in GeniCam browser and my app works fine if I do a GeniCam browse before first app start.
I’m using “with cvb.DeviceFactory.open(…) as device…” and have tried all kinds of “dummy” opening/closing/start/stop/sleep in my app before starting the actual frame acquisition but nothing helps.
Seems like something is not initialized before first start but I can’t figure out what that is? I’m writing my settings to node_map before start and that works fine.
Any help is appreciated!
Can you please post a screenshot of one of the distorted images here?
Diagonal lines actually sounds like a testpattern…
I assume you are loading the GenICam.vin, which you have configured via GenICam Browser before?
Ok, slightly different behaviour now. No diagonal lines on this test but a very strange picture on first run.
The “Black and white” picture is from first run. After stopping and restarting my app I get the color picture.
Do you set nodes like image width / height or pixel format?
Since the buffer for the images are being allocated when loading the driver, changing the image size will lead to a mismatch between buffer size (and it’s interpretation) and the actual data you receive.
To avoid a driver reload by hand, you can use the ImageRect Interface like so:
Fantastic! That was it!
I am setting pixel size and pixel format so this was obviously the fix. That also explains the two different distortions as I changed cam pixel size between those tests.
The picture looks good now but should I do similar stuff for the pixel format change I do in my app?
Cam boots with RGB but my app changes that to BayerRG8.
Anything that changes the arrangement/interpretation of the data inside the buffer should be followed by an update call as there is no automatism that allows to detect these changes (there is no device/manufacturer-independent convention or mechanism that would allow a software to know that changes to the value of a node X means that the buffer layout (widht/height/stride) has been affected).
Ok,
I was more wondering about the exact update call for pixel format? I can’t find anything specific for that?
Is it the same update call as for image size, i.e “device.image_rect.apply_size(…)”
Thanks a lot!
It was not crystal clear to me that the class described as Image rectangle operations on a device would be used for updates of “non rectangle” settings as well But now I know!
Thanks a lot for quick response. It’s working great now!!
You’re absolutely right, this is far from intuitive… It’s located there because the image rect operations just happened to be the first where this became an issue (this used to be at a time when dynamically changing parameters like binning, colour mode etc. were almost unthinkable…), which is why the function ended up attached to the image rect interface. Maybe we should consider moving it to a more prominent location when we integrate the new acquisition engine of 13.3 into the object-oriented wrappers…
Thanks! Probably a good idea to move it around a bit for easier understanding . Been doing some heavy Python/USB development this autumn so if you are interested in feedback I’m happy to share.
to detect these changes (there is no device/manufacturer-independent convention or mechanism that would allow a software to know that changes to the value of a node X means that the buffer layout (widht/height/stride) has been affected).