[FEATURE REQUEST] Write generation parameters as image EXIF

[ndemar]

An option to add generation data into files as EXIF data. This would help when sorting and searching large sets of images using standard tools that operate on EXIF.

[sowbug]

Hi there, I added a feature like this over on https://github.com/basujindal/stable-diffusion (PR submitted). It writes most of the command-line parameters to the generated picture files:

Since the @basujindal fork also optionally outputs JPEGs, the PR handles both file types. Note that it uses XMP, rather than EXIF, but I suspect the tools you're describing can handle that format as well.

I couldn't figure out whether this fork does anything like this already, but as you can see, the PR is fairly simple, so you're welcome to adapt it to this fork.

[EliEron]

We have some metadata support but it only supports PNG files and its off by default. And it does not list everything, only what is considered important. Though even there it's a bit lacking. I just opened a PR to add the sampler name as that is not currently saved, which feels like an oversight.

We use custom PNG chunks to store the data. The advantage of that is that it did not require any additional dependencies as PIL supports reading and writing PNG chunks, which is sadly not the case with Exif or XMP. It's also pretty simple and readable code wise.

I have actually looked into making an Exif version that would work with JPEG files but finding a clean solution proved a challenge. There are no big maintained Exif writing libraries for Python that I could find which is a pain as adding an unmaintained dependency to the project for a feature most don't use isn't great.

Also personally I don't really like stuffing all of the values into one field, having them as actual custom fields feels a lot cleaner. Which is what the current PNG chunks implementation does.

The PR that implemented metadata support is here #78. And to enable it you have to pass "--save-metadata" when starting the UI, either by passing it directly to webui.py or by modifying relauncher.py if that is what you use.

[DasWookie]

I have actually looked into making an Exif version that would work with JPEG files but finding a clean solution proved a challenge. There are no big maintained Exif writing libraries for Python that I could find which is a pain as adding an unmaintained dependency to the project for a feature most don't use isn't great.

Either the exif or PIL.ExifTags are likely the best candidates. While I agree with you almost to the letter, ultimately to do this with JPG files, there isn't any other solution as the spec for EXIF data is long set. There are some excellent candidates for sluffing the info into, like 0x927c Maker Note, 0x9286 UserComment, and 0x9c9e XPKeywords, for a start. There are a lot of other tags we should be able to get a mapping to MOST of the rest of the parameters. Worst case, the tag could just have the name of the parameter and the value stuck into it. It's ugly, but there isn't a terrific solution when custom tags aren't supported... an oversight of the spec to be sure... but that ship sailed a LOOOOOOONG time ago. So, we just have to make due with what's available. The perfect solution doesn't exist within the spec.

Also personally I don't really like stuffing all of the values into one field, having them as actual custom fields feels a lot cleaner. Which is what the current PNG chunks implementation does.

I agree, but that's not possible with JPG and EXIF. Short of going outside of the JPG spec, there isn't any other solution that either:

1. Slam everything into one field
2. Find the best mapping of parameters to EXIF tags and repurpose the tag to our needs for embedding the information. Using tags this way would at least allow for the saving of the information, and once a mapping was settled on, tools could load the values from those fields. While I don't like the idea of doing something like shoving the parameter name and value into the various string fields, it would at least save the info. Allowing a configurable mapping would be nice, but I'd be just as OK with having the mapping be hard coded in and if you wanted to change if you'd be responsible for making all of the various connections.

[sowbug]

These approaches are not mutually exclusive, and they satisfy overlapping but different goals.

A thoughtful, properly structured solution requires only a single parser on the client side. It feels architecturally stronger. But the tools will have to catch up, both on the creation side and on the rendering side.

The quick-and-dirty approach of stuffing everything into a well-known field such as XMP Description means that users can typically right-click a file and see the information in their OS's file explorer, and many online photo sites such as Google Photos and Flickr already index the metadata and display it in the UI:

I'm personally enjoying the fact that Google Photos indexes the keywords in the XMP Description field, which makes it a cinch to find all my images generated from a specific prompt word or parameter.

[EliEron]

Either the exif or PIL.ExifTags are likely the best candidates.

Does PIL.ExifTags support writing Exif tags? In my research I got the impression it only supported reading. The two libraries I primarily looked at was exif and Piexif. Neither of them seem to be maintained anymore.

While I agree with you almost to the letter, ultimately to do this with JPG files, there isn't any other solution as the spec for EXIF data is long set.

Yeah I did come to that conclusion myself, which is partly why I said I was unable to find a clean solution. Though I have to say I was honestly surprised to find that Exif had no support for custom tags. A surprisingly shortsighted decision given that it should have been obvious that cameras and other applications would need other metadata in the future.

There are some excellent candidates for sluffing the info into, like 0x927c Maker Note, 0x9286 UserComment, and 0x9c9e XPKeywords, for a start.

Yeah MakerNote and UserComment was the tags I looked into, I did not come across XPKeywords in my research.

The issue with MakerNote is that it is designed to store data in whatever binary format the maker wants. Which means that Exif parses can't decode them unless its a known format that have already been programmed into the parser. So if we used that it wouldn't actually be displayed by most Exif parsers out there at least in the short term, which would be a big disadvantage as far as I'm concerned.

UserComment is more promising since it's pure text, and it's what I used in a quick hacky POC that I threw together. And it did work fine, though I wasn't super happy with it since I did of course have to stuff all of the properties together in there.

Repurposing other tags isn't something I though about, but to be honest I'm not sure I like that any more than just stuffing the tags into one field. Especially if the mapping is configurable, as I definitively prefer thing to be as standardized as possible. Having endless permutations feels like a bad idea.

As for @sowbug's comment, I agree that there is value in making these tags work with existing tools. And ultimately the best way to achieve that is probably just to stuff things into one tag, despite my dislike of it. But I'm not sure how the other devs will feel about supporting two different metadata systems (PNG Chunks and Exif (or XMP)) especially since the existing metadata system already breaks quite often due to most devs not using and testing it.

[Oros42]

Have write a lite POC who use pyexiv2.
Setup : pip install pyexiv2

import pyexiv2
img = pyexiv2.Image('00000-50_k_lms_305139102_0.00.png')
print(img.read_xmp())
img.modify_xmp({'Xmp.xmp.CreatorTool': 'Stable Diffusion'})

infos = {
	'batch_size': '1',
	'cfg_scale': '7.5',
	'ddim_eta': '0',
	'ddim_steps': '50',
	'height': '512',
	'n_iter': '1',
	'prompt': 'A fantasy landscape, trending on artstation',
	'sampler_name': 'k_lms',
	'seed': '305139102',
	'target': 'txt2img',
	'toggles': '1;2;3;4;5',
	'width': '512'
}
img.modify_xmp({'Xmp.dc.description': infos['prompt']})

pyexiv2.registerNs('Stable Diffusion info', 'SDi') # SDi is a suggestion but can be change
for k in infos:
	img.modify_xmp({f'Xmp.SDi.{k}': infos[k]})

img.close()

[sowbug]

Note that pyexiv2 has two different implementations: the version by @LeoHsiao1 here, and the version here that calls itself py3exiv2 but also claims the Python module name pyexiv2. The former includes precompiled binaries, which for my personal security posture is a no-no, and the latter introduces a dependency on the exiv2 library, which made it more complicated for end users to install. python-xmp-toolkit also has the problem of native dependencies. That's why my PR uses a pure Python solution.

[Oros42]

aaah ... okay :-/