Re: [Openexr-devel] OpenEXR 1.4.0 released

[Florian Kainz]

Hi Barnaby,

I am not entirely sure if I understand your question; I hope my
answer doesn't miss the point of your mail...

setGlobalThreadCount() creates a global "thread pool".  When your
application calls readPixels(), writePixels(), readTiles() or
writeTiles(), the IlmImf library examines if your application's
request is large enough to be broken up into smaller chunks that
can be processed concurrently.  The library then grabs as many
threads as necessary from the thread pool and tells each thread
to process one or more of those chunks.

Your application performs three sequential steps: 1) read an image
from an input file, 2) process the pixels, 3) store the results in
an output file.

The IlmImf library will not magically overlap steps 1 and 3 so that
reading the input file and writing the output file happen concurrently.
However, the library will use its thread pool to accelerate steps
1 and 3.  (For tiled files you should replace the loop over the tiles
with a single call to the new readTiles() or writeTiles() function.)

Sharing threads between file input and file output is relevant only if
your application is multi-threaded.  For example, if your application
processes a long sequence of images, then it might have three threads:
one thread reads the input files, the second one does pixel processing
and the third one writes the output files.  In this case file reading
and writing do overlap.  Most of the time you will have two files open
at the same time: one for input and one for output.  You want to make
sure that the IlmImf library splits its thread pool evenly.  If you
set the global thread count to 4, then you should set numThreads to 2
for each of the files you open for reading and writing.

Florian



Barnaby Robson wrote:
> Hey OpenEXR coders,
>
> Sorry if this is a really stupid question and feel free to quietly 
> chuckle at me from your desk if it is .... 
>
> In the docs it mentions setting the global thread count with 
> setGlobalThreadCount()
> and then sharing the threads between reading and writing files with 2 going
> to each process. 
>
> In one of my programs I read a file into a frame buffer in one big chunk if it 
> is a
> scanline file (or read all tiles in a loop if it is tiled).
> I then process the pixel data by looping through scanlines to find the DOD and 
> then
> loop through the pixel data over a user specified tile size (unrelated to the EXR tile size 
> to look for bad render buckets) and then I write out a new file. 
>
> Am I likely to need to share threads between reading and writing in this case 
> or not ?
> In the code it seems like all the reading gets done before the writing but I am
> wondering if there is some compiler magic that takes place that makes things all
> happen concurrently.
>
> Thanks ! 
>
> Barnaby.
>
>
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden
> Behalf Of Drew Hess
> Sent: Wednesday, August 02, 2006 2:14 PM
> To: address@hidden; address@hidden
> Subject: [Openexr-devel] OpenEXR 1.4.0 released
>
>
>
> Hi all,
>
> I'm happy to announce the release of OpenEXR 1.4.0.  This is the next
> major production-ready release of OpenEXR and offers full
> compatibility with our last production release, which was 1.2.2.  You
> can download the source code here:
>
> http://download.savannah.gnu.org/releases/openexr/openexr-1.4.0.tar.gz
>
> When I'm back from SIGGRAPH next week, I'll upload pre-compiled
> versions for Windows (for both Visual Studio 2003 and 2005) and for OS
> X 10.4.
>
> This version obsoletes version 1.3.x, which was the beta test version
> for 1.4.0.  If you have been using 1.3.x, please upgrade to 1.4.0.
> Please do not ship applications with 1.3.x, it had a few significant
> bugs that are fixed in 1.4.0.
>
> The major new feature in OpenEXR 1.4.0 is support for multithreaded
> reading and writing of files.  Developers, please see the developer
> documentation for information on how to enable threading support in
> your application.
>
> Here's a full list of changes in 1.4.0:
>
>     - Multithread support for reading and writing an OpenEXR
>       file.
>     - Support for Intel-based OS X systems.
>     - Support for Visual Studio 2005.
>     - When compiling against OpenEXR headers, there's no longer any
>       need to define any PLATFORM_* or HAVE_* macros; OpenEXR now
>       supplies an OpenEXRConfig.h header file which is included by
>       the OpenEXR headers that need these special macros.  However,
>       on Windows platforms, when using OpenEXR DLLs, you must still
>       define the OPENEXR_DLL preprocessor directive in your project.
>     - New documentation for multithread support, plus some
>       updates and additions.
>     - Bug fixes releated to better handling of incomplete/damaged 
>       files.
>     - Numerous bug fixes and cleanups to the autoconf-based
>       build system.
>     - Removed support for the following configurations that were
>       previously supported.  Some of these configurations may happen
>       to continue to function, but we can't help you if they don't,
>       largely because we don't have any way to test OpenEXR on these
>       configurations.
>            - IRIX 
>            - OSF1
>            - SunOS
>            - OS X versions prior to 10.3.
>            - gcc on any platform prior to version 3.3
>
> If you are using OpenEXR on one of the deprecated platforms listed
> above, let me know *privately* (don't bug the list members), and we'll
> see if we can work something out with you, if you're willing to do
> some testing (at least).  Of course, previous versions of OpenEXR will
> still work on these platforms, excepting any bugs that were fixed in
> 1.4.0.
>
> thanks,
> d
>
>
>
>
> _______________________________________________
> 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