JSON process
Pull four values out of a JSON string with dotted-path queries
- value_1
- value_2
- value_3
- value_4
Feed it a JSON string, give it up to four paths, get back up to four extracted values. That's json_process (the class name is lowercase, don't go hunting for a capitalized version). It's the natural companion to ImageMetadataReader: that node hands you a big JSON blob of PNG metadata, and this one digs the specific bits out - the width, the height, the A1111 parameters line, the SillyTavern character card.
The inputs:
json_data- the JSON string. It'sforceInput, so you wire it from a string output (likeImageMetadataReader'smetadata_json); you can't just type a blob into it.query_1…query_4- the paths to extract, with a proper little query language:key1.key2[0].key3[2]for nested keys and array indexing. The author's tooltip spells it out: "支持key1.key2[0].key3[2]这种查询语法" - i.e. dotted keys, square-bracket indices, mixed freely. Defaults arewidth,height, andpng_text.parameters, which line up exactly with whatImageMetadataReaderemits.
The outputs: value_1 … value_4, strings. A scalar becomes its string form; a nested dict or list becomes pretty-printed JSON (indent 2), which is a thoughtful touch - you can grab a whole object without losing structure. A missing or malformed query returns a friendly 错误: (error) message instead of killing the run.
Mechanically it's a small regex-driven path walker: split the path on dots (but not dots inside a number) and brackets, then descend. It handles the "wrong type" cases - indexing a non-list, keying a non-dict - and reports which key failed, which is exactly the kind of error message that makes JSON digging bearable.
Where it earns its keep: any workflow that consumes metadata. Pull png_text.parameters off a found PNG and feed it to a text model; pull png_text.chara off a SillyTavern image and route it to TextEncoderDecoder for the base64 card; grab a seed or width out of a workflow JSON. If your JSON comes from somewhere else entirely (an API response in a string), it works there too - it doesn't care where the string came from.
One honest note: the default query paths are clearly tuned for ImageMetadataReader output, so if you're pointing it at a different JSON shape, remember it's four independent queries - empty query means empty output, and each query is optional to fill.
Install
ComfyUI Manager → search comfyui-spawner-nodes → install → restart. Or:
cd ComfyUI/custom_nodes
git clone https://github.com/spawner1145/comfyui-spawner-nodes
Deps: piexif, pypng, xmltodict - light pure-Python, no models. README is a stub, UI labels are Chinese, author is spawner1145 (of a Wan2.1 SD extension). Works, thinly documented.
Troubleshooting
- "无效的 JSON 字符串" - the input isn't valid JSON. Usually you wired the wrong string, or the source emitted an error object (
ImageMetadataReaderreturns error JSON for unreadable files - read that first). - "错误: 未找到键 'parameters'" - the path doesn't exist in this particular JSON. Check the actual shape with a JSON viewer, or query
png_textfirst to see what keys exist. - All four outputs empty - you left queries blank. An empty query returns an empty string by design.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| json_data | STRING | — | |
| query_1 | STRING | width | 支持key1.key2[0].key3[2]这种查询语法 |
| query_2 | STRING | height | 支持key1.key2[0].key3[2]这种查询语法 |
| query_3 | STRING | png_text.parameters | 支持key1.key2[0].key3[2]这种查询语法 |
| query_4 | STRING | 支持key1.key2[0].key3[2]这种查询语法 |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| value_1 | STRING | — |
| value_2 | STRING | — |
| value_3 | STRING | — |
| value_4 | STRING | — |