|
Old snapshot showing up
keith from United States [12 posts] |
9 year
|
I am processing images from two cameras, and generally finding the response super slow - kind of like the script is preoccupied in doing something unhelpful. Occasionally I see an old snapshot displaying. This snapshot is from a couple of weeks ago and I don't understand why it keeps showing up.
How do I delete any old snapshots that might be stored with a script?
 program.robo
|
|
|
|
Steven Gentner from United States [1446 posts] |
9 year
|
Keith,
There is a picture (of lollipops) that is saved in the robofile. At one point you probably set the "embed image in robofile" checkbox in the dialog where you specify the filename to save (either image or robofile).
Are the cameras connected over Ethernet or are they USB cameras? What I think you are describing is when the connection fails it momentarily shows the default image loaded in the robofile. You can see this by disabling the first Camera module ... that will show the lollipop image that was loaded.
I don't see any execution issues. Perhaps you can post one example of each of the camera images that are present when the slowness happens. As the issue is very dependent on what images are currently being processed having those two example images would help us narrow down the slowness issue by replicating the problem that you are having.
Its also possible that if the cameras are connected via ethernet that a slow network is slowing down the image capture and sometimes breaking the connection which defaults to that image. If you look at the right side of the pipeline at the gray numbers those indicate the time taken by each module. If any of the numbers are above 01:000 that will indicate a problem.
STeven.
|
|
|
|
keith from United States [12 posts] |
9 year
|
How do I 'un-embed' an image? I tried saving the file with the radio button un-checked, but I see that the image is still hanging around.
Both cameras are USB. The processing timer display is really helpful - I hadn't understood what that was. One of my markers was taking over 2 seconds, and with the switches between the cameras the round-robin was over 3 seconds. I am getting that fixed.
The RGB filter doesn't seem to be active on it's second usage in my file (Step #8). I am enclosing a screen shot where you can see that something should be happening, but no affect.
The robo file is also attached.
Thanks, guys.
program.robo
|
|
|
|
Steven Gentner from United States [1446 posts] |
9 year
|
Keith,
You got it correctly ... if you uncheck that checkbox it will not save the image. So to undo it, just save over your exsiting robofile without that checkbox. To be really sure, you can load in that .robo file into a text editor. If you see a bunch of data fields with long numbers/letters then it saved the image, if not, you're good to go.
Wow, that's strange. I've not encountered a USB camera that takes that long to snap images! Is the camera working correctly? Or perhaps because its a digital microscope the images come very slowly? If this continues to cause slowness, let me know and we can add a parameter to not wait on a new image but use the old one which will speed up your editing of the pipeline. Each time the marker module is encountered it will wait for a new image to be sent before continuing ... this behavior can be changed.
Its hard to tell why the second filter isn't working ... since I don't have the camera that is specified in the Maker module just before it the image comes out all black (i.e. it fails). If you click on that maker module (just once) you can see what image is coming in from the microscope ... I suspect that image isn't looking quite right which is why the filter doesn't appear to work.
Out of curiosity which microscope are you using?
STeven.
|
|
|
|
keith from United States [12 posts] |
9 year
|
I have a pair of Plugable USB 2.0 digital Microscope that I am using as the cameras. There is a Generic Amazon 4-port USB hub between the notebook and the cameras, because I am running low on USB ports.
The image coming out of the Maker module (step #7) looks great and I have confirmed that it is a live image. There are no changes to the image when I mess with the RGB filter settings - but the image continues to be live. If I move Step #8 up to the top of the pipeline it works fine. If I bypass the 4-port USB box it still does not work right.
|
|
|
|
keith from United States [12 posts] |
9 year
|
Things seem to fall apart upon first usage of the 'Marker' module when I select the 'revert to'. The subsequent image is generally correct and live, but none of the tools seem to know how to reference to it.
I don't think that the Mfg of the microscopes (USB 2.0 Digital Microscope, USB2-MICRO-200X) has a driver that supports multiple cameras, but I am checking with them right now.
There have been brief intervals upon start-up where everything worked, and then something goes sour. I haven't been able to identify what initiates the disintegration.
If they don't have a multiple-camera driver, what are my options?
|
|
|
|
keith from United States [12 posts] |
9 year
|
This is the reply from tech support of the digital microscope. Would using a generic driver solve my problem? if 'yes', then which one would be most convenient?:
The microscope, without any software installed, will work with any normal webcam software. It will use the generic Microsoft video class driver that all standard webcams will initially enumerate under, and work with a default viewer like the camera app in Windows 8.
When I say that the software will only recognize one device at a time, I mean the MicroCapture software. The driver doesn't play favorites (actually as far as I know no driver does, a device will arrive and request a driver).
The one problem you might encounter is that the camera itself doesn't report a unique identifier, so some software has difficulty differentiating between the two devices. The system will identify the camera as "this device on this port on this hub", but if you change the port of the device then the system will think that it is a completely different unit, and re-enumerate it as such.
If the developer wants to contact us, I'd be happy to talk to him about any projects he has in mind. We're always interested in what people are up to!
Cheers,
Technical Support Analyst
Plugable Technologies
|
|
|
|
keith from United States [12 posts] |
9 year
|
'sorry for flooding this thread!
Actually, the issue could probably be solved by referencing to the camera by it's physical connection location on the 4-port hub. Have you already solved this in the past? I am using Amazon's 4 Port USB 3.0 Hub with 5V/2.5A power adapter (Amazon identifier HU3641V1), but could easily get a different hub at your suggestion.
|
|
|
|
Steven Gentner from United States [1446 posts] |
9 year
|
Keith,
Try using one of the cameras on the USB hub and connect the other on a different side of your computer/laptop (i.e. direct to the computer). The issue is that most cameras do not have a unique serial number for us to identify so they are enumerated based on what Hubs they are connected to. We've seen this issue often in the past and unfortunately there isn't a really good solution. Some drivers (like those by Logitech) don't have this issue regardless of the Hub used.
When you view the Options button->Video tab->Video dropdown menu do you see
Digital Microscope
Digital Microscope #2
in that list? The #2 is RR trying to distinguish between the two cameras. When it saves the selection it also saves the full path (i.e. hub, etc.) along with it such that next time it identifies the right camera. The problem that once in a hub outside of the computer that doesn't seem to work as well.
We'll try to see if we can replicate your issue with some other generic camera just to be sure things are working as expected.
STeven.
|
|
|
|
keith from United States [12 posts] |
9 year
|
Apparently Logitech gives each of their webcams a unique serial number. Digital Microscope does not. I will research Logitech and other vendors to see if I can find a pair of webcams with unique serial numbers AND and minimum focal distance of about 5 cm.
Are there any external USB hubs that do a better job of tracking plug-ins by position?
Do you know if there is such a thing as a flow-through USB dongle that could be used to add a unique identifier to each device?
|
|
|
|
Steven Gentner from United States [1446 posts] |
9 year
|
That's correct, unfortunately the serial numbers are optional and not added by all vendors (much to our frustration!).
I assume changing the connections to different sides of your machine didn't work?
The hubs are pretty much the same when it comes to this problem. There isn't any that really help to our knowledge. The only way is to get a different hub from your machine (i.e. the root) which seems to make a difference. After that, adding hubs ontop of hubs doesn't seem to help.
We did explore the possibility of reassigning the image to different markers based on some image property ... so if you can include a known marker in one of the camera images it is possible to simply capture both images and based on that marker process them differently. Bit of a hack but it can work. (i.e. include a visual serial number of some sort)
Don't know of any USB hubs that add a serial number ... maybe if one converts from USB to ethernet those converters do? Never really tried that.
STeven.
|
|
|
|
keith from United States [12 posts] |
9 year
|
Eureka - problem pinpointed!
I removed the USB hub, and am only using (1) camera. I also re-installed your hardware and rebooted my computer.
If I check the 'include overlay graphics' in the Marker module - the subsequent RGB_filter will NOT work. If I uncheck the 'include overlay graphics' in the Marker module, then the subsequent RGB_filter works just fine.
There is a bug in the marker module.
|
|
|
|
keith from United States [12 posts] |
9 year
|
|
Yup, everything is working great with the two non-unique webcams connected externally to a 4-port USB hub. I just have to stay away from the 'include overlay graphics' in the Marker module.
|
|
This Thread