Add resolution for Arch.anima in resolution.py

[Sen-sou]

Added missing Anima preferred resolution.

[Acly]

Not convinced this is actually needed or an improvement. Regardless of what the model claims are ideal resolutions, the mechnism in the plugin has clear goals:

• Lower bound: avoid issues where image is broken below certain resolution. Try 256x256 resolution with SD1.5 or SDXL and it will just produce complete garbage. This is obviously always bad, so internal upscale is legitimate. But in all other cases the priority is to use the resolution the user is working at -- ie. the canvas resolution. Resolution is a speed/quality trade off, and the user's preference should be honored if at all possible. So saying "but 512 looks better than 256" is not an argument, of course higher resolution looks better, it always does, if the user wanted that they can use a bigger canvas.
• Upper bound: avoid "repetition" and "elongation" artifacts, common in SD1.5/SDXL models. To avoid this issue the plugin will use a pre-pass at low resolution, and a follow-up img2img/refine at the desired resolution. This is effective at fixing those issues. Anime does have issues at resolutions 2k+, but unfortunately I don't think 2-pass fixes it. The second pass still happens at the full resolution and introduces grid/noise artifacts. Since the upper bound's only purpose is to trigger 2-pass gen, if that doesn't actually help, there is no reason to do it.

IME Anima works fine at resolutions lower than 512, and its issues with higher resolutions can't be fixed with this code change (it needs tiling, which is only implemented in the upscale path).

[Sen-sou]

Thanks for explaining in detail. That indeed makes sense, but i was approaching this with keeping those refine passes within the Anima's preferred resolution, and though lower resolutions (<512) doesn't break as bad as sdxl or sd1.5, it causes degradation in quality or little to no quality improvement at all. Since the purpose of refine is to improve the result, rather than honoring the canvas resolution, i think keeping the Anima lower bound to 512 is beneficial.
That said i agree with your point regarding the upper bound, lowering would be just useless refines.

[Acly]

Since the purpose of refine is to improve the result, rather than honoring the canvas resolution

No that is not the purpose. If you want higher resolution, increase resolution. There is no reason refine should do that on its own behind the curtain. It's a strictly worse way to do it, because results of refine have to be downscaled to fit into the canvas, and the next refine picks up the low-res result. If you increase canvas resolution, results are better.

[Sen-sou]

Since the purpose of refine is to improve the result, rather than honoring the canvas resolution

No that is not the purpose. If you want higher resolution, increase resolution. There is no reason refine should do that on its own behind the curtain. It's a strictly worse way to do it, because results of refine have to be downscaled to fit into the canvas, and the next refine picks up the low-res result. If you increase canvas resolution, results are better.

That was my fault for not being clear. For refining the whole image, its always better to increase your canvas resolution to get better results. What i was referring to specifically is refining a selection. I would expect to get more quality/detailed result if i refine a selection area, but currently its not (i have seen other users report the same). For example, if i have a 1M canvas, and i select a small area, say a face of around 300px, and i refine it, i don't get improved result at all, because the lower bound is set to 256 px, where it will not upscale the image to do a refine pass. So by increasing the lower bound to 512px, we can get better results.
But as you said this can also be done by increasing the canvas resolution, doing the selection refine, and then downscaling the canvas. But it defeats the convenience of selection refinement, where the purpose is to improve the small area without rescaling the entire image.

So do you think it justifies the lower bound for selection, or can it be handled in some other way?

P.S. Can you check the PR for the tooling node?

[Acly]

It was not unclear. Yes A1111 folks are regularly confused about this, there's some unlearning to do and they hate that?

In selection case we can

1. don't increase canvas resolution, use actual resolution for diffuse -> bad quality
2. don't increase canvas resolution, use higher resolution for diffuse and downscale -> good quality but we throw some of it away when downscaling
3. increase canvas resolution, use actual resolution for diffuse -> good quality and we keep it

I don't want to implement 2. because people should use 3.

[Sen-sou]

It was not unclear. Yes A1111 folks are regularly confused about this, there's some unlearning to do and they hate that?

In selection case we can

1. don't increase canvas resolution, use actual resolution for diffuse -> bad quality
2. don't increase canvas resolution, use higher resolution for diffuse and downscale -> good quality but we throw some of it away when downscaling
3. increase canvas resolution, use actual resolution for diffuse -> good quality and we keep it

I don't want to implement 2. because people should use 3.

Fair enough. I understand what you're saying. My goal was mainly to improve small selection refinement, but I can see why you prefer tying the behavior directly to the canvas resolution keeping the control with the user rather than background auto scaling.
Thanks for explaining.