invoke-ai
defer patchmatch loading
Because of the way that patchmatch was loaded early at import time, it was impossible to turn off the attempted loading with --no-patchmatch.
In addition, the patchmatch loading messages appear early on during initialization, interfering with ability to print out the version cleanly when --version provided to invoke script.
This commit creates a thin wrapper class for patch_match that is only loaded when needed, solving both problems.
I'm not sure I fully understand what problem this is solving. Is the web API just pulling in patchmatch through the config gathering before the options have been processed? If so, wouldn't the solution be to re-order that code?
Patchmatch being available or not seems like a system-level/singleton/static thing, not something a class should be instantiated to check. I also don't think it makes sense to have infill instances on the inpaint class, since the infill is more of a singleton.
I'm not sure I fully understand what problem this is solving. Is the web API just pulling in patchmatch through the config gathering before the options have been processed? If so, wouldn't the solution be to re-order that code?
This is solving two minor problems. First, there are runtime switches for turning off loading of PyPatchmatch, GFPGAN, ESRGAN and CodeFormer, but the PyPatchmatch switch wasn't doing anything because the patchmatch code is loaded before the switches are processed. The second problem is that I finally got around to adding a --version switch to invoke.py, but because of the order in which PyPatchmatch loads, it prints out its initialization message before the version number is printed, which will interfere with scripts that interrogate InvokeAI's version number.
Patchmatch being available or not seems like a system-level/singleton/static thing, not something a class should be instantiated to check. I also don't think it makes sense to have infill instances on the inpaint class, since the infill is more of a singleton.
I can make the Patchmatch wrapper into a singleton. The current code will just be moved into its own little module. Is this what you're suggesting?
I did want to split out patchmatch and tile into either an infill module or their own infill modules anyway, so that would probably be fine.
@Kyle0654 I've addressed your second round of issues, but my development machine is currently offline and so I haven't tested to be 100% sure. You may go ahead with another review if you wish, but please don't merge until I've had a chance to test.
@Kyle0654 When you have a chance, this version should be good. I can't believe how much time I've spent making revisions to this "simple fix!"