Apex Post-Processing
Introduction
Before Apex, a rendering workflow would look like this, with each stage carried out on the CPU (central processing unit).
CPU-based workflow
Apex makes possible GPU (graphics processing unit)-based rendering, but post-processing steps such as applying tone curves are still carried out on the CPU.
GPU rendering, CPU post-processing
The highly-parallel architecture of a GPU suggests that an operation such as applying tone curves could be significantly faster if carried out on the GPU, but the overhead of transferring a raster to the GPU and back again can negate any performance advantage. Apex addresses this concern by carrying out post-processing on the GPU, before the result is retrieved.
Mako 8.0 allowed for two Apex post-processes:
Application of tone curves to the rendering result
Merging of spot colors post-render, primarily to support overprint preview
GPU-based post-processing
However, both were “built-in” to the rendering process, with no scope for customization.
Apex post-processing APIs
Mako 8.1 formalizes Apex’s post-processing capability, encompassing the two existing post-processes (tone curves and spot merging) and adding two new post-processing steps: color conversion and ink limiting.
Moreover, customizable post-processing steps are now possible, described in the next section.
| |
---|---|
| Color convert to a new color space. |
| Apply tone curves. |
| Merge spots. |
| Ink limiting via scaling. |
| Custom color manipulation on the GPU with a specially made shader. |
| Custom spot color manipulation on the GPU with a specially made shader. |
| Custom spot merging on the GPU with a specially made shader. |
Apex custom post-processing API
With the release of Mako 8.1, a new API is introduced that enables Mako developers to implement their own post-processing algorithms and have Apex run them on their behalf on the GPU, to change the raster at that stage of the workflow. A good example of this is screening, and an implementation of a traditional line screen is included in this documentation. Multiple post-processing steps can be added, each receiving the result of the previous step for further processing.
End-to-end workflow on GPU
Components of an Apex post-processing step
GLSL = OpenGL Shading Language, a C-like language for writing GPU programs in OpenGL.
Shader = A GPU program. The term comes from early graphics terminology related to computing lighting and shading on surfaces, but now includes all programmable GPU tasks.
The processing to be carried out on the GPU is written in GLSL and is known as a shader. A shader allows developers to write custom behavior for various stages of the rendering pipeline, such as:
Vertex shaders – transform each vertex's position in 3D space.
Fragment shaders – compute the color of individual pixels (fragments).
Geometry shaders, tessellation shaders, and compute shaders – for more advanced stages and general-purpose computation on GPUs.
Apex post-processing supports Fragment shaders only. Apex post-processing supports three categories of shader that operate on different aspects of the rendered result.
Post processes that operate on (process) color samples (
CCustomColorPostProcessSpec
)Post processes that operate on spot (color) samples (
CCustomSpotPostProcessSpec
)Post processes that merge spots into the color samples (
CCustomSpotMergePostProcessSpec
)
Each of these is described on the following pages, the content of which is derived from the API documentation.
The worked examples demonstrate how to get started, and exactly what code is required to implement a post-processing step.