Image transfer latency is impacting usability in some networks.

[SinaYa]

I am using ComfyUI with a remote server and while image generation on remote servers finishes in less than a second, transferring images between the server and client takes a significant amount of time (e.g. around 7 seconds).

Here's what I propose as an improvement:

1. Image Compression: Implementing configurable compression levels for image uploads and downloads, allowing users to adjust based on their internet speed.
2. Asynchronous High-Quality Download: Downloading the high-quality generated image in the background while the input is not changing, eliminating the need for an additional download when adding the image as a layer.
3. Client-side Generation/Preview Cache Based on Canvas Hash: Storing the hash of the images provided to the server along with the response from the server on the client-side, thus avoiding redundant generation of the same image.

If I was a developer, I would love to contribute to the codebase, but as a product designer, I wish to contribute with my product UX background.

[Acly]

In version 1.16.0 I changed compression slightly, the uploads use compressed formats (they are more likely a bottleneck, and they go through VAE encode/decode anyway which is lossy). Results are lossless.

The redundant request in Live mode should also be gone now. Nothing will be sent to the server as long as the image or other inputs don't change.

Asynchronous high quality download is not a bad idea, but quite a lot of effort to implement. There are probably other optimizations to explore first.

significant amount of time (e.g. around 7 seconds).

What was the resolution for those 7 seconds?

[SinaYa]

What was the resolution for those 7 seconds?

It was 1024x1024 with a 4-6 megabits internet - around 700kbps (The highest internet speed in my country).

[SinaYa]

The redundant request in Live mode should also be gone now. Nothing will be sent to the server as long as the image or other inputs don't change.

Regarding this, my suggestion about redundant generations was actually about something different than the Live mode.

It's a feature meant to improve the experience of users when they undo a change (or change it back without using Undo) to a state that previously had an image generated for it. This can be achieved if the generated image is cached and associated with the hash of a loss-less capture of the canvas locally so that next time the user undoes something or changes something to how it was before by other means (e.g. by a change that isn't registered in the undo history), and the hash of the canvas is again the same as one associated with a cached image, that cached image is used and the upload/download/computation for a new generation is avoided.

[SinaYa]

Asynchronous high quality download is not a bad idea, but quite a lot of effort to implement. There are probably other optimizations to explore first.

The idea for the asynchronous download is that all previews are also downloaded in a compressed format, and only the generation that the user adds to their layers is high quality (downloaded in the background).

Ideally this would mean:

1. A high-quality version of the generation starts to download right after its preview is downloaded
2. Only if the users try to add the generation to the layers before the download in the background is completed will they be informed of the download progress or told to wait.
3. The download of the high-quality image is also interrupted as soon as another image needs to be generated (i.e. as soon as the system knows it won't be added to the layers).
4. Optionally, if caching is implemented, the "interruption" mentioned above can also have a condition to apply only if less than 70% of the image is downloaded, so that it can be downloaded and cached.

This feature would supercharge the iteration speed for users with slower internet (70% of the world), but I understand there are different priorities.

Thanks for the other changes!