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
>