headers
John Burnett | 9 Dec 02:41

ilmbase new release

Hello,

 

Is there going to be a push for an updated ilmbase release?

 

I made a few changes to fix build some warnings (silly things like int vs size_t), and I’m curious if I should try to push those changes up to the official project?  If so, what are the guidelines for contributing?

 

Thanks,

John

 

_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel
Permalink | Reply | 2 comments |
headers
Piotr Stanczyk | 9 Dec 22:19

Re: ilmbase new release

Hi John,

That is indeed the plan, I'd like to have a firmer plan for the release 
at the start of next year....
In the meantime, would you be so kind as to send me the changes and I 
will fold them in to the CVS tree and test out.

Many thanks in advance

Piotr

John Burnett wrote:

*



>
> Hello,
>
> Is there going to be a push for an updated ilmbase release?
>
> I made a few changes to fix build some warnings (silly things like int 
> vs size_t), and I’m curious if I should try to push those changes up 
> to the official project? If so, what are the guidelines for contributing?
>
> Thanks,
>
> John
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Openexr-devel mailing list
> Openexr-devel <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/openexr-devel
>
Permalink | Reply | 1 comment |
headers
John Burnett | 10 Dec 04:16

RE: ilmbase new release

Great to hear!  We are using 1.01 internally here, so the attached diff applies to that.  They're all silly
little things like doing explicit casts and using ((expr) != FALSE) to coerce expressions into bools.  Thanks!

John

-----Original Message-----
From: Piotr Stanczyk [mailto:pstanczyk <at> ilm.com] 
Sent: Wednesday, December 09, 2009 1:20 PM
To: John Burnett
Cc: openexr-devel <at> nongnu.org
Subject: Re: [Openexr-devel] ilmbase new release

Hi John,

That is indeed the plan, I'd like to have a firmer plan for the release 
at the start of next year....
In the meantime, would you be so kind as to send me the changes and I 
will fold them in to the CVS tree and test out.

Many thanks in advance

Piotr

John Burnett wrote:

*



>
> Hello,
>
> Is there going to be a push for an updated ilmbase release?
>
> I made a few changes to fix build some warnings (silly things like int 
> vs size_t), and I'm curious if I should try to push those changes up 
> to the official project? If so, what are the guidelines for contributing?
>
> Thanks,
>
> John
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Openexr-devel mailing list
> Openexr-devel <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/openexr-devel
>   


Index: K:/dev/trunk/buildsystem/trunk/ThirdParty/Source/Libraries/ilmbase/Source/Imath/ImathVec.cpp
===================================================================
---
K:/dev/trunk/buildsystem/trunk/ThirdParty/Source/Libraries/ilmbase/Source/Imath/ImathVec.cpp	(revision 40239)
+++
K:/dev/trunk/buildsystem/trunk/ThirdParty/Source/Libraries/ilmbase/Source/Imath/ImathVec.cpp	(revision 40240)
@@ -107,7 +107,7 @@
 short
 Vec2<short>::length () const
 {
-    float lenF = Math<float>::sqrt (dot (*this));
+    float lenF = Math<float>::sqrt ((float)dot (*this));
     short lenS = (short) (lenF + 0.5f);
     return lenS;
 }
@@ -176,7 +176,7 @@
 int
 Vec2<int>::length () const
 {
-    float lenF = Math<float>::sqrt (dot (*this));
+    float lenF = Math<float>::sqrt ((float)dot (*this));
     int lenI = (int) (lenF + 0.5f);
     return lenI;
 }
@@ -314,7 +314,7 @@
 int
 Vec3<int>::length () const
 {
-    float lenF = Math<float>::sqrt (dot (*this));
+    float lenF = Math<float>::sqrt ((float)dot (*this));
     int lenI = (int) (lenF + 0.5f);
     return lenI;
 }
Index: K:/dev/trunk/buildsystem/trunk/ThirdParty/Source/Libraries/ilmbase/Source/Imath/ImathRandom.cpp
===================================================================
---
K:/dev/trunk/buildsystem/trunk/ThirdParty/Source/Libraries/ilmbase/Source/Imath/ImathRandom.cpp	(revision 40239)
+++
K:/dev/trunk/buildsystem/trunk/ThirdParty/Source/Libraries/ilmbase/Source/Imath/ImathRandom.cpp	(revision 40240)
@@ -91,9 +91,9 @@
     // We assume that sizeof (unsigned short) == 2.
     //
 
-    state[2] = x >> 32;
-    state[1] = x >> 16;
-    state[0] = x;
+    state[2] = unsigned short(x >> 32);
+    state[1] = unsigned short(x >> 16);
+    state[0] = unsigned short(x);
 }
 
 } // namespace
@@ -163,7 +163,7 @@
 srand48 (long int seed)
 {
     staticState[2] = seed >> 16;
-    staticState[1] = seed;
+    staticState[1] = unsigned short(seed);
     staticState[0] = 0x330e;
 }
 
Index: K:/dev/trunk/buildsystem/trunk/ThirdParty/Source/Libraries/ilmbase/Source/IlmThread/IlmThreadSemaphoreWin32.cpp
===================================================================
---
K:/dev/trunk/buildsystem/trunk/ThirdParty/Source/Libraries/ilmbase/Source/IlmThread/IlmThreadSemaphoreWin32.cpp	(revision 40239)
+++
K:/dev/trunk/buildsystem/trunk/ThirdParty/Source/Libraries/ilmbase/Source/IlmThread/IlmThreadSemaphoreWin32.cpp	(revision 40240)
@@ -95,7 +95,7 @@
 
 Semaphore::~Semaphore()
 {
-    bool ok = ::CloseHandle (_semaphore);
+    bool ok = ::CloseHandle (_semaphore) != FALSE;
     assert (ok);
 }
 
Index: K:/dev/trunk/buildsystem/trunk/ThirdParty/Source/Libraries/ilmbase/Source/IlmThread/IlmThreadPool.cpp
===================================================================
---
K:/dev/trunk/buildsystem/trunk/ThirdParty/Source/Libraries/ilmbase/Source/IlmThread/IlmThreadPool.cpp	(revision 40239)
+++
K:/dev/trunk/buildsystem/trunk/ThirdParty/Source/Libraries/ilmbase/Source/IlmThread/IlmThreadPool.cpp	(revision 40240)
@@ -247,7 +247,7 @@
     // an error like: "pure virtual method called"
     //
 
-    for (int i = 0; i < numThreads; i++)
+    for (size_t i = 0; i < numThreads; i++)
     {
 	taskSemaphore.post();
 	threadSemaphore.wait();
@@ -364,19 +364,19 @@
 
     Lock lock (_data->threadMutex);
 
-    if (count > _data->numThreads)
+    if ((size_t)count > _data->numThreads)
     {
 	//
         // Add more threads
 	//
 
-        while (_data->numThreads < count)
+        while (_data->numThreads < (size_t)count)
         {
             _data->threads.push_back (new WorkerThread (_data));
             _data->numThreads++;
         }
     }
-    else if (count < _data->numThreads)
+    else if ((size_t)count < _data->numThreads)
     {
 	//
 	// Wait until all existing threads are finished processing,
@@ -389,7 +389,7 @@
         // Add in new threads
 	//
 
-        while (_data->numThreads < count)
+        while (_data->numThreads < (size_t)count)
         {
             _data->threads.push_back (new WorkerThread (_data));
             _data->numThreads++;
Index: K:/dev/trunk/buildsystem/trunk/ThirdParty/Source/Libraries/ilmbase/Source/IlmThread/IlmThreadWin32.cpp
===================================================================
---
K:/dev/trunk/buildsystem/trunk/ThirdParty/Source/Libraries/ilmbase/Source/IlmThread/IlmThreadWin32.cpp	(revision 40239)
+++
K:/dev/trunk/buildsystem/trunk/ThirdParty/Source/Libraries/ilmbase/Source/IlmThread/IlmThreadWin32.cpp	(revision 40240)
@@ -76,7 +76,7 @@
 {
     DWORD status = ::WaitForSingleObject (_thread, INFINITE);
     assert (status ==  WAIT_OBJECT_0);
-    bool ok = ::CloseHandle (_thread);
+    bool ok = ::CloseHandle (_thread) != FALSE;
     assert (ok);
 }
 
_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel
Permalink | Reply | 0 comments |
headers
Koraxen | 8 Dec 03:21
Picon

Writing single EXR file with very many channels?

Hey guys,

I have a question regarding how to deal memory consumption and multi-layered EXR files.

I need to write an EXR file that contains 10 different versions of a same high res (5120 x 2880) image. This translates into an EXR file that contains 10 layers x 4 channels = 40 channels.

What I am doing is:
1. Instantiate an exr framebuffer
2. Allocate memory for 40 high-res channels, and insert() them all into framebuffer
3. Instantiate OutputFile object, and set the framebuffer to it
4. Write the OutputFile

The problem is that host system obviously runs out of memory during step #2.

What's needed here is the ability to:
- Insert a channel to framebuffer
- Write it to disk
- Free memory
- Repeat 40 times
- End up with a *single* EXR file containing 40 channels

How can this be done?

Thanks a ton!
- Kora

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

Re: Writing single EXR file with very many channels?

Hi Kora,

the IlmImf library does not allow writing the file channel by channel;
all channels must be written at the same time.  The OpenEXR file layout
would channel-by-channel writing very inefficient.
However, you can write a few scanlines at a time or a few tiles at a
time; your frame buffer only has to be large enough to hold the portion
of the image you are writing.  (In the extreme, a single scan line or
a single tile is enough.)

Florian

Koraxen wrote:

*



> Hey guys,
> 
> I have a question regarding how to deal memory consumption and 
> multi-layered EXR files.
> 
> I need to write an EXR file that contains 10 different versions of a 
> same high res (5120 x 2880) image. This translates into an EXR file that 
> contains 10 layers x 4 channels = 40 channels.
> 
> What I am doing is:
> 1. Instantiate an exr framebuffer
> 2. Allocate memory for 40 high-res channels, and insert() them all into 
> framebuffer
> 3. Instantiate OutputFile object, and set the framebuffer to it
> 4. Write the OutputFile
> 
> The problem is that host system obviously runs out of memory during step #2.
> 
> What's needed here is the ability to:
> - Insert a channel to framebuffer
> - Write it to disk
> - Free memory
> - Repeat 40 times
> - End up with a *single* EXR file containing 40 channels
> 
> How can this be done?
> 
> Thanks a ton!
> - Kora
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Openexr-devel mailing list
> Openexr-devel <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/openexr-devel
Permalink | Reply | 4 comments |
headers
Koraxen | 10 Dec 19:26
Picon

Re: Writing single EXR file with very many channels?

Thanks for the reply Florian!

Do you know of any example that shows scanlines being written 1 at a time?

As in:
write scanline1 of channel1
write scanline1 of channel2
write scanline1 of channel3
write scanline1 of channel4
free() mem

write scanline2 of channel1
write scanline2 of channel2
write scanline2 of channel3
write scanline2 of channel4
free() mem

...and so forth.

I can find one for tiled files in the ReadingAndWritingImageFiles pdf, but not for scanline.

Thanks again,
- K.


On Wed, Dec 9, 2009 at 11:20 AM, Florian Kainz <kainz <at> ilm.com> wrote:
Hi Kora,

the IlmImf library does not allow writing the file channel by channel;
all channels must be written at the same time.  The OpenEXR file layout
would channel-by-channel writing very inefficient.
However, you can write a few scanlines at a time or a few tiles at a
time; your frame buffer only has to be large enough to hold the portion
of the image you are writing.  (In the extreme, a single scan line or
a single tile is enough.)

Florian


Koraxen wrote:
Hey guys,

I have a question regarding how to deal memory consumption and multi-layered EXR files.

I need to write an EXR file that contains 10 different versions of a same high res (5120 x 2880) image. This translates into an EXR file that contains 10 layers x 4 channels = 40 channels.

What I am doing is:
1. Instantiate an exr framebuffer
2. Allocate memory for 40 high-res channels, and insert() them all into framebuffer
3. Instantiate OutputFile object, and set the framebuffer to it
4. Write the OutputFile

The problem is that host system obviously runs out of memory during step #2.

What's needed here is the ability to:
- Insert a channel to framebuffer
- Write it to disk
- Free memory
- Repeat 40 times
- End up with a *single* EXR file containing 40 channels

How can this be done?

Thanks a ton!
- Kora


------------------------------------------------------------------------


_______________________________________________
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 | 3 comments |
headers
Koraxen | 10 Dec 19:34
Picon

Re: Writing single EXR file with very many channels?

More precisely:

generateScanline(1)
write scanline1 of channel1
write scanline1 of channel2
write scanline1 of channel3
write scanline1 of channel4
free() mem

generateScanline(2)
write scanline2 of channel1
write scanline2 of channel2
write scanline2 of channel3
write scanline2 of channel4
free() mem

.. and so forth.

The writePixels( int height ) function will write a given number of scanlines, but not a specific scanline?

- K.

On Thu, Dec 10, 2009 at 10:26 AM, Koraxen <koraxen <at> gmail.com> wrote:
Thanks for the reply Florian!

Do you know of any example that shows scanlines being written 1 at a time?

As in:
write scanline1 of channel1
write scanline1 of channel2
write scanline1 of channel3
write scanline1 of channel4
free() mem

write scanline2 of channel1
write scanline2 of channel2
write scanline2 of channel3
write scanline2 of channel4
free() mem

...and so forth.

I can find one for tiled files in the ReadingAndWritingImageFiles pdf, but not for scanline.

Thanks again,
- K.



On Wed, Dec 9, 2009 at 11:20 AM, Florian Kainz <kainz <at> ilm.com> wrote:
Hi Kora,

the IlmImf library does not allow writing the file channel by channel;
all channels must be written at the same time.  The OpenEXR file layout
would channel-by-channel writing very inefficient.
However, you can write a few scanlines at a time or a few tiles at a
time; your frame buffer only has to be large enough to hold the portion
of the image you are writing.  (In the extreme, a single scan line or
a single tile is enough.)

Florian


Koraxen wrote:
Hey guys,

I have a question regarding how to deal memory consumption and multi-layered EXR files.

I need to write an EXR file that contains 10 different versions of a same high res (5120 x 2880) image. This translates into an EXR file that contains 10 layers x 4 channels = 40 channels.

What I am doing is:
1. Instantiate an exr framebuffer
2. Allocate memory for 40 high-res channels, and insert() them all into framebuffer
3. Instantiate OutputFile object, and set the framebuffer to it
4. Write the OutputFile

The problem is that host system obviously runs out of memory during step #2.

What's needed here is the ability to:
- Insert a channel to framebuffer
- Write it to disk
- Free memory
- Repeat 40 times
- End up with a *single* EXR file containing 40 channels

How can this be done?

Thanks a ton!
- Kora


------------------------------------------------------------------------


_______________________________________________
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 | 2 comments |
headers
Jonathan Litt | 14 Dec 19:01
Picon

Re: Writing single EXR file with very many channels?

It's almost exactly like the general interface examples in the distribution (generalInterfaceExamples.cpp -> writeGZ1 & writeGZ2), but you would put a loop around that whole chunk of code. Your buffers should each be the size of one scanline, and you need to recreate the framebuffer object for each scanline because you're going to pass the same pixel buffers each time but give them a different offset into the file. The key thing to get right is the second argument to the Slice() object that you pass to each call of framebuffer.insert(), because that is where the offset will go. That is how writePixels knows where to start . Perhaps the closest example of this is in the function "readGZ1", although that is for reading a datawindow and not writing scanlines.

I agree it would be nice if there were an example of this in the distribution.

-Jonathan


From: Koraxen <koraxen <at> gmail.com>
To: Florian Kainz <kainz <at> ilm.com>
Cc: openexr-devel <at> nongnu.org
Sent: Thu, December 10, 2009 10:34:44 AM
Subject: Re: [Openexr-devel] Writing single EXR file with very many channels?

More precisely:

generateScanline(1)
write scanline1 of channel1
write scanline1 of channel2
write scanline1 of channel3
write scanline1 of channel4
free() mem

generateScanline(2)
write scanline2 of channel1
write scanline2 of channel2
write scanline2 of channel3
write scanline2 of channel4
free() mem

.. and so forth.

The writePixels( int height ) function will write a given number of scanlines, but not a specific scanline?

- K.

On Thu, Dec 10, 2009 at 10:26 AM, Koraxen <koraxen <at> gmail.com> wrote:
Thanks for the reply Florian!

Do you know of any example that shows scanlines being written 1 at a time?

As in:
write scanline1 of channel1
write scanline1 of channel2
write scanline1 of channel3
write scanline1 of channel4
free() mem

write scanline2 of channel1
write scanline2 of channel2
write scanline2 of channel3
write scanline2 of channel4
free() mem

...and so forth.

I can find one for tiled files in the ReadingAndWritingImageFiles pdf, but not for scanline.

Thanks again,
- K.



On Wed, Dec 9, 2009 at 11:20 AM, Florian Kainz <kainz <at> ilm.com> wrote:
Hi Kora,

the IlmImf library does not allow writing the file channel by channel;
all channels must be written at the same time.  The OpenEXR file layout
would channel-by-channel writing very inefficient.
However, you can write a few scanlines at a time or a few tiles at a
time; your frame buffer only has to be large enough to hold the portion
of the image you are writing.  (In the extreme, a single scan line or
a single tile is enough.)

Florian


Koraxen wrote:
Hey guys,

I have a question regarding how to deal memory consumption and multi-layered EXR files.

I need to write an EXR file that contains 10 different versions of a same high res (5120 x 2880) image. This translates into an EXR file that contains 10 layers x 4 channels = 40 channels.

What I am doing is:
1. Instantiate an exr framebuffer
2. Allocate memory for 40 high-res channels, and insert() them all into framebuffer
3. Instantiate OutputFile object, and set the framebuffer to it
4. Write the OutputFile

The problem is that host system obviously runs out of memory during step #2.

What's needed here is the ability to:
- Insert a channel to framebuffer
- Write it to disk
- Free memory
- Repeat 40 times
- End up with a *single* EXR file containing 40 channels

How can this be done?

Thanks a ton!
- Kora


------------------------------------------------------------------------


_______________________________________________
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 | 1 comment |
headers
Paul Schneider | 14 Dec 20:55
Picon

Re: Writing single EXR file with very many channels?


The old Photoshop plugin reads and writes a single scanline at a time, so that might also be useful to look at. 

The source is available here:


And the relevant code is in EXRFormatPlugin.cpp. See EXRFormatPlugin::DoReadContinue and EXRFormatPlugin::DoWriteStart. I don't know if the plugin will actually compile anymore, unfortunately. I stopped maintaining it when Photoshop got native EXR support.

- Paul


On Dec 14, 2009, at 10:01 AM, Jonathan Litt wrote:

It's almost exactly like the general interface examples in the distribution (generalInterfaceExamples.cpp -> writeGZ1 & writeGZ2), but you would put a loop around that whole chunk of code. Your buffers should each be the size of one scanline, and you need to recreate the framebuffer object for each scanline because you're going to pass the same pixel buffers each time but give them a different offset into the file. The key thing to get right is the second argument to the Slice() object that you pass to each call of framebuffer.insert(), because that is where the offset will go. That is how writePixels knows where to start. Perhaps the closest example of this is in the function "readGZ1", although that is for reading a datawindow and not writing scanlines.

I agree it would be nice if there were an example of this in the distribution.

-Jonathan


From: Koraxen <koraxen <at> gmail.com>
To: Florian Kainz <kainz <at> ilm.com>
Cc: openexr-devel <at> nongnu.org
Sent: Thu, December 10, 2009 10:34:44 AM
Subject: Re: [Openexr-devel] Writing single EXR file with very many channels?

More precisely:

generateScanline(1)
write scanline1 of channel1
write scanline1 of channel2
write scanline1 of channel3
write scanline1 of channel4
free() mem

generateScanline(2)
write scanline2 of channel1
write scanline2 of channel2
write scanline2 of channel3
write scanline2 of channel4
free() mem

.. and so forth.

The writePixels( int height ) function will write a given number of scanlines, but not a specific scanline?

- K.

On Thu, Dec 10, 2009 at 10:26 AM, Koraxen <koraxen <at> gmail.com> wrote:
Thanks for the reply Florian!

Do you know of any example that shows scanlines being written 1 at a time?

As in:
write scanline1 of channel1
write scanline1 of channel2
write scanline1 of channel3
write scanline1 of channel4
free() mem

write scanline2 of channel1
write scanline2 of channel2
write scanline2 of channel3
write scanline2 of channel4
free() mem

...and so forth.

I can find one for tiled files in the ReadingAndWritingImageFiles pdf, but not for scanline.

Thanks again,
- K.



On Wed, Dec 9, 2009 at 11:20 AM, Florian Kainz <kainz <at> ilm.com> wrote:
Hi Kora,

the IlmImf library does not allow writing the file channel by channel;
all channels must be written at the same time.  The OpenEXR file layout
would channel-by-channel writing very inefficient.
However, you can write a few scanlines at a time or a few tiles at a
time; your frame buffer only has to be large enough to hold the portion
of the image you are writing.  (In the extreme, a single scan line or
a single tile is enough.)

Florian


Koraxen wrote:
Hey guys,

I have a question regarding how to deal memory consumption and multi-layered EXR files.

I need to write an EXR file that contains 10 different versions of a same high res (5120 x 2880) image. This translates into an EXR file that contains 10 layers x 4 channels = 40 channels.

What I am doing is:
1. Instantiate an exr framebuffer
2. Allocate memory for 40 high-res channels, and insert() them all into framebuffer
3. Instantiate OutputFile object, and set the framebuffer to it
4. Write the OutputFile

The problem is that host system obviously runs out of memory during step #2.

What's needed here is the ability to:
- Insert a channel to framebuffer
- Write it to disk
- Free memory
- Repeat 40 times
- End up with a *single* EXR file containing 40 channels

How can this be done?

Thanks a ton!
- Kora


------------------------------------------------------------------------


_______________________________________________
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

_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel
Permalink | Reply | 0 comments |
headers
David | 24 Nov 11:56
Picon
Picon

PIZ-Compression / Multithreading

Hello Everyone,

i've got two little questions:
I'm developping a c++-tool to convert OpenExr-images from Maya to 
OpenExr-images which are optimized for Nuke (the tool creates a data 
window and converts the images into scanline-mode with piz compression).

Question 1: Why is the creation of a Image with piz-compression so slow 
comparing to the zip-compression? (The input-File is a tiled EXR with 
RLE-Compression). Is there a way to optimize the conversion from RLE to 
PIZ? The conversion is really slow (several minutes for a 2k exr with 10 
layers) so multithreading wouldn't fix the problem.

Question 2: I want to use Multithreading for writing an exr. Reading the 
documentation i thought i just have to set the GlobalThreadCount and 
then start the writePixels-function for every 20 scanlines (for example) 
again and again and the interface would do the thread-stuff 
automatically. But i don't see any effect. The writing takes exactly the 
same time. What is the right way to do that?

Thanks for your replies.

David
Permalink | Reply | 4 comments |
headers
Florian Kainz | 24 Nov 19:38

Re: PIZ-Compression / Multithreading


David wrote:
> Hello Everyone,
> 
> i've got two little questions:
> I'm developping a c++-tool to convert OpenExr-images from Maya to 
> OpenExr-images which are optimized for Nuke (the tool creates a data 
> window and converts the images into scanline-mode with piz compression).
> 
> Question 1: Why is the creation of a Image with piz-compression so slow 
> comparing to the zip-compression? (The input-File is a tiled EXR with 
> RLE-Compression). Is there a way to optimize the conversion from RLE to 
> PIZ? The conversion is really slow (several minutes for a 2k exr with 10 
> layers) so multithreading wouldn't fix the problem.

For scanline-based files PIZ compression should be faster than ZIP
compression, although ZIP decompresses faster than PIZ.

PIZ does not work well for tiled files, unless the tiles are fairly large,
maybe 256x256 or 512x512 pixels.  For smaller tiles I recommend that you
use ZIP or PXR24.

PIZ generates a fairly large header for every tile.  If the tile is not
very large, then the header and the compressed pixels together are larger
than the raw, uncompressed pixels.  When this is the case, the tile is
stored uncompressed.  In addition to being large, generating the header
is expensive.  If your tiles are small, a large number of headers are
generated, only to be discarded as soon as the IlmImf library notices that
storing the "compressed" tiles are larger than the uncompressed ones.

> 
> Question 2: I want to use Multithreading for writing an exr. Reading the 
> documentation i thought i just have to set the GlobalThreadCount and 
> then start the writePixels-function for every 20 scanlines (for example) 
> again and again and the interface would do the thread-stuff 
> automatically. But i don't see any effect. The writing takes exactly the 
> same time. What is the right way to do that?

When threading is enabled in the library, multiple scanline blocks or tiles
are processed concurrently.   A scanline block is 32 lines for PIZ compression.
Threading doesn't kick in unless each writePixels() call supplies multiple
blocks' worth of pixels.  For best threading performance, write the entire
image with a single writePixels() call.
See also Section 7.2 of http://www.openexr.com/ReadingAndWritingImageFiles.pdf.

> 
> Thanks for your replies.
> 
> David
> 
> 
> _______________________________________________
> Openexr-devel mailing list
> Openexr-devel <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/openexr-devel
>
Permalink | Reply | 0 comments |

Gmane