headers
Hai Nguyen | 1 Aug 01:28
Picon

B44 question

Hi,

I am wondering if there was a formula of some type of find the maximum 
size of a B44 compressed image
give its dimensions? I briefly looked through the header files but I 
couldn't find what type the final compressed
data is stored in.

Thanks,
- Hai
Permalink | Reply | 4 comments |
headers
Florian Kainz | 1 Aug 01:56

Re: B44 question

Hai,

the B44 compression rate is fixed; it does not depend on image content.
If you store the pixels as RGB data, the compression rate for the raw
pixels is 32:14 (approximately 2.28:1).  If you store the pixels as
luminance/chroma data, the compression rate is 32:7 (approximately 4.57:1).
In addition to the pixels, the file contains header data and some padding,
so the overall compression rate will be slightly less.

Since the compression rate is fixed, the easiest way to determine the
size of a file with given dimensions, is to compress one image; other
images will have the same size.

I don't have an exact formula for the size of B44-compressed files,
but if necessary, we can probably work it out.

Florian

Hai Nguyen wrote:
> Hi,
> 
> I am wondering if there was a formula of some type of find the maximum 
> size of a B44 compressed image
> give its dimensions? I briefly looked through the header files but I 
> couldn't find what type the final compressed
> data is stored in.
> 
> Thanks,
> - Hai
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Hai Nguyen | 1 Aug 02:10
Picon

Re: B44 question

Thanks, Florian.

That information was actually on the web site - I should have been more 
paying more attention. :)

What I'm trying to do is to compress an image in memory to B44 and save 
it off in a chunk of memory.
Then derive something form IStream to read it back during play back. I 
think someone was trying to do something similar
sometime ago - I saw it in the archives.

The motivation for my initial question was to avoid having to write out 
to a temporary file and read it back in.
This requires me to make a guess at what the maximum size of the 
compressed data would be.

Do you have any recommendations/suggestions for a process like this?

- Hai

Florian Kainz wrote:
> Hai,
>
> the B44 compression rate is fixed; it does not depend on image content.
> If you store the pixels as RGB data, the compression rate for the raw
> pixels is 32:14 (approximately 2.28:1).  If you store the pixels as
> luminance/chroma data, the compression rate is 32:7 (approximately 
> 4.57:1).
> In addition to the pixels, the file contains header data and some 
> padding,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Florian Kainz | 1 Aug 03:24

Re: B44 question


The document at  http://www.openexr.com/openexrfilelayout.pdf
describes the on-disk format of OpenEXR files.  The document
should be enough to calculate how much space is used by the
file header and other auxiliary data.

The source code and comments in file ImfB44Compressor.cpp
are currently the only detailed description of how B44
compression works.  It will take a bit of work, but you
should be able to derive a relatively formula that tells
you exactly how big the compressed pixel data are.

If you work out an exact formula for the file sizes, would
you mind publishing it?

Hai Nguyen wrote:
> Thanks, Florian.
> 
> That information was actually on the web site - I should have been more 
> paying more attention. :)
> 
> What I'm trying to do is to compress an image in memory to B44 and save 
> it off in a chunk of memory.
> Then derive something form IStream to read it back during play back. I 
> think someone was trying to do something similar
> sometime ago - I saw it in the archives.
> 
> The motivation for my initial question was to avoid having to write out 
> to a temporary file and read it back in.
> This requires me to make a guess at what the maximum size of the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hai Nguyen | 1 Aug 03:43
Picon

Re: B44 question

Not at all,

Thanks again,
Hai

Florian Kainz wrote:
>
> The document at  http://www.openexr.com/openexrfilelayout.pdf
> describes the on-disk format of OpenEXR files.  The document
> should be enough to calculate how much space is used by the
> file header and other auxiliary data.
>
> The source code and comments in file ImfB44Compressor.cpp
> are currently the only detailed description of how B44
> compression works.  It will take a bit of work, but you
> should be able to derive a relatively formula that tells
> you exactly how big the compressed pixel data are.
>
> If you work out an exact formula for the file sizes, would
> you mind publishing it?
>
>
> Hai Nguyen wrote:
>> Thanks, Florian.
>>
>> That information was actually on the web site - I should have been 
>> more paying more attention. :)
>>
>> What I'm trying to do is to compress an image in memory to B44 and 
>> save it off in a chunk of memory.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Florian Kainz | 4 Aug 05:14

OpenEXR 1.6.0 and CTL 1.4.0 released

August 3, 2007 - New stable versions of OpenEXR and CTL are now available.
The source code has been tested on Linux, Mac OS X and Windows (Visual Studio
7 and 8).  Here's a summary of the changes since the last release:

     OpenEXR 1.6.0
         - Reduced generational loss in B44- and B44A-compressed images.
         - Added B44A compression.  This is a variation of B44, but with
           a better compression ratio for images with large uniform areas,
           such as in an alpha channel.
         - Bug fixes.

     CTL 1.4.0
         - Added new functions to the CTL standard library: 3x3 matrix
           support, 1D lookup tables with cubic interpolation.
         - Added new ctlversion statement to the language.
         - Bug fixes.

     OpenEXR_CTL 1.0.0
         - Applying CTL transforms to a frame buffer is multi-threaded.
         - Bug fixes.

     OpenEXR_Viewers 1.0.0
         - Implemented new naming conventions for CTL parameters.

     IlmBase 1.0.0
         - Half now implements "round to nearest even" mode.

ilmbase-1.0.0.tar.gz, openexr-1.6.0.tar.gz and openexr_viewers-1.0.0.tar.gz
can be downloaded from
(Continue reading)

Permalink | Reply | 19 comments |
headers
Ken McGaugh | 6 Aug 01:18

Re: OpenEXR 1.6.0 and CTL 1.4.0 released

On 04/08/2007, at 1:14 PM, Florian Kainz wrote:
>         - Added B44A compression.  This is a variation of B44, but  
> with
>           a better compression ratio for images with large uniform  
> areas,
>           such as in an alpha channel.

Are there any disadvantages to using B44A versus B44?
Or should we just always use B44A?

Thanks for a great release.  I've been looking forward to this for a  
while.
--Ken
Permalink | Reply | 14 comments |
headers
Ken McGaugh | 7 Aug 12:49

1.6.0 OSX universal libraries not building

I'm trying to build the new 1.6.0 libraries under OSX as universal  
binaries.  Following the
instructions I ran configure this way:

     ./configure --enable-osx-universal-binaries --disable-dependency- 
tracking

Then when I run make to build the libraries it all seems to be  
working correctly until libtool
is called to build a final shared library.  It seems that libtool  
isn't passing the following flags
along to the compiler:

     -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386

Can anybody else confirm this?

Thanks.
--Ken
Permalink | Reply | 1 comment |
headers
Paul Schneider | 7 Aug 16:38
Picon

Re: 1.6.0 OSX universal libraries not building


Hi, Ken,

I see this too, with the pre-packaged source from savannah.  If I  
checkout the source from CVS, I can still build universal.

Every invocation of libtool I see in make's output passes both -arch  
flags.  It also seems that the object files and the static libraries  
are being built universal, but the shared libraries are being built  
thin.  I notice that the shared libraries don't have the .dylib  
extension, like they do when I build from CVS.

spyhunter:~/Desktop/openexr-1.6.0 paul$ file IlmImf/.libs/ 
ImfIntAttribute.o
IlmImf/.libs/ImfIntAttribute.o: Mach-O universal binary with 2  
architectures
IlmImf/.libs/ImfIntAttribute.o (for architecture ppc):  Mach-O object  
ppc
IlmImf/.libs/ImfIntAttribute.o (for architecture i386): Mach-O object  
i386

spyhunter:~/Desktop/openexr-1.6.0 paul$ file IlmImf/.libs/libIlmImf.a
IlmImf/.libs/libIlmImf.a: Mach-O universal binary with 2 architectures
IlmImf/.libs/libIlmImf.a (for architecture ppc):        current ar  
archive random library
IlmImf/.libs/libIlmImf.a (for architecture i386):       current ar  
archive random library

spyhunter:~/Desktop/openexr-1.6.0 paul$ file IlmImf/.libs/libIlmImf.6
IlmImf/.libs/libIlmImf.6: Mach-O dynamically linked shared library i386
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc-Antoine Desroches | 8 Aug 03:43
Picon

using the openexr C callable interface on Windows

Hello,

I want to use the openexr library from within scheme programs (I use PLT scheme on windows). When I load the dll (using the foreign function interface) I get a R6034 error. It seems the openexr dlls are linked with the MS runtime library. Does someone know a good solution to this that will not get me in dll hell? Is it possible to have openexr dlls that are statically linked with the standard libraries they need?

I use the 1.4.0 vs2005 binary package.

It would be really cool if there was a way for me to use openexr without using a custom-built package. This way users of my application will be free to easily update the openexr library without my help.

Thank you,

Marc-Antoine

_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel
Permalink | Reply | 5 comments |

Gmane