RE: [Openexr-devel] Exr.NET

[Drew Hess]

p.s. one more thing -- the C# API can (and probably should) diverge from
the C++ API when it's appropriate.  For example, if you don't want to pass
around pointers to pixels, use the C# idiom that's suited to that sort of
thing, maybe an iterator or something, just like someone writing Python
bindings for OpenEXR would do.  So if you're concerned about this sort of
thing, by all means feel free to make the C# interface suited to C#.  But
that's a lot easier than reimplementing the whole thing!



On Fri, 12 Mar 2004, Drew Hess wrote:

> 
> 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
> > > 
> > > 
> > 
> > 
> 
>