File Name: LVOOP ImageMagick Interface File Submitter: Justin Goeres File Submitted: 16 Jun 2007 File Updated: 12 Mar 2008 File Category: Machine Vision and Imaging File Version: 1.0.2 LabVIEW Version: 8.2.x License: GNU Public License LVOOP ImageMagick Interface V1.0.2 Copyright © 2007, Justin Goeres Engineering All rights reserved. AUTHOR: Justin J. Goeres (see enclosed README.txt for email address) DESCRIPTION: This library provides an LVOOP-based interface to the powerful cross-platform ImageMagick image handling utility suite. It supports all of the ImageMagick utilities and almost every command-line operator (over 200 of them) with support for custom user-specfied operators for the edge cases. Several examples are included that demonstrate basic text & image creation, composition, and conversion in and out of LabVIEW (including VI icon creation). GETTING STARTED: The first thing you need to know about ImageMagick is that it has a pretty steep learning curve. Complicated things are complicated, and easy things are sometimes complicated, too. The Example VIs provided with the project are intended to give you a basic start on how to use the library, but you should expect to consult an ImageMagick Examples Page frequently. COMPATIBILITY: The library is written for cross-platform usage, but is currently limited to compatibility with Windows because I don't have any non-Windows LabVIEW machines to write the platform-specific code on. If you can help out with compatibility for other platforms, please contact me. I would LOVE to hear from you. REQUIREMENTS: A working Windows ImageMagick installation. Tested with ImageMagick v6.3.4-Q16. Almost certainly works with later versions, and probably with earlier versions back to at least v5.4.8. (Personal testimonials on this are welcome.) REQUIRED minimum OpenG Packages: oglib-error-2.3.2 oglib-lvdata-2.7.2 RECOMMENDED OpenG Packages: (used in examples, but not in the core functions) oglib-file-2.8.1 oglib-array-2.5.1 KNOWN ISSUES: Currently applications built against this library throw a litany of execution errors when run in the RTE. If you need to build these libraries into an application, please contact me and I will try to help you. Functions for a few of the built-in pattern generators are not completely implemented. You can access them using a custom raw operator argument. SUPPORT: Comments, bug reports, and feature suggestions are always welcome! http://forums.lavag.org/CR-LVOOP-ImageMagi...face-t8461.html CHANGE LOG: 1.0.2: Fixed a localization bug in the generation of floating-point command-line arguments. Added a check for oversize command line length (System Exec.vi max is 32766 bytes). (11/26/2007) 1.0.1: Fixed an incompatibility with ImageMagick 6.3.4 when using certain operators. Added a better error message when ImageMagick can't be located under Windows. (6/19/2007) 1.0.0: Initial release (06/18/2007) LICENSE: GNU General Public License, Version 2. (Other licensing terms may be available. Contact the author for details.) Click here to download this file

Seems like an interesting project. Unluckily I cannot use this library in any work related project because of the virality of the GPL license you have used

Tomi,

Without getting into a religious war about licensing , I'd like to state that I've given a lot of thought to what license to release the library under, and I chose the GPL very carefully. My understanding of the GPL is that you may be absolutely free to use GPL-licensed code in work-related projects, but it depends on your specific situation and what you want to accomplish.

If you, for instance, are working inside a corporation as an agent of that corporation, then distributing your software within that corporate entity does not fall under "distribution" as the GPL defines it. I want to heartily encourage people to use my library in situations like this.

If, however, you are distributing those work products to others commerically or outside the corporation you create them in, then I specifically want the code to remain free. The correct license for a situation like that is the GPL.

If you have a suggestion of a better license to use that meets the above criteria, I'd be interested to discuss it. Also, if you have a specific situation you would like to use the library in that the GPL prohibits, please contact me -- I may be willing to license it under different terms on a case-by-case basis.

Thanks!

I don't think I will use this (for one thing I don't have 8.x and for another I don't really need image manipulation), but I do hope to take this as an opportunity of learning from an actual LVOOP example.

Is there any other kind?

My company prefers to use BSD components, as they're easier for us to include in commercially release software (everything we write). GPL and LGPL are a little more restrictive, and I think (I don't want to put any words in Jim's mouth) this is why OpenG dumped LGPL in favour of BSD.

yen,

I think that's a great idea. Honestly, I don't use ImageMagick very much (mostly scaling/rotating/format conversion) but it struck me as a great project to force myself to do a larger-scale LVOOP design (there are about 26 classes in all, and most of them inherit from a single base class):

There's a method in Command Line Operator.lvclass and its descendents called Translate to Command Line Operator.vi that is overridden in probably 20 different child classes. It's responsible for all the magic of building the cryptic ImageMagick incantations. LVOOP makes that single method beautiful to implement.

Moderator Note: The Code repository has a bug which caused this file to be currently unavailable. This will be fixed ASAP and the download will soon be available.

Actually GPL license is almost never used in a library. GPL licesne forces any project that uses such library to be of GPL license as well. So it's not only about keeping your library modifications open source and freely available but also about forcing all the work that uses that library to become open source and freely available as well. You surely understand that this is a very restrictive license term for a library.

I prefer BSD licensing as well. However if you are not comfortable with BSD licensing, please take a look at my post about LabVIEW library licensing below.

Open Source Licensing of LabVIEW packages, How to license LabVIEW Open Source Packages

Tomi

I'm not sure that's true. On the contrary, I think it's used in thousands of libraries, is it not?


As I said above, I do understand that.
(dons religious armor)
Part of this matter is a difference in perspective. What you see as a "very restrictive license" I see as a very permissive license. You can do anything you want with the GPL code, with the single caveat that you must do so under the banner of creating Free Software. I don't find that restrictive at all -- what it restricts is only your ability to impose restrictions on others.
(removes religious armor)

Let me be clear that I understand the need/purpose for different licensing schemes. I understand why OpenG moved to BSD, and I fully (tacitly) supported that move. I have released other code (in other languages) under other licenses, and I've chosen to release this specific library under the GPL for the reasons above. I know what that means to people who want to use it, and I also know that there's a great deal of both dislike and misunderstanding about the GPL (for the record, I don't include you in that -- I'm speaking more generally).


I appreciate that you've clarified the different types of open source licenses and the (OSI certification is important to some extent), but I don't see that the linked post adds much new information for me.

My position is still the same as what I stated before (emphasis added):

Right - and I'm in the game of system integration where a lot of what I release is proprietary to both my company and my client - we're not going to be releasing that code as open source anytime soon, so the GPL license that you've imposed therefore restricts me from using your library in my projects.

Understood. That was the balance that was kicking around in my head when I was deciding the licensing. In this case, I fell on the side of software freedom rather than size of potential audience. The ensuing discussion is by no means unexpected .

For someone in your situation, I would suggest that you might still be able to find use for my library. One of the hardest parts of using ImageMagick is working out what in blazes your command line should look like. The Execute ImageMagick Process.vi routine in the library (which is what actually makes the magic(k) happen) outputs the command line string that's executed:

Anyone can, for instance, use my code as a development aid to work out what their ImageMagick operations need to be, and then mangle the resulting command line into a Format Into String (or any number of other things) for their situation under almost any license they want (subject to the ImageMagick license, which is very permissive). I find that working out ImageMagick incantations by pushing VIs around beats command-line gymnastics by a wide margin.

The GPL limits the end users' rights to impose new restrictions (beyond the GPL) on the rights of downstream licensees. I don't think that Justin was implying that the GPL is without restrictions

Definitely, I believe that GPL'ing LabVIEW reuse libraries is going to significantly limit the user-base and collaborators, but that is the choice of the author

However, it does give people an opportunity to test the software and use it in some ways. And, if they want to use it outside the GPL, they can always negotiate new terms with the author(s). Several companies earn a living this way -- it's called the dual-licensing model.

Thanks, Justin, for this wonderful gift to the community!

Cheers,

-Jim

As a self-and-LabVIEW-promotional note, this library has been added to the official list of ImageMagick APIs.