Hi Mike
Thanks for the link. The post confirm what I was thinking: each anti
aliasing sub sample has to be stacked into the pixel's deep samples, and
the type of filtering has to be taken into account to compute the alpha
values.
On 04/30/2014 02:43 AM, Mike Wong | ax.gmail wrote:
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/nuke-dev@support.thefoundry.co.uk/msg01495.html
On Tuesday, April 29, 2014, Michel Lerenard <michelisotro...@gmail.com
<mailto:michelisotro...@gmail.com>> 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
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
