A DTF spot channel is a separate grayscale raster plane assigned to a production ink role, most often white. It is not the colour composite and it is not PNG transparency. A reliable handoff defines the plane’s role, name, polarity, dimensions and mapping, then verifies all five in the exact RIP/version before output. A familiar label such as W1 is useful, but never universal proof.
Separate colour, alpha, and production ink planes
One design can carry several different kinds of information that look similar in a thumbnail but have different jobs:
- Colour raster: the RGB or CMYK values used to reproduce the visible artwork.
- Alpha: per-pixel opacity attached to a colour image. Alpha can describe a cut-out edge, soft shadow or distress, and can be used as an input when generating white.
- White plane: a separate single-channel mask intended to map to white ink in the production workflow.
- Varnish plane: an optional separate mask intended to map to a clear/varnish role in a workflow that supports it.
- Channel name and metadata: labels and file structures that help an application identify each plane’s role.
These are not interchangeable. A transparent PNG can carry RGB plus alpha, but it does not contain a named white-ink spot channel. A prepress application or RIP may derive white from alpha. Once derived, the white plane has its own geometry and density controls and should be inspected separately.
Likewise, a grayscale image named “W1” is not necessarily a mapped ink. The receiving application must import it as the intended production separation. If it appears as visible grey in the colour composite, disappears, or maps to another ink slot, the file has not completed the handoff.
The TIFF-versus-PNG guide covers the container decision. This article stays with the planes inside a spot-bearing handoff.
Read the plane semantics before reading the names
A name is only one part of the contract. Polarity—the meaning of dark and light values—matters just as much.
| Plane or signal | What it represents | Value meaning in the current NestSheet path | Handoff question |
|---|---|---|---|
| RGB/CMYK primary channels | Visible colour components | Container-specific colour samples | Which source interpretation and RIP conversion will be used? |
| Alpha | Opacity of the colour image | 0 = transparent, 255 = opaque | Is alpha merely transparency, or will the RIP derive white from it? |
| Generated white mask / preview | Intended white ink coverage before output serialization | 0 = no generated coverage, 255 = full generated coverage | Is this a generation preview or the serialized output plane? |
| Serialized W spot plane | White ink data written to the current NestSheet output | The generated mask is inverted: 0 = full white ink, 255 = no white ink | Does the target import preserve or invert the expected white coverage? |
| Serialized V spot plane | Intended clear/varnish coverage in the current output | 0 = no varnish, 255 = full varnish | Does this queue support the plane and map its polarity correctly? |
| Name | Human/application identifier | Editable output names with W1–W8 and V1–V4 defaults | What exact label and mapping has been validated for this RIP/version? |
The inversion between the generated white mask and serialized W plane—and the different V convention—is a reason to verify the image, not a suggestion to edit raw bytes by hand. Containers and applications can display spot masks with different visual conventions. The decisive test is what the target RIP preview says will be printed.
Dimensions and alignment are part of the same contract. Every production plane should cover the same output canvas and registration origin as the colour raster. A plane can have the correct name and still be unusable if it is scaled, cropped, mirrored differently or offset on import.
White generation also has an upstream source decision. NestSheet’s current white source is either eligible file-supplied white or alpha-derived white. In the alpha path, threshold decides which source opacity enters the base mask; choke erodes that geometry inward; mode/halftone can alter distribution; amount scales white density. None of those controls mechanically realigns a printer.
How NestSheet writes TIFF and PSD/PSB spots
NestSheet’s current export matrix exposes several valid rows rather than treating every format/channel combination as possible. PNG is colour plus alpha. The current flattened raster PDF has no separate white or varnish spots. TIFF and PSD/PSB are the spot-bearing output lanes.
| Choose | Current NestSheet structure | Practical decision |
|---|---|---|
| TIFF | Selected colour primaries plus separate named W/V planes in supported rows | Use when the validated RIP handoff expects the supported TIFF structure |
| PSD/PSB | Flattened composite plus real extra Photoshop spot channels; PSB is used when document limits require it | Use when the validated handoff expects Photoshop spot-channel structure; do not expect an editable layer stack |
TIFF
For a spot-bearing TIFF row, NestSheet writes the selected colour primaries followed by separate W and, where the row supports it, V planes. The current output name families are W1 through W8 and V1 through V4, with only the combinations allowed by the selected matrix row. The combined white-plus-varnish rows currently top out at four white and four varnish planes; eight white names being available in other rows does not mean every combination is valid.
The current TIFF writer stores extra plane names in a Photoshop image-resource block. It does not claim that every TIFF reader will discover those names through one universal InkNames convention. An application that opens the colour image proves only that it can decode the container—not that it has mapped the extra planes to production inks.
For intake, current file-plane passthrough is narrower than “any file with something called White.” The eligible path is a separated CMYK TIFF with the required detected white sources; otherwise the visible source falls back to alpha-derived white. A PSD may contain extra channels as source artwork, but current NestSheet output should not be described as arbitrary input-channel preservation.
PSD and PSB
The current writer creates a flattened composite plus real extra Photoshop spot channels. PSD or PSB is selected according to document limits; “PSD export” therefore does not mean an editable layer stack. CMYK primary data follows the PSD container convention, while spot masks retain their defined bytes. The target application still decides how those channels are presented and whether a RIP import maps them as inks.
This distinction keeps two claims separate:
- File structure claim: NestSheet emitted separately named planes in the selected supported output row.
- Production compatibility claim: a particular RIP, version and queue imported those planes with the intended name, polarity, scale and ink mapping.
The first can be checked against the exported file. The second requires the actual downstream environment.
Why W, W1, and White are not interchangeable promises
Channel naming is a local interface contract. One workflow may look for W1; another may ask the operator to map a plane named White; another may derive white internally and ignore supplied planes. Vendor product families can also change import behavior across versions or queue presets.
NestSheet supplies editable W1–W8 and V1–V4 output names. Those are NestSheet defaults, not a claim that every vendor expects them. A NestSheet RIP or handoff preset proves only the fields NestSheet is configured to emit. It does not automatically inspect the installed RIP, negotiate its version, create a hotfolder or guarantee printer output.
The live RIP hub separates general workflow guidance from the three current vendor-specific handoff pages: MainTop, CADlink and AcroRIP. Use each page as a starting configuration record, then compare it with the exact target manual and queue. Do not extend one page’s name or mirror rule to an untested product.
This is also why multiplying a white plane is not automatically “more white.” Multiple W planes can be a required file structure or printer mapping in a particular workflow, but only the downstream setup determines how they drive ink. The operator should not infer density from channel count alone.
Varnish requires an even clearer boundary. NestSheet can emit varnish planes in supported TIFF/PSD rows, but dedicated UV-DTF mode is roadmap. A file-format capability is not a claim that the current DTF Studio supplies a complete UV-DTF production workflow.
Verify the RIP handoff before printing
Use a deliberately small proof file with obvious colour, white and no-white regions. Import the exported production file into the exact queue that will print it, then verify:
- Physical dimensions: the RIP reports the intended width and height with no fit-to-media scaling.
- Colour composite: expected colour appears once, without a grey spot mask flattened into it.
- Plane discovery: every intended white/varnish plane is visible separately; no unexpected plane appears.
- Names: the imported labels match the names you intended to emit.
- Ink mapping: each plane is assigned to the correct device ink role rather than merely listed.
- Polarity: intended solid-white areas show coverage and intended empty areas show none.
- Alignment: colour and production planes share the same origin, scale, crop and mirror state.
- Underbase geometry: threshold and choke results look correct at hard edges, thin strokes and intentional fades.
- Output settings: screening, ink limits, passes, resolution and queue controls belong to the locally tested RIP/printer setup.
- Controlled print: inspect film and one pressed sample before releasing an unfamiliar format or mapping to a full run.
The visual technique in reading a RIP’s white-channel preview helps distinguish the colour composite from the underbase. The broader DTF RIP comparison is appropriate when the unresolved choice is the RIP itself.
Record the tested combination: NestSheet output row, channel names, file dimensions, RIP product/version, queue, printer and date. That receipt is stronger than any statement that a format is “universally compatible.”
Sources
- CADlink, Digital Factory Direct-to-Film Edition: https://cadlink.com/product/digital-factory-direct-to-film-edition
- CADlink Help, Queue menu — Output: https://help.cadlink.com/website/digital_factory/en/production/menus/queue_menu_output.htm
Mutable vendor documentation checked July 2026. NestSheet plane counts, names, polarity and container representation were verified against the shipped repository on 21 July 2026; target-RIP mapping remains version- and queue-specific.
