HT Value Mapper

ComfyUI workflows end up full of magic numbers: steps, scales, resolutions, strengths. They're meaningful to you ("medium quality = 768"), but they're just digits to the graph. HT Value Mapper (from the HommageTools pack) is the lookup table that connects the two - you define a mapping of friendly labels to values, feed it a label, and it hands back the value in every type you could need: string, float, int, and boolean.

How it works

The core input is mapping_list, a multiline text field of label: value pairs. The default shows the pattern:

small: 512
medium: 768
large: 1024

You type whatever labels and values suit your workflow. Then input_value (an any-type socket) is matched against the labels - if you feed it the string "medium", you get 768 out. The node parses each value and converts it into every format simultaneously, so you can grab value_float for a strength, value_int for a resolution, or value_string if that's what the downstream wants. There's also boolean interpretation built in (bool_value and bool_int), so labels like enabled: true or mode: off resolve to proper booleans too.

The five outputs are the point: one mapping, every type you'd ever want, no conversion nodes in between.

When you'd use it

Anywhere you want a human-readable interface in front of a parameter. The README's own example pairs it with HT Parameter Extractor - extract a labeled control value from a prompt, feed the extracted label into the mapper, and get the numeric parameter out. But it stands alone just as well: turn a quality label into an actual step count, map a style name to a CFG value, translate a boolean-ish string into a real boolean for a switch. It's the node that turns a text-driven workflow into an enumerated, typed one.

Installing it

HommageTools install, once:

cd ComfyUI/custom_nodes
git clone https://github.com/ArtHommage/HommageTools.git
cd HommageTools
pip install -r requirements.txt

Restart ComfyUI, or ComfyUI Manager → "HommageTools". No models, no extra dependencies - it's pure string parsing.

Where it bites

The format is rigid. label: value with a colon; a stray extra colon or a missing separator and that line won't parse the way you expect. Match exactly, and remember the labels are matched as strings - case and whitespace matter, so "Medium" won't hit a mapping for "medium" unless you account for it. Unmatched inputs are the other trap: there's no obvious failure signal, so an unknown label silently produces empty/zero-ish conversions that propagate into your workflow looking like data. If a value suddenly comes out as 0, check whether the input actually matched a label. And the boolean interpretation is its own thing - "true"/"false"/"yes"/"no" style strings work, but arbitrary values resolve to whatever the node's rules say, so test one before trusting it in a logic path. For a lookup table that's all fair play - just be tidy with your mapping list and you're set.