Re: Deep data API: another batch of questions.

Hi,

thanks for your answer. I've read the InterpretingDeepPixels document 
already, and didn't find the answer I'm looking for.
I was quite vague in my last message, typically my question is: should 
the sampling (random, blue noise, etc...) and the filter type (box, 
blackman harris, etc...) used for antialiasing be applied to "bake" the 
deep samples in the file ?
I don't see any other option at the moment to ensure that samples are 
correctly blended, I'm wondering if another option is available.


On 04/29/2014 10:28 AM, Peter Hillman wrote:
> The only standard way to go is that you should write samples according 
> to the "InterpretingDeepPixels" document, and particularly you should 
> take care to guarantee that the "flattening" procedure described gives 
> you the correct RGBA image.
>
> Beyond that specification, there are no official recommendations 
> regarding how many samples you should write, or how and when to merge 
> samples.  It would make sense to anticipate what operations might be 
> applied to the deep image before it is flattened, including merging 
> with other deep images. One should ensure that there is appropriate 
> information for those operations to work as expected without storing 
> too many samples. Since it is hard for software developers to 
> anticipate how images are to be used, it makes sense that tools 
> provide options for end users to control output.
>
>
>
>
> On 29/04/14 19:27, Michel Lerenard wrote:
>> Thanks a lot, that did the trick.
>>
>> I got my export code working, both using Tiled and Scanline images, 
>> depending on user choice.
>>
>> I still one have question, that is more related to deep data than 
>> OpenEXR itself: how should I write anti aliasing samples values. I've 
>> seen that Houdini  writes all anti aliasing samples into the same 
>> data stack, and has an option to merge values. Is it the standard way 
>> to go ? (if there is one...)
>>
>> Thanks again for your help.
>>
>> On 04/22/2014 09:51 AM, Peter Hillman wrote:
>>> You can modify an existing FrameBuffer/DeepFrameBuffer object, using 
>>> something like this (untested!) code:
>>>
>>> outputfile.setFrameBuffer(...);
>>> outputfile.writePixels(32);
>>>
>>> /*later on*/
>>>
>>> FrameBuffer myFrameBuffer = outputfile.frameBuffer();
>>> myFrameBuffer["R"].base -= myFrameBuffer["R"].yStride*32;
>>> myFrameBuffer["G"].base -= myFrameBuffer["G"].yStride*32;
>>> myFrameBuffer["B"].base -= myFrameBuffer["B"].yStride*32;
>>> outputfile.setFrameBuffer(myFrameBuffer);
>>> outputfile.writePixels(32);
>>>
>>>
>>> Just don't forget to call setFrameBuffer. Admittedly there's 
>>> overhead, but not significant compared to the cost of writePixels.
>>>
>>>
>>> On 22/04/14 19:42, Michel Lerenard wrote:
>>>> I had a look at the sources and the docs, I misunderstood you post 
>>>> yesterday, I thought you meant there was a way to modify the 
>>>> pointers of a framebuffer. Creating a new framebuffer and insert 
>>>> new DeepSlices for every batch of lines was what I was trying not 
>>>> to do.
>>>> But reading your messages I guess there's no other option.
>>>>
>>>> On 04/21/2014 12:19 AM, Peter Hillman wrote:
>>>>> You will need to call setFrameBuffer before every call to 
>>>>> writePixels, as you need to update the frame pointers.
>>>>> The pointer you pass to Slice/DeepSlice is the memory location of 
>>>>> pixel (0,0) in the image. This point will move in memory as you 
>>>>> update your memory block with different scanlines.
>>>>>
>>>>> Your first call is probably doing the right thing. For each 
>>>>> subsequent call you need to set up a new FrameBuffer with 
>>>>> yStride*currentScanLine() subtracted from the base pointer, where 
>>>>> currentScanLine() is the y offset of the first scanline you are 
>>>>> writing.
>>>>>
>>>>> The library will only access the memory locations it needs to for 
>>>>> writePixels() - there's no problem in passing an "illegal address" 
>>>>> as a base pointer to setFrameBuffer, as long as 
>>>>> (base+yStride*currentScanLine() + dataWindow.min.x*xStride) is 
>>>>> always a valid location when writePixels() is called.
>>>>>
>>>>> The above is true for xSampling=1 and ySampling=1 - you may need 
>>>>> to adjust the logic accordingly otherwise.
>>>>>
>>>>>
>>>>> On 19/04/14 21:18, Lerenard Michel wrote:
>>>>>> Hi,
>>>>>>
>>>>>> still trying to write deep data image, i'm struggling a bit with 
>>>>>> FrameBuffers.
>>>>>> As I need to write subsampled deep images, I cannot use Tiled 
>>>>>> images. I went for the scanline approach. My idea was to write 
>>>>>> batches of n scanlines, in increasing Y order.
>>>>>>
>>>>>> This way I was thinking I would be able to limit the memory 
>>>>>> footprint:
>>>>>> OpenEXR would not need to cache data, and I would be able to 
>>>>>> reuse the same buffers for every batch of lines: one buffer for Z 
>>>>>> and one for each visible channel.
>>>>>>
>>>>>> So I created a bunch of buffers, whose size was my image width * 
>>>>>> 32. (arbitrary value). I planned to feed these buffers to the 
>>>>>> DeepSlices I added to the FrameBuffer.
>>>>>> Thing is, it appears the FrameBuffer/Slices cannot work that way: 
>>>>>> they need to have memory allocated for the whole image. I 
>>>>>> couldn't find any function limiting / defining the region I want 
>>>>>> to work on.
>>>>>>
>>>>>> Here are my questions:
>>>>>> - Is the statement above correct ?
>>>>>> - Should I work differently ? I doesn't look like using several 
>>>>>> framebuffers would help, I out of ideas at the moment.
>>>>>>
>>>>>> I can explain in more details my process if it can help.
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Michel
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Openexr-devel mailing list
>>>>>> [email protected]
>>>>>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>>>>>
>>>>> . 
>>>>
>>>
>>
>

_______________________________________________
Openexr-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/openexr-devel