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
