icetCompositeImage(3)
π icetCompositeImage(3) β bestie edition π
okay so this page is straight out of the IceT Reference manual and it's all about icetCompositeImage(3), aka the function that takes your already-rendered pics and smushes them into one glorious image. sit down, grab a boba, let's go π§β¨
πΈ NAME πΈ
icetCompositeImage β composites a pre-rendered image πΌοΈπ
β¨ Synopsis β¨
#include <IceT.h>
IceTImage icetCompositeImage(
const IceTVoid * color_buffer,
const IceTVoid * depth_buffer,
const IceTInt * valid_pixels_viewport,
const IceTDouble * projection_matrix,
const IceTDouble * modelview_matrix,
const IceTFloat * background_color );
π¦ Description π¦
So icetCompositeImage takes image buffer data and composites it into one single image. It behaves a lot like icetDrawFrame, except instead of using callback functions to render and retrieve image data, the images are pre-rendered and handed straight to icetCompositeImage. Real talk: it's more efficient to let IceT figure out rendering projections and use callbacks, but ngl it's often way more convenient for applications to just slot IceT in as a separate compositing step after the rendering. iykyk π«Ά
Before IceT can composite anything, you gotta set things up, no skipping steps bestie:
- the display needs to be defined (using
icetAddTile) - the buffer formats need to be specified (using
icetSetColorFormatandicetSetDepthFormat) - the composite strategy must be set (using
icetStrategy)
and the single image sub-strategy may optionally be set too (using icetSingleImageStrategy).
β οΈ every single process must call icetCompositeImage for the operation to complete on any process in a parallel job. no ghosting your group project, fr fr.
The color_buffer and depth_buffer arguments point to memory buffers that contain the image data. The image data is always stored in densely packed arrays in row-major order (a.k.a. x-major order or by scan-lines). The first horizontal scan-line is at the bottom of the image, with subsequent scan-lines moving up. β¬οΈ The size of each image buffer is expected to be the width and the height of the global viewport (which gets set indirectly with icetAddTile). The global viewport lives in the ICET_GLOBAL_VIEWPORT state variable. If only one tile is specified, then the width and height of the global viewport will be the same as that one tile. cute, simple, iconic π
π Color buffer formats π
The format for color_buffer is expected to be the same as what's set with icetSetColorFormat. The formats and their interpretations with respect to color_buffer are as follows:
ICET_IMAGE_COLOR_RGBA_UBYTEβ each entry is an RGBA color tuple. Each component is valued in the range from 0 to 255 and is stored as an 8-bit integer. The buffer will always be allocated on memory boundaries such that each color value can be treated as a single 32-bit integer. lowkey satisfying nglICET_IMAGE_COLOR_RGBA_FLOATβ each entry is an RGBA color tuple. Each component is in the range from 0.0 to 1.0 and is stored as a 32-bit float.ICET_IMAGE_COLOR_RGB_FLOATβ each entry is an RGB color triple. Each component is in the range from 0.0 to 1.0 and is stored as a 32-bit float. > heads up bestie: there is no alpha channel, so the color blending composite mode will not work with this color format. πICET_IMAGE_COLOR_NONEβ no color values are stored in the image.
π Depth buffer formats π
Likewise, the format for depth_buffer is expected to be the same as what's set with icetSetDepthFormat. Here's how that shakes out:
ICET_IMAGE_DEPTH_FLOATβ each entry is in the range from 0.0 (near plane) to 1.0 (far plane) and is stored as a 32-bit float.ICET_IMAGE_DEPTH_NONEβ no depth values are stored in the image.
If the current format doesn't have a color or depth, then the respective buffer argument should be set to NULL. π«₯
π¨ care should be taken to make sure that the color and depth buffer formats are consistent with the formats expected by IceT. Mismatched formats will result in garbage images and possible memory faults. not the vibe. do not do this. π
Also note that when compositing with color blending (icetCompositeMode is set to ICET_COMPOSITE_MODE_BLEND), the color buffer must be rendered with a black background in order for the composite to complete correctly. A colored background can later be added using the background_color as described below. β¨
π valid_pixels_viewport π
valid_pixels_viewport is an optional argument that makes it possible to specify a subset of pixels that are valid. In parallel rendering it's super common for a single process to render geometry in only a small portion of the image, and IceT can take advantage of that info. If the rendering system identifies such a region, it can be specified with valid_pixels_viewport. π―
Like all viewports in IceT, valid_pixels_viewport is an array of 4 integers in the form $<x, y, width, height>$. This viewport is given in relation to the image passed in the color_buffer and depth_buffer arguments. Everything outside of this rectangular region will be ignored. For example, if the valid_pixels_viewport $<10, 20, 150, 100>$ is given, then icetCompositeImage will ignore all pixels in the bottom 10 rows, the left 20 columns, anything above the $160^{th}$ (10+150) row, and anything to the right of the $120^{th}$ (20+100) column.
If valid_pixels_viewport is NULL, then all pixels in the input image are assumed to be valid. periodt π
π projection_matrix and modelview_matrix π
projection_matrix and modelview_matrix are optional arguments that specify the projection that was used during rendering. When applied to the geometry bounds information given with icetBoundingBox or icetBoundingVertices, this provides IceT with further information on local image projections. If the given matrices aren't the same ones used in the rendering, or the given bounds don't contain the geometry, IceT may clip the geometry in surprising ways. π If these arguments are set to NULL, then geometry projection will not be considered when determining what parts of images are valid.
π background_color π
The background_color argument specifies the desired background color for the image. It's given as an array of 4 floating point values specifying, in order, the red, green, blue, and alpha channels of the color in the range from 0.0 to 1.0. π
- When rendering using a depth buffer, the background color is used to fill in empty regions of images.
- When rendering using color blending, the background color is used to correct colored backgrounds.
As stated previously, color blended compositing only works correctly if the images are rendered with a clear black background. Otherwise the background color will be added multiple times by each process that contains geometry in that pixel. π΅ If the ICET_CORRECT_COLORED_BACKGROUND feature is enabled, this background color is blended back into the final composited image. slay π
π Return Value π
On each display process (as defined by icetAddTile), icetCompositeImage returns the fully composited image in an IceTImage object. The contents of the image are undefined for any non-display process.
If the ICET_COMPOSITE_ONE_BUFFER option is on and both a color and depth buffer is specified with icetSetColorFormat and icetSetDepthFormat, then the returned image might be missing the depth buffer. The rational behind this option is that often both the color and depth buffer is necessary in order to composite the color buffer, but the composited depth buffer isn't needed. In this case, the compositing might save some time by not transferring depth information at the latter stage of compositing. efficiency queen π
π¨ do NOT use this image after the next call to icetCompositeImage (unless you have changed the IceT context). The returned image uses memory buffers that will be reclaimed the next time IceT renders or composites a frame. it's giving ephemeral, bestie, respect the lifecycle π¦
π Errors π
ICET_INVALID_VALUEβ an argument is set toNULLwhere data is required. rude.ICET_OUT_OF_MEMORYβ not enough memory left to hold intermittent frame buffers and other temporary data. π
icetDrawFrame may also indirectly raise an error if there's an issue with the strategy or callback.
π¨ Warnings π¨
ICET_INVALID_VALUEβ an argument toicetCompositeImageis inconsistent with the current IceT state. vibe check failed π
π Bugs π
The images provided must match the format expected by IceT or else unpredictable behavior may occur. The images must also be carefully rendered to follow the provided viewport and projections. Images that are color blended must be rendered with a black background and rendered with the correct alpha value.
If compositing with color blending on, the image returned may have a black background instead of the background_color requested. This can be corrected by blending the returned image over the desired background. This will be done for you if the ICET_CORRECT_COLORED_BACKGROUND feature is enabled. π«Ά
π Copyright π
Copyright (C) 2014 Sandia Corporation
Under the terms of Contract DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains certain rights in this software.
This source code is released under the New BSD License.
π See Also π
icetAddTile(3)icetBoundingBox(3)icetBoundingVertices(3)icetDrawCallback(3)icetDrawFrame(3)icetSetColorFormat(3)icetSetDepthFormat(3)icetSingleImageStrategy(3)icetStrategy(3)
and that's the whole page bestie!! π this iconic lil doc came from the IceT Reference manual, dated October 9, 2014 β yeah she's an elder but she ate and left no crumbs πβ¨ go composite something beautiful, ily, bye ππ¦
π¦ where this page comes from
- debian bookworm: paraview 5.11.0+dfsg-1+b1 Β· BSD-3-Clause
- debian trixie: paraview 5.13.2+dfsg-3 Β· BSD-3-Clause
- ubuntu jammy: paraview 5.10.0~rc1-1build3 Β· BSD-3-Clause
- ubuntu noble: paraview 5.11.2+dfsg-6build5 Β· BSD-3-Clause
- ubuntu questing: paraview 5.13.2+dfsg-3
- ubuntu resolute: paraview 6.0.1+dfsg1-7 Β· BSD-3-Clause
- ubuntu stonking: paraview 6.1.1+dfsg1-2build1 Β· BSD-3-Clause
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms