Palette
A Layer 2 picture carries its own 256-colour palette, and NextDither builds that palette for you every time it converts. Two parts of the window are about it: the Palette tab in the control rail, which decides how the palette is chosen, and the palette dock along the bottom edge, which shows you the palette the last conversion actually produced and where every colour in it is used.
The Palette tab
Palette mode
Three modes are offered:
- Adaptive (Wu) - Wu's quantiser, run over the RGB333 grid the Next actually displays. The histogram is built in RGB333-snapped space, so every colour it picks is exactly representable and nothing is lost to a later snap. When the image reduces to no more than the number of free slots, the palette is exact and no box cutting happens at all.
- Adaptive (K-means) - k-means over the same grid, measuring distance in OKLab. Slower than Wu and usually better. Its seeding is deterministic by construction rather than seeded-random, so the same image gives the same palette on every machine.
- RGB332 (fixed) - the Next's standard palette, where slot N holds colour N. This is the same palette
gfx2next -pal-stdproduces, so it is the mode to pick when a picture has to share a palette with art converted by other tools. It is not adapted to your image at all, so an adaptive mode will almost always look better on its own.
Note one detail of the fixed palette: slot 227 of a literal RGB332 identity palette would hold a colour whose first byte is the reserved transparency value, which is not allowed anywhere except index 255. NextDither moves it to the nearest permitted colour rather than writing it, so the file already agrees with what the hardware will show. See Transparency for what that reserved value is and why it matters.
Colour count
The Colour count slider sets how many colours the quantiser may choose. Its ceiling is not a fixed 256 - it is however many slots the loaded preset leaves free for the quantiser to allocate.
Under the stock NextDAAD preset that ceiling is 255, not 256. The preset marks slots 0 to 254 as free and keys slot 255 to #FF00FF for transparency, and a keyed slot is never handed to a quantiser. Index 255 belongs to the transparent colour and nothing else may be allocated there, which is exactly the rule Transparency exists to explain. A ceiling of 256 here would mean the slider was ignoring the preset, and artwork could end up on the transparent index.
If a colour count larger than the free-slot count reaches the pipeline some other way - a hand-edited preset, say - it is clamped rather than obeyed, and a warning names both numbers: "requested 200 colours but only 6 slots are free; clamped to 6".
Freeze palette
An adaptive palette is a function of the adjusted image, so every time you move Brightness, Contrast, Gamma or Saturation the palette is rebuilt underneath you and the whole picture changes at once. Freeze palette holds the palette still so you can work the tone controls against a fixed set of colours: it is the difference between tuning contrast and chasing it.
While the tick is on, the mode dropdown and the Colour count slider are disabled and a line beneath them reads "Mode and colour count are ignored while the palette is frozen." The palette is captured from the next conversion after you tick the box, and every conversion after that reuses it.
A frozen palette will make a brightened image look worse, and that is the control working, not a fault. The picture is being mapped onto a palette chosen for the tones it had before you touched anything, so pushing the brightness well off zero gives you banding, or colours that no longer quite fit. What you are seeing is how much of the previous look depended on the palette moving with the image. Untick the box and the palette is rebuilt for the current tones; unticking also discards the captured palette, so nothing lingers.
Two things worth knowing about the freeze:
- If a frozen palette contains an entry that collides with the reserved transparency value, the warning says so and tells you to unfreeze, since the quantiser is the thing that would otherwise have avoided it.
- Changing the slot policy or the forbidden-colour set drops the freeze automatically, because a palette captured under one policy is not valid under another. Loading a preset that changes only the quantiser does not drop it, so the new mode appears to do nothing until you unfreeze.
The palette dock
The dock is a full-width strip along the bottom of the window, above the status bar. Hide at the left of its heading row collapses it and gives the vertical space back to the preview; the button then reads Show.
The heading reads Palette (256 slots), followed by one of two labels:
live - the palette the most recent conversion builtfrozen - every conversion uses this palette until unfrozen
If the loaded preset's transparency slot is Pinned rather than Keyed, an amber line appears above the grid: "The transparency slot is not keyed. Pixels painted #FF00FF will be quantised as ordinary colour, not turned into holes.", beside a button reading Set it to keyed #FF00FF. See Transparency and Presets for what this warns about and what the button does.
Beneath that, all 256 slots are laid out in four rows of 64, in index order, so slot 0 is the first cell of the first row and slot 255 is the last cell of the last. The column count only ever steps down - to 32, then 16 - and only on a genuinely narrow window; each cell is capped at a maximum size, so widening the window leaves space unused at the edge rather than inflating the dock into the preview.
The four slot states
Every slot is in one of four states, and the state is part of the preset rather than something the picture decides:
- Free - the quantiser may allocate it and the ditherer may emit it. Ordinary artwork lives here.
- Blocked - never allocated, never emitted, written to the file as black.
- Pinned - the colour is fixed and written to the file, but no quantiser allocates it and the ditherer never chooses it.
- Keyed - source pixels matching the key colour are routed straight here, bypassing quantisation and dithering entirely. This is how the stock preset makes slot 255 transparent.
Reading the grid
A slot nothing uses is drawn hollow - an empty ring with a thin edge of the colour it would hold - so how much of the palette is spare is obvious at a glance. Drop Colour count to 8 and almost the entire dock turns hollow.
Pinned slots are exempt from that. A pinned slot is written to the file but never allocated, so zero usage is correct for it rather than spare capacity, and drawing it hollow would be a lie. Keyed slots are not exempt: a keyed slot whose colour appears nowhere in your source genuinely matched nothing, and hollow is the honest answer.
Two rings can appear over a cell. A white ring marks the selected slot. An amber ring marks a collision - an entry whose first byte packs to the reserved transparency value at an index other than 255. A collision under a selection stays visible; the rings do not hide each other. See Transparency for what a collision means for your exported file.
A white T is drawn in the centre of whichever slot the preset nominates as its transparency slot.
Selecting a slot
Click any cell and every pixel in the result pane that does not use that slot dims toward grey, leaving only the pixels that do use it at full colour. It is the fastest way to answer "where did this colour end up". Click the same cell again to clear the selection and return the pane to normal.
You can also go the other way: click a pixel in the result pane and the dock selects whatever slot that pixel uses. Picking is bound to a click and never to a drag, so panning the image around cannot change your selection however hard you try. The source pane is not pickable, and neither is the result position while you are holding Space to flip - see The preview.
Collapsing the dock while a slot is selected clears the selection first, so you are never left with a dimmed result pane and no visible control to undo it.
The detail line
With a slot selected, a line above the grid names, in this order: the slot index, its colour as #RRGGBB, its RGB333 triple, its state, and its pixel count with a percentage of the whole picture.
slot 12 #B6496D (5,2,3) Free 1234 px (1.5%)
Which slot, which colour and which counts you see depend entirely on what the quantiser chose for your picture; only the shape of the line is fixed. The whole detail line - index, colour, triple, state and count alike - dims while a conversion is still in flight, because a precise figure describing a superseded conversion is a wrong answer to a precise question. The swatches in the grid do not dim, and that difference is deliberate: a stale swatch is still a real colour that a real conversion produced.
The dock is read-only, deliberately
You cannot edit a slot from the dock, and that is a decision rather than an unfinished feature. NextDAAD's picture format constrains exactly two things about a palette: index 255 is the transparency slot, and no other entry may carry the reserved first byte. The pipeline already enforces both - generated palettes are checked against the forbidden value and moved off it before anything is written, and the transparency slot is never allocatable. There is nothing left for hand-editing to fix, so the dock exists to let you see what the quantiser did and find any colour in the picture, not to manage slots the format never asked you to manage.
Slot states and the transparency slot come from the preset, which is where they can be changed. See Presets and The preset file.