Adding the option to save pnginfo/metadata

[ExoPhantasm]

This adds the ability to add metadata via PIL pnginfo.
This is useful for storing workflow or related data directly into the .png file.

This is mainly in mind for batch operations where you might be using BLIP and you want to then store that information and reuse elsewhere, but it also gives users the option to replicate what popular Stable Diffusion UI's do when creating an image, this then allows you to send the generation parameters from Chainner over to your favourite UI's ready to be parsed, such as the HxW, pos/neg prompts, seed etc.

It should all be working as expected but if you use a non-standard metadata key some online png metadata services might omit it.

[RunDevelopment]

While, I think that it's fine to support saving PNG info, I am not a fan of the current implementation. I think that it makes the Save Image node too complex.

So here is what I would suggest: The Save Image node only gets a single new input called "PNG Info". The "PNG Info" input is an optional input that takes a PIL PNGInfo object. To create those objects, we have a little helper node (fittingly) called "PNG Info". The PNG Info node will have 2 text inputs for key and value.
This design move the complexity of creating a PNGInfo object into its own node, which also allows users to reuse those objects.

If we want to fancy, we can also extend the PNG Info node to take any number of key value pairs.

What do you think?

[ExoPhantasm]

While, I think that it's fine to support saving PNG info, I am not a fan of the current implementation. I think that it makes the Save Image node too complex.

So here is what I would suggest: The Save Image node only gets a single new input called "PNG Info". The "PNG Info" input is an optional input that takes a PIL PNGInfo object. To create those objects, we have a little helper node (fittingly) called "PNG Info". The PNG Info node will have 2 text inputs for key and value. This design move the complexity of creating a PNGInfo object into its own node, which also allows users to reuse those objects.

If we want to fancy, we can also extend the PNG Info node to take any number of key value pairs.

What do you think?

Okay great, that sounds like a clean solution. Originally it did have it as its own node (although not quite the same) but I wasn't sure on the desired balance between overall node count and node complexity, so it's good to know.

I can look into updating this tomorrow as requested. I like the idea of multiple key value pairs and I think I know what is required to meet the above, but I will reach out on Discord if I am missing something.

[joeyballentine]

@ExoPhantasm Did you ever continue working on this? It seems like it would be useful to have