Re: [Openexr-devel] Rate of development for OpenEXR and CTL?

[Jonathan Litt]

One thing that has been sitting around for a long time in CVS is  
support for long (255 char) channel and attribute names. It would be  
really great to get that out soon so it can begin the slow trickle  
into products. :)

-Jonathan


On May 7, 2010, at 1:58 PM, Piotr Stanczyk wrote:
> Hi Jonathan,
>
> The OpenEXR pages have indeed been static of late. Regarding CTL,  
> this is the link to the Academy pages:
> http://www.oscars.org/science-technology/council/projects/ctl.html
> which really is a gateway to (after reviewing license agreements):
> http://sourceforge.net/projects/ampasctl/
> Thanks for pointing that out, I'll get the guys to update the website.
>
> Ilm does internal builds of IlmBase and OpenEXR on a regular basis  
> with a variety of compilers to make sure that there are no  
> unresolved build (and test) issues. (we sync out internal source  
> trees with the savannah/cvs ones pretty often) Of course, if you  
> happen to come across a compiler / platform combination that is  
> display incorrect behaviour please send that to the group.
>
> Regarding future releases; we've had a number of targets in mind for  
> a while now, at the very least a wrapping up of what is there in the  
> head of the cvs tree. I hope to get some time allocated to do this  
> in the near future.
>
> Thanks,
>
> Piotr
>
> https://savannah.nongnu.org/projects/openexr/
>
> Jonathan Day wrote:
> > Hi,
> >
> > The OpenEXR website seems to be a little stagnant (the links to CTL  
> > on www.oscars.com are broken - if you want it, it's on Sourceforge)  
> > and there's no evidence of any new releases or bugfix releases  
> > since October 2007.
> >
> > Call it a hunch, but given the modifications to GCC and other  
> > compilers over the past 3 years, I'm certain that even if the code  
> > had been perfect in 2007, there will be something that that is  
> > either no longer really correct (a legacy way of doing things) and  
> > perhaps does something unexpected, or breaks entirely.
> >
> > (The concept of "bit-rot" is actually valid, albeit described more  
> > in a comedic way than in the actual dynamics. Correct but  
> > unmaintained code will effectively accumulate errors, because  
> > language specs, standard function call semantics and compiler- 
> > specific nuances will always diverge from whatever you started off  
> > with.)
> >
> > Is anyone maintaining OpenEXR and/or CTL on an unofficial site or  
> > maintaining a bugfix patch, or is there a planned official release  
> > on the table?
> >
> > Jonathan Day
> >
> >
> >
> >
> >
> > _______________________________________________
> > Openexr-devel mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/openexr-devel
>
>
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel