headers
Michal Vyskocil | 2 Jun 08:37
Picon

Re: Announcing Python OpenEXR 1.0.0

On Tuesday 26 of May 2009 20:35:50 James Bowman wrote:
> All,
>
> The Python bindings for OpenEXR have reached version 1.0.0
>
> http://excamera.com/articles/26/openexr.html
>
> Changes:
>
> * Full documentation using Sphinx:
>    http://excamera.com/articles/26/doc/index.html
> * Unit test suite
> * Code cleanup for better error checking and exception catching
> * Plugged memory leaks
>
> It is tested on 32-bit BSD, Linux, and 64-bit Linux.

Hi,

I'd like to add your binding to openSUSE, but I did not find the license of 
it. OpenEXR is under the 3 clause BSD [1], so I expect that you'd like to use 
the same. Can you add the license to the upstream tarball (or on the homepage 
[2])?

[1] http://www.ilm.com/opensource/ilm-bsd-lic.html
[2] http://excamera.com/articles/26/openexr.html

Regards
Michal Vyskocil
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Bowman | 2 Jun 15:30
Favicon

Re: Announcing Python OpenEXR 1.0.0

On Tue, Jun 02, 2009 at 08:37:42AM +0200, Michal Vyskocil wrote:
> On Tuesday 26 of May 2009 20:35:50 James Bowman wrote:
> > All,
> >
> > The Python bindings for OpenEXR have reached version 1.0.0
> >
> > http://excamera.com/articles/26/openexr.html
> >
> > Changes:
> >
> > * Full documentation using Sphinx:
> >    http://excamera.com/articles/26/doc/index.html
> > * Unit test suite
> > * Code cleanup for better error checking and exception catching
> > * Plugged memory leaks
> >
> > It is tested on 32-bit BSD, Linux, and 64-bit Linux.
> 
> Hi,
> 
> I'd like to add your binding to openSUSE, but I did not find the license of 
> it. OpenEXR is under the 3 clause BSD [1], so I expect that you'd like to use 
> the same. Can you add the license to the upstream tarball (or on the homepage 
> [2])?
> 
> [1] http://www.ilm.com/opensource/ilm-bsd-lic.html
> [2] http://excamera.com/articles/26/openexr.html

Yes, added 3 clause BSD LICENSE to the tarball.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Piotr Stanczyk | 3 Jun 19:42
Gravatar

OpenEXR and Savannah outage

Hi all,

There has been a recent disk failure at Savannah. 
(http://lists.gnu.org/archive/html/savannah-users/2009-05/msg00023.html)

The good news is that it looks like the most recent stable back up is 
from May 27th and I have requested that this be used for restoring the 
source tree.

I've checked out the back up and run the confidence tests: they all pass 
on my AMD linux box here. However, if you do see any issues arising 
please let me know.

Thanks

Piotr
Permalink | Reply | 1 comment |
headers
Piotr Stanczyk | 4 Jun 05:51
Gravatar

RE: OpenEXR and Savannah outage

An update; the CVS source tree is back up and appears to be working well.

Please let me know if you run into any problems.

Piotr


-----Original Message-----
From: openexr-devel-bounces+pstanczyk=ilm.com <at> nongnu.org on behalf of Piotr Stanczyk
Sent: Wed 6/3/2009 10:42 AM
To: openexr-devel <at> nongnu.org
Subject: [Openexr-devel] OpenEXR and Savannah outage

Hi all,

There has been a recent disk failure at Savannah.
(http://lists.gnu.org/archive/html/savannah-users/2009-05/msg00023.html)

The good news is that it looks like the most recent stable back up is
from May 27th and I have requested that this be used for restoring the
source tree.

I've checked out the back up and run the confidence tests: they all pass
on my AMD linux box here. However, if you do see any issues arising
please let me know.

Thanks

Piotr




_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel


_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel
Permalink | Reply | 0 comments |
headers
Pablo Hdez-M. Saiz | 22 Jun 16:39
Picon

prman display exr single file

Hi,

We are working with Pixar's Renderman and we were wondering how we could tell the renderer to add channels to one single openexr file. If we write something like this in the RIB files:

Display "filename0001.exr" "openexr" "rgba" "quantize" [0 0 0 0]
Display "+p.exr" "openexr" "P" "quantize" [0 0 0 0]
Display "+n.exr" "openexr" "Ng" "quantize" [0 0 0 0]

what we get is three different exr each containing one of the channels we want (rgba, P and Ng respectively). But we only want one exr file with everything!

If we use the same filename in the three lines, the file only contains the rgba channel.

Perhaps you know what we should do to fix this.

Thank you very much.

Pablo and Alberto
www.elranchito.es
Spain

_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel
Permalink | Reply | 0 comments |
headers
Pablo Hdez-M. Saiz | 23 Jun 15:15
Picon

Re: prman display exr single file

Hi,

Thank you very much for your kind answer. We apologize if this wasn't the right place for this question. In the future we will make sure to ask only specific OpenExr questions.

Pablo and Alberto 

_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel
Permalink | Reply | 0 comments |
headers
Larry Gritz | 23 Jun 23:11

8 bit int?

I know this has been covered a couple time over the years, but from my 
cursory search of the archives, not lately, and not to my full 
satisfaction. :-)

Is anybody entertaining the idea of adding a uint8 data type to OpenEXR? 
  Sometimes (actually quite frequently) we store things in textures that 
do not need fp16 precision.

Objections I've seen in previous discussion:

"It's bad to store luminance" -> We store textures of things like masks 
or linear parameter values that are not luminance and 256 levels are 
more than enough.

"Use TIFF or PNG" -> But it's so much nicer to have all our textures in 
one format, and there is anecdotal evidence (which I'm trying to 
confirm) that libIlmImf is just flat-out faster to read texture than 
libtiff (though that's hard to verify with few useful data formats in 
common between TIFF and OpenEXR).

"Use fp16 with piz, it compresses as well as 8 bit" -> on disk, maybe, 
but it takes up twice the space in an in-memory tile cache.

I know you want to avoid a proliferation of data types.  I'm just 
talking about adding the one type that is by far the most common for 
source images.

Anything changed in your philosophy about this since the last time it 
came up?

--

-- 
Larry Gritz
lg <at> larrygritz.com
Permalink | Reply | 6 comments |
headers
Florian Kainz | 24 Jun 00:09

Re: 8 bit int?


A couple of random thoughts: compression should not be a problem - existing
methods could either be specialized for 8 bits, or the 8-bit data could be
padded to 16 bits.

One problem that needs to be solved is how the mapping between floating-point
numbers and integers gets encoded.  During file reads the library automatically
converts between pixel formats; to do this correctly, the libray must know
about the mapping.  And of course, application code must know about this too.
Your mail suggests that this mapping should be selectable per channel.

I am not sure that "256 levels are more than enough" for masks. If a mask
with a smooth and not very steep gradient is used to interpolate between
two layers that contain essentially flat fields, the stair steps in the
mask can become visible.

 > "Use fp16 with piz, it compresses as well as 8 bit" -> on disk, maybe,
 > but it takes up twice the space in an in-memory tile cache.

You could read each tile into a temporary buffer and convert the pixels
to 8 bits during the transfer from the buffer to the tile cache.  (Yes, I
know it's not the most efficient method ever, but you can do it without
waiting for an 8-bit EXR data type.)
Permalink | Reply | 4 comments |
headers
Florian Kainz | 24 Jun 00:11

Re: Version query?

I believe you are right, ther is no library version flag in the
header files.  The "configure" script should be able to add a
version number to OpenEXRConfig.h.

Larry Gritz wrote:
> Is there a way that an app can detect what version of OpenEXR it's 
> using, from the header files?  I can't find any #define VERSION or 
> anything like that.  (There's a version defined for the file format, but 
> not the library itself.)
> 
> This would be really helpful for an application that wants to compile 
> itself against whatever version of OpenEXR is on the system it finds, 
> and #ifdef out code that may not be supported in certain versions.  For 
> example, there are some compression methods that are new to 1.6, and if 
> you use the enum but you're really compiling against 1.4, it won't 
> compile.  You'd like to #if OPENEXR_VERSION >= 10601 ... or something 
> like that, so it can take advantage of the new feature if available, but 
> not break the compile if it's too old.
> 
> If such a thing is not already there, I recommend adding it in future 
> releases.  If it is there, it's very well hidden!
>
Permalink | Reply | 2 comments |
headers
Larry Gritz | 24 Jun 00:25

Re: 8 bit int?

Florian Kainz wrote:
> One problem that needs to be solved is how the mapping between 
> floating-point numbers and integers gets encoded. 

How does it work for the currently-supported int32? I'd be happy with 
something analogous, only fewer bits.

> I am not sure that "256 levels are more than enough" for masks.

Of course there are many texture use cases that must be 16 bit or float. 
  Nevertheless, a great many 8-bit files pop up in our productions, with 
no ill effect, and I'd like to take advantage of the file size, I/O, 
memory, and performance without forcing everything to more precision 
that is needed.

> You could read each tile into a temporary buffer and convert the pixels
> to 8 bits during the transfer from the buffer to the tile cache.  (Yes, I
> know it's not the most efficient method ever, but you can do it without
> waiting for an 8-bit EXR data type.)

Neat idea!  If fp16 files that only use ~256 values really do compress 
especially well, then I could store as fp16 and have a special header 
tag that means "it's ok to keep this internally as 8 bits."

That's a potentially great solution.  Do you have a specific suggestion 
for name and semantics of header attributes that would indicate that the 
exr file has "extra" precision and range that could be dropped?  May as 
well choose a common convention, in case others also want a solution 
like this.

	-- lg

--

-- 
Larry Gritz
lg <at> larrygritz.com
Permalink | Reply | 3 comments |

Gmane