Acly / krita-ai-diffusion

Streamlined interface for generating images with AI in Krita. Inpaint and outpaint with optional text prompt, no tweaking required.
https://www.interstice.cloud
GNU General Public License v3.0
6.7k stars 328 forks source link

Upscale issue #3: can’t upscale images beyond 8K-10k size #1265

Open valery016 opened 1 week ago

valery016 commented 1 week ago

Issue #3 (an old one too) : can’t upscale images beyond 8K-10k size

Upscaling beyond 8-10K sizes with the Krita AI plugin seems unattainable: when 2x upscaling a file of that size, Krita will be fine with taking it to 16K, but the plugin always returns a failure in red, see below.

upscale screenshot 2 (issue #3)

Is this a ComfyUI problem? I have quite a capable PC with RTX 4070 Ti Super card (16 GB) and when using Forge, I routinely process images of up to 64K size, upscaling from 8K or 10K resolution never posed a problem. What is also strange, I can easily load a 32K image into Krita and inpaint or generate with the plugin various (not too large) selections in it, no problem whatsoever.

megagrump commented 1 week ago

Try starting ComfyUI with --max-upload-size 200 or more to override the default limit of 100 (megabytes).

valery016 commented 1 week ago

Thanks megagrump, I didn't know about this switch. Setting it to some very large value and restarting Comfy didn't change much though: when attempting to 2x upscale a 7200x9600 image, I get a somewhat different failure message in red:

upscale screenshot 3 (issue #3)

(while Krita upscales the image to the target size with no issues whatsoever. Note also the bizarre target size indicator).

The original message, however, concerned Krita AI-managed server, not an external one. In that case, this parameter is controlled, I understand, by the Maximum Pixel Count setting in Performance. I set it to 99 MP, the maximum allowed value, but the plugin still returns the same failure in red letters when 2x upscaling that image. In any case, the plugin's 100 MP limit translates to a picture of roughly 12Kx8K dimensions, which is nowadays nothing unusual (especially for AI-assisted image processing), I don't understand why such restriction in the first place.

valery016 commented 1 week ago

UPDATE. I receive the message “Error Failed to read JSON 'Maximum request body size 104857600 exceeded, actual body size 104861476' with message: Unexpected character encountered while parsing value: M. Path '', line 0, position 0.” in SwarmUI when trying to refine a 6144x8192 image, both in non-tiled and HyperTiled Refine/Upscale mode. In general, processing of files starting from 6-8K resolution seems impossible in SwarmUI. This problem may or may be of the same nature as the failure to upscale or refine high resolution files with the Krita AI plugin. If the underlying motivation for this 104857600 restriction is the Comfy’s reliance on the ancient ImageBase64 encoding in the JSON workflow file (which makes them swell beyond reason), then it’s not a very clever part of its methodology and needs to be upgraded a.s.a.p.

Acly commented 1 week ago

that's probably the reason, there was no such limit in the past I think (or I never hit 100mb png dispite using larger resolutions, it depends on the content too)

also, it was me who introduced base64 transfer, it's convenient

megagrump commented 1 week ago

it's convenient

It also reduces the maximum image transfer size by 33% with the current implementation. The mere existence of such a cap in an upscale workflow is unfortunate. The inefficient encoding exacerbates the issue on top of the (arbitrary?) limit, and slows down the entire process, especially when working remotely over a network.

Acly commented 1 week ago

Yea it was made for local prompts without a maximum request limit. The content type must be JSON, base64 is pretty much the only option to embed images directly.

ComfyUI's "native" way of doing it is separate upload requests that write to the filesystem, I don't particularly like it because files need to be cleaned up and have a host of issues.

Cloud client already uses separate uploads/downloads, so it's not difficult from plugin side, but might need a custom node.