[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Openexr-devel] Writing Deep tiled images: help !
From: |
Larry Gritz |
Subject: |
Re: [Openexr-devel] Writing Deep tiled images: help ! |
Date: |
Thu, 10 Apr 2014 17:02:09 -0700 |
Uh oh.
I knew about RANDOM_Y for scanline images. Are you saying that for tiled
images, if we don't set lineorder to RANDOM_Y, then there's internal buffering
if we send the tiles in anything but canonical order?
On Apr 10, 2014, at 4:54 PM, Peter Hillman <address@hidden> wrote:
> In general with OpenEXR, you cannot write to a file from different threads
> unless they have a shared framebuffer. Calling "setFrameBuffer" from one
> thread while another is writing may cause a crash.
>
> Even if you do have a shared framebuffer, the threads lock to serialise the
> writes: only one "writePixels" or "writeTile" request goes through at once.
> If you don't use the IlmThread library to run your threads it may be wise to
> implement your own lock mechanism around writePixel and writeTile calls.
>
>
> There are two ways of writing tiled data: if you use xTileCoords/yTileCoords,
> then pixel(0,0) is the bottom left corner of each tile, implying the image
> buffer pointed to by the slice is the same size as the tile.
> if you don't do that, then pixel(0,0) is the bottom left corner of the
> displayWindow, implying the image buffer pointed to be the slice is the size
> of the dataWindow, accounting for offset data windows appropriately.
>
> In your case, it would seem like you want the second option: preallocate your
> dataWindow sized array of pointers-to-samples, and call setFrameBuffer before
> any rendering begins.
> Then each thread sets the pointers to the samples for the tile it is going to
> write and fills in the corresponding part of the samplecount array before
> calling writeTile.
>
> The pointers need not be valid when setFrameBuffer is called. When you call
> writeTile, only the pointers and sampleCount data for the pixels being
> written need to be valid, and need not remain valid afterwards. So yes, you
> can delete data for the actual sample data of a tile after calling writeTile,
> though you'll need to keep the sampleCount array and the pointers-to-samples
> array for each channel.
>
> Note that if you are writing tiles in anything other than RANDOM_Y order,
> then whenever your threads deliver tiles out of order OpenEXR will have to
> buffer data so it can write the tiles sequentially.
> I suspect this may well be the case from multithreaded write applications.
> With deep data this could take a significant amount of memory.
> You may wish to enforce RANDOM_Y order to allow the library to write tiles to
> disk as soon as you call writeTile. If your read pattern is generally also
> random, rather than in 'scanline order', there'll be little performance hit.
>
> You might also consider having one worker thread managing the writing of tile
> data and marshalling into the format required for the DeepSlices, and have
> other threads compute data and signal the worker thread when they have tiles
> ready for processing.
>
> Yes, you can use an Array2D<float*> for your data points (dataZ and dataA in
> the example). Each value is a pointer to the first sample of the channel data
> for each pixel.
> Subsequent samples are found using the offset provided. That means you can
> store pixel data in separate or interleaved channels.
>
>
>
> On 11/04/14 02:16, Michel Lerenard wrote:
>> Hi,
>>
>> I'm trying to write deep data into an EXR file and am having trouble
>> understanding how the API works.
>> I'd like to be able to write tiles from different threads. The application
>> I'm working on (Isotropix Clarisse) runs several threads, each one render a
>> part of an image.
>> I'd like to write deep data when the current tile is completely computed.
>>
>> I'm using the "Reading And Writing Image Files" documentation, and the
>> section about Deep Tile File writing on page 26 is confusing to me.
>>
>> From what I understand, I need a DeepFrameBuffer to write an image. It seems
>> it should be the same for all threads, as a DeepTiledOutputFile can only use
>> one. Is it thread safe ? Can I use the same FrameBuffer from all threads ?
>> I was puzzled by the type of dataZ and data0, reading the next example
>> (reading a deep tiled file) I understand that the arrays are only storing
>> pointers to deep data for a particular pixel, and that they could as well be
>> Array2D<float*>. Is that correct ?
>>
>> If it is, this means that each one of my threads should set pointers in the
>> framebuffer DeepSlice for each pixel of the tile it's computing, then call
>> writeTile. After that can I delete the data and reset the pointers in the
>> DeepSlice ?
>>
>>
>> Thanks,
>>
>> Michel
>>
>>
>> _______________________________________________
>> Openexr-devel mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/openexr-devel
--
Larry Gritz
address@hidden
- [Openexr-devel] Writing Deep tiled images: help !, Michel Lerenard, 2014/04/10
- Re: [Openexr-devel] Writing Deep tiled images: help !, Peter Hillman, 2014/04/10
- Re: [Openexr-devel] Writing Deep tiled images: help !,
Larry Gritz <=
- Re: [Openexr-devel] Writing Deep tiled images: help !, Peter Hillman, 2014/04/10
- Re: [Openexr-devel] Writing Deep tiled images: help !, Michel Lerenard, 2014/04/11
- Re: [Openexr-devel] Writing Deep tiled images: help !, Larry Gritz, 2014/04/11
- Re: [Openexr-devel] Writing Deep tiled images: help !, Larry Gritz, 2014/04/11
- Re: [Openexr-devel] Writing Deep tiled images: help !, Piotr Stanczyk, 2014/04/11
- Re: [Openexr-devel] Writing Deep tiled images: help !, peterh, 2014/04/12
- Re: [Openexr-devel] Writing Deep tiled images: help !, Larry Gritz, 2014/04/12
- Re: [Openexr-devel] Writing Deep tiled images: help !, peterh, 2014/04/12