[FEATURE REQUEST] prompt history

[aetherwu]

Is your feature request related to a problem? Please describe.

• When the page is refreshed by intention or accientally, all prompt gone.

Describe the solution you'd like

• Prevent tab close event when there is prompt existing in input.
• Show warning modal to user
• Save used & current prompt in local storage

Describe alternatives you've considered

• A history list (including prompt/param) could be helpfull to find previous used prompts.

[hlky]

I think this should be possible, another feature uses javascript afaik, will look into it

Input from anyone else is welcomed

[sedetweiler]

I just posted a request for a log file. Perhaps this is a solution to this issue as well if there was a simple interface to see past prompts and to be able to quickly re-launch those prompts with or without a seed.

[jansteffen]

From what I've seen it's possible to add Javascript code to gradio events such as .click(), but I don't know if it's possible to add javascript code triggered by onDocumentReady to load the existing history on page load. But then again maybe that could be "prepared" on the python side.

Also, if we want to add a history to the UI, we should probably first figure out what exactly we want to store and present in there. Is it just a vertical list of Images with Text next to them that containing the prompt, seed and settings? How does the history handle batches of images? Should the history contain the grid, or each picture individually?
And how would the history be stored, as a simple txt file, or maybe JSON would be easier to work with?

[nahojjjen]

From a workflow-perspective I think it'd make sense to have a whole new tab next to GFPGAN, RealESRGAN dedicated to viewing your generation history. Currently we need an external program (file explorer) open frequently when generating images.

[ZeroCool940711]

@nahojjjen a gallery style browser for previous runs would definitely be a nice thing to have, browsing from folder to folder and opening images externally eats a lot of time when dealing with lots of images or lots of generations over time.

[codedealer]

If we're talking about local storage in the browser at this point it should just store the entire app state: prompt and all the other settings that go with it. Then you can call up the history stack and basically go back to each previous iteration with gradio ui synchronizing the app state at that point (setting sliders, filling out prompt forms).

In regards to storing images in there I am currently against it. First of all the local storage space is limited and was not designed to store large data (like png files) but storing app state (basically a set of input values) is fine. Secondly, this is doubling the behavior of a system folder which only wastes memory needlessly (the original images are already on the hard drive).

[nahojjjen]

@codedealer My suggestion was purely from a UX perspective, I'm not familiar with the limitations of gradio. I was not suggesting we create extra copies of the generated images, I was suggesting creating a file viewer optimized for generated images currently stored in the output folder. Is it not possible to access the files in the existing output folder? Does gradio /some other technical limitation require we use browser storage?

[hlky]

@codedealer could images be displayed from the files using html img tags? the script will know the filename/directory

[codedealer]

@codedealer could images be displayed from the files using html img tags? the script will know the filename/directory

That is certainly the most apparent idea: store the file url of an image in local storage, then on restoration event just read it from the disk. Why I didn't offer this solution immediately is File System Access API is currently not supported in Firefox but is covered pretty well otherwise.

It is certainly something worth exploring because this will allow for app state traversal not only for text2img but for img2img as well (assuming of course the files are still present on the disk). I intend to experiment with it and possibly polyfill for Firefox later.

Edit: I should add that I approach this from client-side js perspective, maybe it is easily solvable with gradio on the python side, I'll check into that too.

[jansteffen]

I believe it should be possible with python as well, assuming we use a file on the disk for storing all the info and references to the images. You can add a gradio.HTML element and change its content through gradio events, it simply takes a string as an argument. That string containing all the html elements can be constructed by a python function that reads the local file on page load, and when a new image is generated it can just write its location into the storage file and update the HTML again

[jansteffen]

Actually thinking about this just now, using a file for storing all the info would only be a sensible idea when using this locally on your own PC, but since there are some public colabs that use this repo using a file stored in the execution location would mean people would see the history of other users too.

[codedealer]

Yes, it is important to keep the mindset of a web app which it is rather than a desktop app which it feels like. Even without considering colabs and public facing frontends by default gradio is accessible within the local network.
I think the discussion veered off track a bit with prompt history vs built-in file browser to view previously generated images in the gradio tab.

A comprehensive persistent app state in this case is not possible without storing everything on the machine that runs gradio server simply because img2img needs an image as input and that one is on the "server" machine. Yes, that means exposing public facing gradio apps to history but I'd say it is a given anyway. Instead maybe you can just disable history when share=True in the launch method.

More interesting idea that captures me is restoring state from the generated image. There is already an option to store (some?) data in the png_info. If you can drop that image into a gradio app and basically restore the state where you're left off that would be neat I think.

P.S. I know there are also yaml files but those require another interface to drop and parse them and they are dependent on the image they were generated along with. Why bother when you can pack all the necessary state inside an image?

[altryne]

There are some features that would require an external account.
For syncing, for saving prompts (and maybe images)
@hlky let's chat about how best to keep balance between the ever growing list of amazing requests!

[altryne]

The idea of getting the embedded png data and seeing if there are parameters there is a cool one! Could confusing for a few images but worth a shot

[codedealer]

@altryne the loading parameters from png data should of course be optional and turned off by default. Yet it is a very elegant way of saving and resuming and sharing your progress.

[sedetweiler]

Yes, it is important to keep the mindset of a web app which it is rather than a desktop app which it feels like. Even without considering colabs and public facing frontends by default gradio is accessible within the local network. I think the discussion veered off track a bit with prompt history vs built-in file browser to view previously generated images in the gradio tab.

A comprehensive persistent app state in this case is not possible without storing everything on the machine that runs gradio server simply because img2img needs an image as input and that one is on the "server" machine. Yes, that means exposing public facing gradio apps to history but I'd say it is a given anyway. Instead maybe you can just disable history when share=True in the launch method.

More interesting idea that captures me is restoring state from the generated image. There is already an option to store (some?) data in the png_info. If you can drop that image into a gradio app and basically restore the state where you're left off that would be neat I think.

P.S. I know there are also yaml files but those require another interface to drop and parse them and they are dependent on the image they were generated along with. Why bother when you can pack all the necessary state inside an image?

If we can store that data in the IPTC metadata, then it also opens up the result to use in other apps.

[devilismyfriend]

@hlky @altryne here's a try at this
The buttons get generated dynamically on startup, passed as a list, each is also getting a click event to just send the value into the prompt box along with a button to hide the entire thing when not in use, should be easy enough to implement after taking care of the backend saving of prompts and passing them into the UI startup, I guess it could even utilize dynamic parameters to set other variables? don't know

Edit:
So I ran into an issue with this approach which is that I can't update the buttons dynamically after running a generation, seems like once it's loaded at startup you can't change the buttons all willy nilly.