Compact infotext system, Compact soft inpainting infotext

[w-e-w]

Description

in some cases the infotext amount is getting a bit out of hand
particularly in the cases where an extension has multiple parameters that needs to be individually entered into Intel text
as infotext key name is required to be unique across all webui the common practice in this case for extension is to add a prefix or suffix to the key name

but this has the issue of making the infotext excessively long

• one example of this is Soft Inpainting #14208
  when using this built-in extension you will get an infotext like this

1girl
Steps: 20, Sampler: DPM++ 2M Karras, CFG scale: 7, Seed: 1282321148, Size: 528x528, Model hash: 54ef3e3610, Model: meinamix_meinaV11, VAE hash: 235745af8d, VAE: vae-ft-mse-840000-ema-pruned.ckpt, Denoising strength: 0.75, Soft inpainting enabled: True, Soft inpainting schedule bias: 1, Soft inpainting preservation strength: 0.5, Soft inpainting transition contrast boost: 4, Soft inpainting mask influence: 0, Soft inpainting difference threshold: 0.5, Soft inpainting difference contrast: 2, Mask blur: 4, Version: v1.7.0-384-g8a6a4ad8

to solve this issue I implemented a method that I named info_json
basically it goes back to the idea of using structural data, and as the name suggests json
the basic idea is that if all these information can be encoded as a dictionary within "One infotax entry"
this will remove the need of using multiple long prefixes and enable the possibility of using acronyms as sub keys in the dictory
the data structure will will have to be encoded befor combineing into infotext and decode back to data structure on parse

there's one problem with using Json string directly in info text, due to how infotax is encoded the double quotes in json string will have to be escaped, this will cause extra clutter in the info text defeating the purpose compacting intotext
to solve this issue double quotes in single quotes are swap

implementation and demonstration this system with Soft Inpainting

to utilize this system an only have to register a infotext key as a info_json_key by using
infotext_utils.register_info_json('Soft Inpainting')
after this when writing p.extra_generation_params the extension can directly write a a list or dict in to infotext p.extra_generation_params
the system will automatically encode the infotext to info_json and decode it in parse_generation_parameters

in the implementation of this PR I've compacted the Soft Inpainting infotext to this

1girl
Steps: 20, Sampler: DPM++ 2M Karras, CFG scale: 7, Seed: 1282321148, Size: 528x528, Model hash: 54ef3e3610, Model: meinamix_meinaV11, VAE hash: 235745af8d, VAE: vae-ft-mse-840000-ema-pruned.ckpt, Denoising strength: 0.75, Soft Inpainting: "{'sb':1,'ps':0.5,'tcb':4,'mi':0,'dt':0.5,'dc':2}", Mask blur: 4, Version: v1.7.0-387-g28cc18cb

• Soft inpainting enabled is is signified by the existence of `Soft Inpainting: "{...}"
• Schedule bias -> sb
• Preservation strength -> ps
• Transition contrast boost -> tcb
• Mask influence -> mi
• Difference threshold -> dt
• Difference contrast -> dc

while using acronyms does reduce readability of the infotext, but in general people won't be reading this in a text manually, and when they do even with the full name they still have to have knowledge about webUI elements so I think using acronyms is acceptable

• Backwards compatibility with the old infotext IS implemented

note: I've also remove space after comma and colon in json string maybe this is a bit overkill this can be reverted or made as an option?

---

this system is actually relatively easily achievable in extensions without implementing it in web UI
I have been using this in multiple extensions
the only difference is that, I have to perform the encoding myself and then add an additional decoding step to on_infotext_pasted callback,
but if this system is implemented directly into web UI it would be more easy for future extensions to adapt to the new system
example

Screenshots/videos:

current infotext

compacted with info_json

as you can see lots of space is saved

---

other changes

consolidated the concatenating of infotext in modules.processing and modules.postprocessing to infotext_utils.build_infotext(dict)

---

if this PR is accepted I would like to also perform the same procedure to some other infotext
like

• Add inpaint arguments in .txt file #14497

Checklist:

• I have read contributing wiki page
• I have performed a self-review of my own code
• My code follows the style guidelines
• My code passes tests

[w-e-w]

cc @CodeHatchling

[AUTOMATIC1111]

I personally like the verbose style...

[w-e-w]

I personally like the verbose style...

it doesn't have to be acronyms
it can still use full names but without the prefix

Soft Inpainting: "{'schedule bias':1,'preservation strength':0.5,'transition contrast boost':4,'mask influence':0,'difference threshold':0.5,'difference contrast':2}"

I'm just using this to illustrate this potential

Soft Inpainting: "{'sb':1,'ps':0.5,'tcb':4,'mi':0,'dt':0.5,'dc':2}"

I will argue grouping everything that's related to this extension into one object is more clearer readable
then the curent

Soft inpainting enabled: True, Soft inpainting schedule bias: 1, Soft inpainting preservation strength: 0.5, Soft inpainting transition contrast boost: 4, Soft inpainting mask influence: 0, Soft inpainting difference threshold: 0.5, Soft inpainting difference contrast: 2, 

[akx]

Copying my comment from the Discord:

By the way, why don't we store machine-readable JSON infotext in addition to the human-readable one? Slap e.g. a Record Separator (\x1E) between the two, so it's

Prompt: blah blah, Sampler: whatever, ...
<1E>
{"prompt": "blah blah", "sampler": "whatever", "x-controlnet-data": {"foo": "bar", ...}

so machines (and extensions that care about infodata) can parse JSON and humans can read the text? Feels weird if this hasn't been suggested yet.

[w-e-w]

I don't see the point of writing the information twice

[simonmcnair]

I would deeply like infotext to be json, and so expandable and standardised. I did a quick look in discussion but couldn't see if this had been suggested or not ? Any reason not to ? I'm pretty sure comfy ui already does it. Would also, possibly be a nice way to ensure that no extensions could break the prompt as you could make all extensions follow a standard or just give an extension it's own blob ? That might make it so that png to prompt might be easier to populate extension boxes too ?
Just throwing the idea out there.

[light-and-ray]

≥ note: I've also remove space after comma and colon

You also can remove quotes ' and save extra 12 characters 🤪

[w-e-w]

≥ note: I've also remove space after comma and colon

• I know and I even considered it before swap quotes instead of replace scraed/CharacteristicGuidanceWebUI#2

You also can remove quotes ' and save extra 12 characters 🤪

no not really
this is supposed to be a general system that we work with all cases including times that you would need to escape stuff
which means quotes are necessary

[light-and-ray]

You can check if it contains anything except letters and add quotation if yes

[CoryG89]

I would deeply like infotext to be json

I have to comment here to second this notion. I personally think it would be really beneficial for the entire infotext to be encoded as JSON. I often find myself writing scripts that parse the infotext and currently my method is to shoehorn the current format into valid YAML, then convert YAML -> JSON at which point I can use the JSON easily anywhere. I haven't had much issue doing this so far, but it's extremely brittle and every extension that I install has the potential to break my parsing logic at any time.

[simonmcnair]

It could be made opt in, it could be named parametersjson and live side by side. I suspect that parameters will require more troubleshooting and maintenance than parametersjson. The main thing is that a1111 can write json to the file and can read it.