Leaderboard

I'm not sure if 8.0 is officially compatible with Vista (think so), but I have 8.0 running on Win7 (32-bit) without any issues. Ton

Maybe you should check out my presentation slides (both of theses were in the presentation): http://blog.jki.net/events/niweek-2011-five-clever-debugging-techniques-slides-and-code-now-available/

Thanks for the plug - there's actually a section in it that talks about OCR, and uses licenses plates as an example.

I got a solution for that(maybe it fits for you too): If you want to locate the plate, try geometric matching for the plate, make a template for the plate ignoring the content (chars and digits sequence) and keep only the borders. If you play a bit with the threshold and geometric matching, the program you build should be able to locate the plate with a high accuracy. For this you should make different templates and see which is the best(keep only borders, keep only the corners for the borders of the plate). Then you should be able to extract the matching and then do the OCR on it. Good luck!

QUOTE (flarn2006 @ Apr 4 2009, 03:56 PM) I accept your challenge. I believe that unrevealed features serve more benefit to users than harm, and I suggest that software that does not have such features is likely not innovating sufficiently.First, let us differentiate "unrevealed features" from both "undocumented features" and "undocumented behavior". Undocumented features are publicly exposed features, such as items in the palettes or menu items, that are undocumented. I am not defending developers who fail to communicate with their tech writers or publishing errors that result in documentation being dropped. It is poor practice to leave the feature hanging out there with no reference for the user who might invoke it. Similarly, undocumented behavior is behavior of public features in edge and corner cases for which no help is available. Common instances of undocumented behavior include the value of the output if the function returns an error, or the behavior of a menu item when the application is in a non-standard mode, or differences in behavior on non-dominant operating systems. These are hard to track sometimes, but nonetheless, they should be documented. No, when I speak of unrevealed features, I mean things that you need either a special config token or a special license key to access, features that require an input file that can only be generated by hand-editing the file, or features that require a long series of keystrokes to activate (Up, Up, Down, Down, Left, Right, Left, Right, B, A, Select, Start). Some of these features are what we call "easter eggs" -- little surprises that have no effect on how you use the software but are fun to discover, such as "SuperFunkyPrivateSpecialSecretForumStuff=true" in LV 8.5 only. Those are fun, but are not true unrevealed features. No, what I'm talking about is truly useful functionality of software. In LabVIEW, the first item that everyone will list is VI scripting, the ability to make calls into the LV editor that let you make programmatic modifications to a VI. But there are smaller features: custom wires for classes that go way beyond what the dialog will let you edit; plug-ins to the Project Window; password access to certain block diagrams. These are the sorts of features that I am suggesting it is right, well and good* for software to include. I believe, first of all, that unrevealed features can add to the usability and stability of software. To say that I have made a feature unusable by users for the sake of making the software more usable is not a contradiction of terms. There are plenty of tricks, backdoors, hacks, etc, that can cause myriad problems. For example, LV has an event structure. With this structure, you can catch events fired by the UI. There are private events that are not listed in the structure's configuration dialog. Why? Because some of those events look useful, but if you don't use them right (put too long a process in those event handlers, or use them in parallel with some specific other process), you end up hanging all of LV and having to kill it and restart. Should a regular user see such events listed in the config dialog? I argue no. They are system specific events that are only needed in the most rare of occassions. By exposing them privately, LV is able to write more of its functionality in G code, which means that higher level functions can be easily exposed as subVIs for users' general consumption. If customers are having problems and come to us absolutely unable to solve a problem without a particular event, we may give that particular customer a customized handler for that event. But there is no point to having regular users think they are using something useful, having it hang on them, and then having them believe that LV is somehow inherently unstable. Even burying such things in an "Advanced" pull-right is no help. 19 years of programming has taught me that users will open every menu, will click on every button, and then blame the developer when things go awry. Telling a user "Sorry, you're not advanced" seems to just upset them. It is far better for the collective user experience to to have those users that actually are advanced go hacking through files, trolling through forums, and wheedling insiders for secrets than to put generally useless junk in the interface, even if that junk is extremely useful in the .01% of cases. Unrevealed features also foster innovation. When a feature is not complete, should LV not ship it until it is finished? Or is it better to ship it behind a config token and then call a few key users up and say, "We think this works, would you give it a try and let us know?" We've gotten a lot of feedback over the years by doing this. Some of you who are alliance members or LV Champions may be reading this and thinking, "What? I've never been asked to test secret features, and that's part of my role as alliance/champion!" Don't get mad -- most of the time it is an individual developer who drops such half-finished features in so they can be used completely within National Instruments. You're not being left out of any secret beta. And, to be perfectly honest, most of the time you guys find such features anyway. It is a hard balance to strike -- users want stable versions of LabVIEW, but they also want development of new features, and they want some way of knowing which features are safe and which are not. On the flip side, NI doesn't want to be maintaining multiple versions of LV simultaneously if we can possibly avoid it -- that's very expensive. So for certain features, this "hide it and take the feedback of those who find it" approach is extremely valuable. If you had to enter a config token by hand, or if a certain node only worked when you dropped it at least 16,000 pixels away from the origin, or if you had to adjust your contrast way way down to even see something in the palettes**, you can be pretty sure that it is not considered to be on the "safe and trusted" feature list. Finally, unreavealed features show good use of developer time. There are certain operations in LabVIEW that you can trigger from the menus that are complex sequences of operations, and there may not be any way to trigger one of those substeps by itself, or to stop the process midway through. If we took the time to put a nice clean UI on every bit of LV functionality, we'd never ship anything. The rendering system of LabVIEW may use the OpenGL library under the hood, but that doesn't mean we take the time to wrap every OpenGL feature and expose it as a LV VI. The LV Project may be able to register with the OS to get updates when a file changes on disk, but that doesn't mean we take the time to provide a way for a user to register interest in files of theirs. It might be done eventually, or maybe not. Developers spend time on the features they think will be most valuable to users, and along the way they may include any number of smaller features that users have no access to. They may put all sorts of notes in the save format of files to support those features, bits that are not intended for users to twiddle. Providing twiddling access means supporting error conditions, means documentation, means tech support, means time lost to other projects. Sometimes it is better to just leave the feature hidden. In summary, I believe that unrevealed features support the values of usability, stability, innovation and accelerated development of more valuable features. I would be very interested to hear flarn2006's position on why such features are some combination of wrong, bad or evil*, and what value propistion he/she feels is gained by deliberately minimizing the existence of such features. * Right/Wrong: is this thing acceptable by some observer's subjective standard; well/bad: is this thing acceptable by its own internal standards; good/evil: is this thing acceptable by some objective standard agreed to by the debating parties. ** To the best of my knowledge, there are no easter eggs hidden at 16000 pixels from the origin or in nearly the same color as the palette background. These are just ways I've thought of over the years to hide easter eggs.