|
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.
On Tuesday, April 29, 2014, Michel Lerenard < address@hidden>
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.
<
|