Reading the metadata, keeping the record

The parameters are in the file

Most local generation tools write the full set of parameters into the PNG itself, in a text chunk that survives copying and uploading to some services. Open a generated PNG in a text editor and you will often find something like:

a studio portrait of a woman wearing a red scarf
Negative prompt: watermark, text
Steps: 28, Sampler: DPM++ 2M Karras, CFG scale: 6,
Seed: 3819475210, Size: 1024x1024,
Model hash: 31e35c80fc, Model: sd_xl_base_1.0

That block is a complete recipe. With the same model file, it reproduces the image. Free tools read it for you: most WebUIs have a "send to" button that repopulates every field from a dropped image, and ComfyUI embeds the entire node graph, so dragging a PNG onto the canvas rebuilds the workflow that made it.

This is the single most useful habit in this module. When something works, you have the record already. You just have to not destroy it.

How the record gets destroyed

• Saving as JPEG. The text chunk is a PNG feature. Export to JPEG and it is gone.
• Uploading to most social platforms. They strip metadata on upload, partly for privacy, partly to reduce file size.
• Editing in an image editor and re-saving. Some preserve unknown chunks, many do not.
• Screenshotting. Obviously, but people do it.

So keep the original PNG. Treat exported versions as disposable and the generation output as the master, exactly as a photographer keeps the raw file.

What metadata does not prove

There is a temptation to treat the presence or absence of this metadata as evidence about whether an image is generated. It is not, in either direction.

Absence proves nothing: any conversion, upload or crop removes it, and the vast majority of generated images circulating online have none.

Presence proves very little: the chunk is plain text that anyone can write into any file. Adding a fake generation record to a photograph takes one command. It is not signed, not verified and not tamper-evident.

Provenance that resists tampering requires cryptographic signatures, which is a different system entirely and gets its own module later in the course. The generation metadata is a working convenience for you, not evidence for anybody else.

Keeping a record that survives you

For anything that matters — client work, anything published, anything you might have to explain — the parameters in the file are not enough on their own. Keep a short note alongside the deliverable with:

• Which model, at which version or hash. "Stable Diffusion" is not an answer; checkpoints differ enormously and are frequently updated in place.
• The prompt and seed, so the result can be regenerated.
• Every reference image used, with its source and licence.
• What you did afterwards by hand — the retouching, the compositing, the type.
• Whether the output was disclosed as AI-assisted, and where.

This takes two minutes per job and it answers, without argument, the questions that come up months later: was this generated, what went into it, can we make another one that matches, and can we prove what we did.

The version problem, stated plainly

There is a limitation here that no amount of discipline fixes. Hosted models change under you. A service can update its model with no version number and no announcement, and your recorded prompt and seed will then produce a different image. Nothing in your record is wrong; the machine it referred to no longer exists.

This is the strongest practical argument for keeping local copies of any model your work depends on. A 6-gigabyte checkpoint file on a disk is a version that cannot be revised without your consent, and open-weight models can be archived exactly like fonts or software. If a series of images has to match across two years, this is not a preference. It is the only way it works.

Two small habits make the rest of it painless. Name files so the record is in the name — campaign_hero_seed3819475210_v3.png tells you more at a glance than any folder structure. And keep the failures, at least for the duration of a project. The rejected variants are the evidence of what you tried, they are frequently the answer when a client changes their mind back, and on a job that later gets questioned they show a process rather than a single lucky output. Disk is cheap; regenerating an image whose model has since been updated is not possible at any price.