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
