EditUtils: Config Json Parser lrzjason
Drive Your Reference Settings From a JSON String Instead of Twenty Widgets
- image
- configs
- mask
- configs
- config
Every other Config Preparer in this pack exposes one widget per setting. ConfigJsonParser_EditUtils takes the opposite approach: you hand it a JSON string describing the whole per-image configuration, it parses that string into a config dict, and appends it to the configs chain exactly like the widget-based preparers do. It's the node for people who'd rather version-control a blob of JSON than click twenty dropdowns.
The inputs: image (required), plus optional configs (the chain list), config_json (the settings as a string), and mask. The outputs match every preparer in the pack: configs (the appended list) and config (the current image's config dict). It chains identically to the others, so you can mix and match - a widget-based preparer for image one, a JSON parser for image two, both appending to the same list. The default config_json is a complete, valid starting point:
{"to_ref": true, "ref_main_image": false, "ref_longest_edge": 1024, "ref_crop": "center", "ref_upscale": "lanczos", "to_vl": true, "vl_resize": true, "vl_target_size": 384, "vl_crop": "center", "vl_upscale": "bicubic", "mask": null}
Read that default closely, because it's different from the model-specific preparers in two ways that will bite you. First, ref_main_image defaults to false here (the widget preparers default it true) - so a chain built on this node alone never declares a main image, and the encode step will fall back to the first config. If your output latent is coming out as the wrong reference, that's your culprit. Second, ref_crop defaults to center instead of pad - meaning content gets cropped rather than padded to the VAE grid, and you'll get no pad_info to undo it with. Neither is wrong, they're just a different (older, Qwen-flavored) default than the rest of the pack, and it's worth knowing the node isn't magically consistent with its siblings.
Mechanically it's simple and the source is easy to read: it starts from the default config dict, runs json.loads on your string, and updates the default with whatever you provided - your JSON overrides the defaults field by field. A malformed JSON string is caught and printed to the console, and the node carries on with defaults, which is both forgiving and a silent failure to watch for. The mask input wins over any mask key in the JSON (the node nulls the JSON's mask and applies the wired one), and as with the other preparers, a mask whose dimensions don't match the image is dropped with a warning.
When would you use this over the widget preparer? When you're generating configs programmatically - a script, a template you paste variations into, a workflow you share with a config_json people edit in one text box instead of hunting widgets. It's the power-user option, and for that audience it's the right one. Install: ComfyUI Manager (search "EditUtils") or git clone https://github.com/lrzjason/ComfyUI-EditUtils into custom_nodes, restart.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — | |
| configsopt | LIST | Configs list | |
| config_jsonopt | STRING | {"to_ref": true, "ref_main_image": false, "ref_longest_edge": 1024, "ref_crop": "center", "ref_upscale": "lanczos", "to_vl": true, "vl_resize": true, "vl_target_size": 384, "vl_crop": "center", "vl_upscale": "bicubic", "mask": null} | Config JSON String |
| maskopt | MASK | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| configs | LIST | — |
| config | ANY | — |