I would like to have the ability to add a simulated imaq camera in max to use with the imaqdx driver.
The camera should be able to specify wither it is linescan or area scan, as well as sensor size and specifications. The simulated device should support the basic property nodes (AOI, exposure line or frame rate ..... could even have a xml for iGenCam). Ideally the source of the image (directory) could be specified so that grabs or snaps would play back previously acquired images or a test pattern could be selected instead.
I might be asking for too much, but this allows for offline testing on vision systems, something that is common after deployment.
When I have a camera with a parameter out of range, I cannot open the connection to this camera with NI-IMAQdx, the only way to connect with the camera is to use another Pleora Software like GevPlayer to communicate with the camera. This SW can open the connection and in the parameters outside the range it puts a sign (!) in front of the parameter.
my idea is to allow to open the connection with the camera the result is not an error but a waring indicated the first parameter that is out of range, with this we can correct the parameter and continue capturing image.
The function (IMAQdx Configure Grab.vi)it should return error in case a parameter is out of range, but function (IMAQdx Open Camera.vi) it should not return an error but a waring as said before.
The same with CameraValidator only returns an error code which means (unable get attribute value)
I don't know what the current official status of AIPD is, but the polymorphic "IMAQ Write File 2" VI which is in the LV palette does not offer AIPD in its selector. For me this means that there is no official support for AIPD anymore.
Unfortunately there is also no alternative for storing SGL or complex images.
My request: Add the AIPD format as an officially supported file format to "IMAQ Write File 2" or offer an appropriate alternative for all image types.
I feel there are some IMAQ Vision overlay VIs that would be useful.
1) Get Overlay Groups - Returns an array of Group Names and number of items in the group.
Useful for example - check if "Legend" overlay exists so don't write it again.
I don't see how to tell if overlays are written on top of each other... hence number of items in group (text, line etc) would be useful to look for overlay memory leaks.
Provides a way to tell if any overlays on the image as it returns an empty array if no overlays.
2) Clear Overlay Except
Currently can clear specified overlays, or all overlays, but no way to clear everything except "Legend" overlay unless you create code to keep track of written overlay groups so you know what to clear.
The title says it all, but let me expand a little...
Since LabVIEW 8, trying to create a VI from a selection containing a reference to an Image Control fails. It does absolutely nothing, nada, nitchevo, nichts, rien...
There are at least TWO CARs about it: 54165 and 35835.
Yet, years after years, nothing is done about it.
A workaround for creating VI is to remove the connections to any of the image control references in the original selection, and once in the created subVI, drop a custom control that you will have strategically dropped in your Favorites Control Palette:
Then you need to add it to the connector pane, reconnect in the original calling VI...
Not the easiest but manageable.
Now, what about managing events using a Register Event node handling several controls, including a couple of Image controls? Usually, when not using images, I bundle references to the controls and do the Event Registration in a subVI (there are typically a lot of wires and large nodes involved, therefore this would take an undue amount of real estate in a main VI).
The problem is, any cluster containing a Image Control Reference can apparently not be created as a control in a "Create subVI" or even a "Create Control" operation:
Once again, it is possible to do all this manually, but if you have a bunch of Image Control references and other references to bundle, this is becoming rapidly tedious.
there are some vi in vision toolkit that their controls have not any useful information in labview help for user so many ability of these vi are not discovered by LV user like me for example IMAQ Particle Filter have input control with name of selection value inside this cluster we have item with name of Measurement Parameter that have many mode to select but no detail information for them to know what kind of ability they have I think in next version of this toolkit it should be release with enough information about these controls of such vis
This will be useful to deploy projects to end-users more easily. Currently, NI only provides the USB Dongle Solution for LabVIEW, TestStand, and LabWindows™/CVI™. More software into this USB Dongle will provide more flexibility in the licensing options to deploy to end-users.
It would be really great if there was a way to have one function "Set Exposure" that would work for most cameras. This is analogous to how in IVI, you can have generic instruments and use the generic drivers to control them. Maybe we could assemble some sort of user driven database file we could download to provide a look up for the correct attribute for a given camera.
Another option is to iterate through the list and see if any of those attributes are present on the given camera and apply the setting to the one that's matched.
There's other really common settings like exposure mode (auto vs manual), gamma, gain, pixel format, etc
When merge overlay is performed on image with multiple overlay groups, it merges selected group (correct) and clears all others (wrong!).
It seems that it should affect only what has been said to it (selected group), and do not touch what belongs to somebody else. If you need to kill all other overlays, use clear overlay after it. Or new version needs a switch to not kill other groups - for compatibility.
I want to view the camera image collected through the capture board through LabView. The camera I'm using is a Fluke IR camera, and it doesn't support connection the same way as a regular camera. That's why I'm trying to do the display through the capture board. When searching for previous experiences in the community, there were cases where VMS (Video Measurement Suite or Video master) solved this problem, but I couldn't find VMS. This seems to be an unsupported feature already, is there any other way?
I like this community platform and I would like to know the name of the platform this community was built on. This is not a joke or a cheap attempt to advertise for the platform. If you could reply to me in some way to let me know I would greatly appreciate it.
IMAQdx Snap VI is provided for ease of use as a quick way of making occasional shots. However, citing VI reference:
NI-IMAQdx VI Reference Help:
If you call this VI before calling IMAQdx Open Camera.vi, IMAQdx Snap2.vi uses cam0 by default.
This "feature" is not useful for making quick shots and it makes this VI quite useless in general, because it forces you to manually open and close the camera (what this VI would do as well for unopened camera) every time you want to make a quick shot.
With just a little bit more effort (4 VI vs 3) you can make a usual Grab acquisition.
It's OK to have cam0 as default value, but when Session In terminal is wired please make this VI open the camera which the user actually passed.
It's a very easy change, but making it on a user side is not the best idea.
Please reconsider the decision to drop support for IP cameras. I just had the unfortunate experience of discovering that my application developed in Labview 2018 will no longer support the hardware we have in our department since I've upgraded to 2019 SP1. We have thousands of dollars invested in IP cameras, and with NI's decision, we can no longer use Labview as the data acquisition development software.
I'm working on a school project which is a resistor sorter. I'm tried to use the color segmentation from the Vision assistant but I couldn't get a match because the clasifier I used was based on a resistor and can't be used if I changed the resistor. I've also tried this VI but I can't determine the color code via the RGB profil .
1/ How can I make a clasifier file to include all possible colors?
2/ How can I modifie my VI to get the RGB values of only the bars?
I've Labview 14.0, i have to make project involving recognizing colours. I installed Vision Acquisition Software 14.0 but there is something wrong because i don't have this blocks like IMAQ Particle Analysis, Reject Border ect... Is that IMAQdx driver missinng or i need some driver for Windows 10. ? Thank You for help 🙂
One of my problem for creating image processing project is to make a special overlay that should be rotate expand shrink or change in size, based on processed data in many times creating code for such overlay waste so many time for calculation and test because of so many geometry concept that we should regard and I have to allocate most of my time to solve this problem instead of using this time to solve processing problems that are more important than overlay I think if we have a assistant software in Labview like file ,daq,imaqdx and ... assistant in labview that we could use it for design special overlay and also define variant that should be change based on processing data we will be save so many time to allocate solve image processing issue instead of making an overlay I think it is possible to make such assistant and also I could help to NI to production of this assistant software
We have a critical need to apply a 4096 element U32 Lookup Table to our IMAQ images and were really hoping that it wouldn't be to hard to modify the existing shipped VI from the VDM package (IMAQ UserLookup 2 VI to be able to handle LUT's of greater bit depth.
This is of course a proprietary code from NI so we can't work directly from it. Has anyone one the community been able to write an (optimized) look up table VI/DLL which can take as input a 16 bit image and lookup to a 32-bit image depth?
Our application is correcting machine vision camera output frames for bit error and non-linearity corrections for which we need at least 22 bits of LUT so we decided to simply go to four byte pixel depths.