RE: [Openexr-devel] Exr.NET

[Drew Hess]

Hey Wayney,

I was talking to Florian about this and I think I misinterpreted your 
intentions.

Originally, when I replied to your email, I thought you were talking about
wrapping the C++ OpenEXR API with C# bindings; but then Florian pointed
out that you're talking about the Huffman code, which isn't part of the
public API.  So now I'm thinking that you're actually talking about 
rewriting OpenEXR in C#.

I would strongly recommend against that.  For one thing, we're constantly
changing the code, especially right now in this 1.1.x series, and you
would need to keep up with all of our changes in order to stay compatible
with the format.  It would be extremely bad to create confusion about the 
format if some people are using the C++ libraries and others are using the 
C# libraries, and there turned out to be differences in the files which 
rendered them incompatible, or maybe even worse, gave different results 
depending on which library you used to read the file.

At some point in the future, we would like to have an "OpenEXR validator"  
which could examine a file and give a yes/no answer as to whether that
file can be called an OpenEXR file.  That'll make it easier for people to
write different implementations of the OpenEXR format for cases where it
makes sense, like in embedded devices with small memory footprints that
aren't hospitable to C++, or in hardware codecs in digital cameras, for
example.

So please consider wrapping the full C++ OpenEXR API with C# bindings.  I 
think that would be extremely useful.  But please think twice about doing 
a C# implementation from scratch.

thanks, and sorry for the confusion

-dwh-


On Fri, 12 Mar 2004, Drew Hess wrote:

> 
> Hi,
> 
> 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:
> 
> http://www.gnu.org/licenses/license-list.html
> 
> Again, the OpenEXR license is based on the modified BSD license listed on 
> that page.
> 
> 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 
> confusing option.
> 
> 
> -dwh-
> 
> 
>  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?
> > 
> > Thanks,
> > Wayney
> > 
> > 
> > 
> > _______________________________________________
> > Openexr-devel mailing list
> > address@hidden
> > http://mail.nongnu.org/mailman/listinfo/openexr-devel
> > 
> > 
> 
>