Re: Deep data API: another batch of questions.

Hi Michel,

The following thread at nuke_dev may help you understand how the
deep samples should be written out for correct intepretation.

https://www.mail-archive.com/[email protected]/msg01495.html

On Tuesday, April 29, 2014, Michel Lerenard <[email protected]>
wrote:

>  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.
> <
>
>

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