Chris Davis

I had problems with this error too. I thought I had it setup to log the files, but apparently not, I just had it ignore that error. Perhaps Jim can change the tool to log which files had that error for everyone. BTW, thanks Jim this has saved myself and the guys I work with lots of time! Chris

Thanks Jim, I just installed LV 8 today, and was dreading the mass compile for 8.0.1. I'm not even going to bother trying to see what the compile time would be without your tool.

Do you mean "Can LabView open an image (like a JPG file), scale it to 256x128 then write a new image (JPG) out?" If that is what you are asking you might check out George Zoo's Image toolbox. http://www.geocities.com/gzou999/ I don't know of a pure G implimentation out there but I would love to be proven wrong! Chris Davis

Kahn, There isn't built in support avaliable, but I can tell you it can be done. My group has written a DLL that interfaces to all Matrox boards (Meteor II CL/DIG and Helios XCL) which exposes easy to use LabView-friendly DLL calls. Send me a PM to talk more. This topic can get complicated. Chris Davis

Well, you didn't provide quite enough information to solve your problem, but I might be able to help with a couple of things... Your "saturated" image is probably because you are adding up grayscale images and attempting to look at the result in a picture control. If you are adding the numbers up and storing the result in a u32 you should display the result in an intensity graph. In the intensity graph you'll be able to use the automatic scaling on the z axis to display the image with some kind of control. If you can provide some kind of idea of exactly what you are trying to do, maybe we could help more.

I haven't had time to look at the code to solve the memory leak, but I have started an OpenG project to begin to make the LabView SQLite toolkit a reality. I've created a Requirements Document to state the project goals for those who want to be involved. This document is avaliable through the OpenG CVS system, so you'll have to check with Jim Kring if you want to be able to contribute to this project. I'm posting the first draft of the Requirements document here for everyone who was interested to review. Chris Davis Download File:post-2547-1139455457.doc

I don't know much about PostgreSQL either, but this might be a time to check out the idea of using SQLite with LabView, and join the LabView SQLite toolkit work we are doing at OpenG.org. You can contact me by PM if you have any questions. The LabView SQLite toolkit is posted in the LAVA forums by following the link below. http://forums.lavausergroup.org/index.php?...=2570&hl=sqlite

BTW, the VideoCapX ActiveX control is $80 for a single developer with free redistribution rights. That's $80 total cost, for a control that captures, edits, recompresses and allows you to playback AVI, MPG, and WMV files. I don't own stock or anything, but that is not a bad cost for all you get.

I've got no help for you, but I have recently purchased some cFP-1808's and would like them to show up on Linux and Mac systems too. I just read a DevZone post about the same request. NI's only solution was to use the Optomux protocol, even though they wouldn't offically support it. Good Luck. Chris

Pretty cool Jim! That could be useful when you have to display a cluster to a user, and you want it to have a different look than the standard LV cluster. Chris

I've used VideoCapX from www.fathsoft.com (which it sounds like what you are using) and not experienced this problem. There is a sequence of events that are required to set the video resolution (I don't know of a way to change the default settings) and I think that sequence goes something like this. 1. Connect to device 2. Set which video input you are going to use 3. Set the video format to the desired width and height 4. Preview the video If you have Visual Basic the included example will show you some of the other steps on how to connect with the video capture card and get the settings you want. If not, you'll have to read the help file and try to figure out what order you need to call the correct activeX methods to setup the card the way you want. Chris

I'll take a look today or this weekend to see if I can figure out what is going wrong and causing the memory leak. If I find it I'll upload another version. The next step is to make a database with some blob data in it to see how to access that type of data easily. I'm thinking of a simple database with some JPG's in it to start with. That is my original use case for this particular project so I think I'll try doing something along those lines now. I'll have to find the memory leak first, since when you start working with Blob data, your memory usage goes up dramatically. Chris

You've asked an interesting question, I'll give a couple of answers. Solution 1: Purchase an ActiveX toolkit to read image data from webcams. My favorite is VideoCapX from www.fathsoft.com. It costs $80 and not only allows you to display the video from any WDM source, but also record that video, take snap shots from that video, replay a recorded video, recompress a recorded video, record striaght to MPEG2 (if your hardware supports it), broadcast the video via HTTP, and many many other things which I can't recall. As a student I know you may be saying $80 is a lot of beer and pizza, but it will make whatever project you are working on so much easier you will be thankful you spent the money. They give you a free fully functional version to work with, and it pops up a dialog every now and then to let you know you are using the demo version. Solution 2: NI has a free USB driver for WDM sources, but it requires you to have LabView 7.1 and Vision Assistant 7.1 which may be out of the question. Solution 3: Roll your own DirectX DLL that will talk with the camera. I don't know if the $80 you saved will buy enough pizza and beer to make this worthwhile. Solution 4: Look at the free crossplatform (windows and mac) QuickTime library that has been around for a few years, it may do everything you want, if all you want to do is display the image. I tried using it about a year ago, but have lost track of it since then. All of these solutions will require some level of LabView experience. If you don't have much experience, this may not be the best project to learn LabView with. Chris

All, I've worked a little on the LV SQLite Example I uploaded yesterday, and I found a much better function in SQLite to execute and retrieve all the data from a SQL statement. As such my DLL now has three functions exposed to the user, Open, Close, and Execute. Take a look at the reworked examples to see what I mean. Chris Download File:post-2547-1138317174.zip

I've been using the OpenG Toolkit for awhile, in fact the INI config VI's is the first reason I started. For the last several projects I've used them on I develop a functional global to provide read and write access to the INI file's variables. This allows me to use any of those variables in any part of my program. You should probably check out a different architecture for your code to make less use of locals. You should be able to get by with one instance of a local for every control you want to update from the INI File. Simply call this case of a state machine to update from a change, or on startup. I personnally use a state machine architecture, which is probably the most popular. There are some shipping examples with LV, and probably some on this forum for you to research. Chris

Here is a zip file of the example code i've developed. I'm having some trouble getting all the rows to read back in from the example database I've included. Maybe someone can help? BTW, all code was written in LV 7.0 for compatibilities sake. Chris. Download File:post-2547-1138229920.zip

Thomas, You can call that particular function directly from the SQLite DLL, but when I tried to interfact to it directly on some of the functions that actually execute SQL commands or deal with the database I crashed LV. I may be wrong, but I'm sure it will be easy to see when I've uploaded the interface code. I'll be through with my interface and example code soon and someone who has done this before can begin to look at what I've made and make it better. That's the idea behind open source isn't? Thanks, Chris

Jim and Michael, Give me some time to finalize the DLL and put up a set of LV Vi's and an example database. I'll work on this today and hopefully post it this afternoon. Chris

No, I don't know of any efforts in this area, but I wouldn't be surprised if they existed somewhere. Chris Davis

Not a problem. SQLite is an embedded database, which means that the database you create is just a single file on your computer. This single file can be backed up easily and even moved across platforms (windows, mac, linux) to be read using the appropriate SQLite DLL ( or shared library on other platforms). It claims speed as one of its advantages, but I can't back that up with any hard numbers. In my case, the speed of execution is not as important to me as other properties. I'm mostly interested in the ability to access data with SQL commands without having to install and maintain all the seperate database administration tools and packages on the windows platform. I'm interested in the "crossplatform-ness" because I run LabView on the Mac and Linux as well. As for access with ODBC, there are some ODBC drivers / wrappers for SQLite, but I haven't played with them yet. There are also some ADO drivers / wrappers for SQLite but I have had little success getting those to work in LabView, and of course they ruin the crossplatform idea since they are activeX based. I've created a CVI based DLL that can be called through LabView that lets you read and write to / from a SQLite database. This DLL simplifies the process of calling the SQLite DLL from LabView by taking care of some housekeeping and reformatting of data that are needed to make LabView happy. My initial test case is a program that I am attempting to write to allow a user to load and crop a directory of images (JPG's) with a thumbnail display to let the user select the image they want to crop. I was thinking about processing the thumbnails once and loading them into a SQLite database as blob data to be retrieved the next time that directory is called up. I am also going to try and provide non-destructive editing by logging the crop parameters into the database and executing them only in an export step when the images get uploaded to a web page for viewing by the general public. I know some programs like this exist out there now, but they don't meet all the needs of my particular user, and thus I've been asked to research the idea to see if I can do it without breaking the bank. Hope this provides a little more information. Thanks, Chris Davis

I've been working with SQLite 3 (www.sqlite.org) for the last couple of days. And had good success with and had some good success in developing a wrapper for SQLite that can easily be used in LabView. I'm writing this wrapper in LabWindows/CVI, but it is all standard ANSI C, and not very much of it anyway. I was wondering if there is a call for an embedded database like SQLite in the LabView world. I don't use databases very much but when I ran across an article about SQLite I couldn't resist toying with it. I have no problem posting the code, if there is interest, and I think it could prove to be a useful addition to the OpenG toolkit, if there was a call to develop it into a library compatable with OpenG. One nice thing is that SQLite is at least as cross-platform as LabView! I await your responses! Chris Davis

Is there anyone interested in setting up an open source alternative to the IMAQ Vision toolkit using OpenCV. I've done some preliminary work to see if it is possible, but before I go offering up my work so far I was curious if anyone was interested. I think this would be a good addition to OpenG's set of tools, but I thought this forum would be a good sounding board to see if such a toolkit would be desired. If this topic is of interest to you please reply to this post, where we can begin to work out some of the details. Thanks, Chris Davis