[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Openexr-devel] Exr.NET
RE: [Openexr-devel] Exr.NET
Fri, 12 Mar 2004 12:03:54 -0800 (PST)
This is the right list for your questions.
OpenEXR's license allows you to link against it and choose whatever
license you like which is compatible with it, i.e. any license which
doesn't conflict with the terms of the OpenEXR license. Because OpenEXR's
license is based on the modified BSD license, the only requirement is
that, if you link against OpenEXR code and you distribute it to a third
party, whether for free or otherwise, you include the OpenEXR copyright
somewhere in your "distribution."
Just because you use or wrap OpenEXR in your project doesn't mean you have
to make the source code for your project available. In other words,
OpenEXR can be used safely by "closed source" applications. Of course, I
encourage you to make your .NET wrapper available as open source software.
We really need bindings for other languages!
You're free to use the OpenEXR license, if you wish, but since it's you
writing and distributing the C# code, you need to put your own name (or
that of your employer) in there as the copyright holder for any code you
write. You shouldn't need to distribute any code from the OpenEXR
distribution with your release -- the most I think you'll need to do is
distribute the OpenEXR library binaries so that someone downloading your
.NET wrapper doesn't have to go get the OpenEXR libraries separately --
but if you want to for whatever reason, you should leave the license on
those files as-is.
Let me know if you have any other questions. You can see a very good
summary of free software licenses here:
Again, the OpenEXR license is based on the modified BSD license listed on
As far as the namespace goes, why not keep the same namespaces that
OpenEXR uses in C++: IlmImf, Imath, etc.? That seems like the least
On Fri, 12 Mar 2004 address@hidden wrote:
> Hi again,
> Well, I managed to get it working, loading and displaying exr images
> using my wrapper :)
> A few issues in the managed->C++ interop though, the SetFrameBuffer call
> expects the target address to be offset. So that when ReadPixels is called,
> the scan line offset within the frame buffer is computed and added to the
> original address.
> Whilst this is fine for C++, C# (and managed code in general) doesn't like
> you fiddling with raw pointers. It's possible (in C#) but the code has to be
> flagged as 'unsafe' which means you can't make use of the security features
> provided with the .NET framework.
> Also, there doesn't appear to be any API methods to iterate through the
> attributes or determine their type. And it seems the C API only supports
> 'Half' pixels (ie. using the Half data type).
> So, after some thinking. I've decided instead to port much of the IlmImf.dll
> to native C#, which is a lot of work. But there are some things I'm doing I
> *really* want exr support for :) Are there any [legal] issues with such an
> approach? I shall still make it open source using the same license as
> OpenExr itself. Much of the code so far is a direct C++ -> C# port
> (currently working on the Huffman decompressor) and I'm trying to keep the
> class hierarchy close to the C++ files.
> Should I use the same file\license header as the C++ files? That contains
> ILM's name, should that be removed or can it be kept? I thought of renaming
> the project to OpenExr.NET so I could use the namespace "OpenExr" (the
> current 'ExrDotNet' namespace is a bit clunky :), is that an issue?
> My current roadmap is to first get PIZ compressed files loading and
> displaying (as most exr files seem to use that format), then add support for
> other compression schemes followed by support for writing out files.
> Actually, I'm not sure if this is the correct mailing list for this post
> sorry, perhaps I should mail OpenExr-Users?
> Openexr-devel mailing list