You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the process of making #2473 I generated a lot images in img2img, then using one of them each time, sending it to img2img again directly from GUI.
Then I have all generations with their parameters saved in folders, but no indication of what exact images did I use!
An option to always store a copy of input image will solve this. Even if it won't contain previous generation metadata, but the very image will be good enough. (Combining this with metadata can be left to future improvements).
You can argue that it will take x2 storage space, but firstly: it's an option, and user may enable or disable it at will; and secondly, you can implement an optimization which stores the input image only once per invocation – for example in "img2img-grids" subfolder, where the final result it stored only once even for batches/grids.
I think a good solution would be to just store a hash (sha1?) of the original image. This way it doesn't blow up in size that much and you could (if you still have all images) later even build a history chain of all images that lead to the result.
But image can be pasted directly to img2img from clipboard, not from a file. Also for inpaint the mask must be stored too, honestly.
While I can agree that when images from txt2img are used in img2img and if we don't delete anything – then yes, a hash is technically enough. Putting aside the database for storing those hashes (once the Hydrus was proposed: #2087, probably it indeed can be used for this task).
In the process of making #2473 I generated a lot images in img2img, then using one of them each time, sending it to img2img again directly from GUI.
Then I have all generations with their parameters saved in folders, but no indication of what exact images did I use!
An option to always store a copy of input image will solve this. Even if it won't contain previous generation metadata, but the very image will be good enough. (Combining this with metadata can be left to future improvements).
You can argue that it will take x2 storage space, but firstly: it's an option, and user may enable or disable it at will; and secondly, you can implement an optimization which stores the input image only once per invocation – for example in "img2img-grids" subfolder, where the final result it stored only once even for batches/grids.
Related issues that effectively asked for this:
#2335
#2333
#2140
#1784
#1315
The text was updated successfully, but these errors were encountered: