Custom spot merge post-processing
An Apex custom post process step that merges spot components into an existing process result.
A CCustomSpotMergePostProcessSpec represents a custom post process step that merges spot components into an existing process result. It is a custom version of CSpotMergePostProcess that allows a
custom fragment shader to perform this work in order to implement special behavior, such as dealing with complex color interactions.
This step provides a list of the colorant names that it will merge, and a series of shader parameters that are invoked to merge them.
Currently, Apex will invoke this step with spot components provided four at a time.
Therefore, each step must provide a
CShaderParamsfor each invocation that this represents. For example, if nine merge colorants are specified, then threeCShaderParamsmust be provided. The first for the first four spots, the second for the next four spots, and the third for the last remaining spot. The same shader can be used for all three as appropriate.
The shader is ultimately invoked over the entire image. However, Apex may break rendering into multiple tiles, in which case the draw operation may occur multiple times.
The first input to the shader is the current value of the process components.
If the current color space at the point where this post process is inserted is a gray color space, then the process components will be a single single-channel UNORM image.
If RGB, then the input will be a single four-channel
UNORMimage with theAcomponent ignored.If CMYK, the input will be a single four-channel
UNORMimage, whereRrepresents Cyan,Grepresents Magenta,Brepresents Yellow, and theAchannel represents Black.If extended-gamut, then there will be two four-channel
UNORMinput images, where the first image represents the CMYK components, and the second image represents the extra extended components, with the first such
component in theRchannel.
Following the input process image(s), a single four-component UNORM image will be provided containing the spot tints to be merged for that invocation, with R being the first spot, G being the second, and so forth.
The output image(s) are as per the input, with the same format.
ℹ️ Please note that all the input and output images are in additive form. That is, the components are stored with 0.0 being 100% ink and 1.0 being 0% ink. This mirrors the PDF transparency compositing methods. So take care when interpreting these colors in the shader.
Push constants may be provided to the shader. However, in addition to any supplied push constants, Apex will push an additional two integer values after these push constants representing the top-left offset of the tile being rendered. This, in conjunction with the GLSL gl\_FragCoord variable, allows the shader to discover the current coordinate on the final page render, should this be needed.
The size of the push constant buffer is limited, and may differ from GPU to GPU. Vulkan guarantees a minimum of 128 bytes, but remember that Apex will push eight
additional bytes for tile coordinates, and therefore the minimum guarantee is 120 bytes. In practice, most GPUs will allow significantly more.
Please see: https://vulkan.gpuinfo.org/displaydevicelimit.php?name=maxPushConstantsSize for supported sizes for current GPUs.
The shader and textures may be created by IApexRenderer::createFragmentShader() and IApexRenderer::uploadImage().
Any textures are provided to the shader after the input images.
For example, consider a custom step where:
the current color space is extended gamut (e.g. CMYKOG)
two textures are provided
a single floating point value for a push constant is provided
The shader would have a structure such as the following: