Skip to main content
Skip table of contents

Apex Post-Processing

Introduction

Before Apex, a rendering workflow would look like this, with each stage carried out on the CPU (central processing unit).

Slide1.SVG

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.

Slide2.SVG

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

Slide3.SVG

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.

JawsMako::IPostProcessSpec::ePostProcessType

ePPTColorConversion

Color convert to a new color space.

ePPTToneCurves 

Apply tone curves.

ePPTSpotMerge 

Merge spots.

ePPTInkLimit 

Ink limiting via scaling.

ePPTCustomColor 

Custom color manipulation on the GPU with a specially made shader.

ePPTCustomSpot 

Custom spot color manipulation on the GPU with a specially made shader.

ePPTCustomSpotMerge 

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.

Slide4.SVG

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.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.