By pointing the specific commit, updating bmquilting repo won't change the comfyui_quilting behavior.
I already found & corrected a bug that changes the nodes behavior in bmquilting dev branch, so this change ensures users can have a stable experience.
Additionally, if I want to make more radical changes in the future, I don't risk breaking all the node versions that rely on the bmquilting repo.
reasoning behind seed removal in SP nodes: the cases where seed changes output are so rare that will just confuse the users and occupy unnecessary space in the workflow.
___________________________________________
Additional developments:
Tried to automate tolerance by analyzing the min error distribution of random samples.
After some "adjustments" to avoid large tolerances, was able to get values within a nice range. However, for some textures, the value deed not seem adequate, despite falling within an acceptable range. Thus, I will not include this implementation for now, but it might be a good idea to save it as a gist for future reference.
* abstract repeated code in get_4way_min_cut_patch.
* with the exception of v0, masks are now 2 dimensional arrays.
* re-use already allocated memory when possible.
________________________________
notes:
* patch_blending_vignette cache is cleared post node execution
* new GenParams cleans up args in function, and allows easier adjustments to args if the need arises.
* v0 uses jena2020, ignoring blend_into_patch option.
!! v0 output seemed bizarre on some tests, might have introduced a bug when refactoring...
________________________________
to think about:
* when generating cut mask, output it as single channel instead. blend_into_patch added redundant operation.
* overlap can be small with respect to the block_size, perhaps it is better to handle individual corners in get_4way_min_cut_patch?
* maybe add seed or generator to GenParams.
* patch_search.py renamed to synthesis_subroutines.py.
* fixed number of channels when using cv.floodFill with latents in new min cut implementation.
* make_seamless.py and make_seamless2.py use same "min_cut_patch" implementation.
* quilting.py allows to use v0 implementation, but otherwise, also shares the same as seamless nodes.
* check optional lib using importlib
____________________________________________
Note:
Technically, opencv could be made optional too, but it would require extra work.
Seamless nodes would either have to be excluded or reworked.
Seems like too much work for some niche applications, not motivated to work on that for now. It would have been easier if I had thought about it apriori, but alas...
For now next planned steps are: to integrate the blend functionality; clean up the code; update the documentation; and update/add workflows.
* blend option not yet added to nodes, might cleanup the code a bit first.
* patch_search.py needs to change name, or maybe be separated into different scripts; TBD.
* get_4way_min_cut_patch: make left block optional; rename resBlock to res_block; experimenting with blur (deactivated for now, must be added to node once finished).
* get_min_cut_patch_mask_horizontal: specified mask's dtype.
__________________________
Additional Notes:
* if no additional bugs are found, the function should be moved to another file so that it can be re-used by all implementations. Even if blur option ends up not being added, it allows for potential future changes to be applied to all operations.
* blur implementation using distance transform seems okay, but sometimes it seems that the patch's edges become noticeable. this shouldn't happen due to additional square vignette mask, either it is something independent of the blur or there is some bug/oversight.
* Reminder: I left blur on seams out of the current solution... is it still worth it? might need some time to revisit the idea and test its usefulness within a workflow context.
_______________________________
DevNote
a thought just occurred to me, of a likely blunder in nice block size.
there should, at the very minimum, be an addressable area of size equal to the lowest "best" multiple; and the bigger the addressable area the more variation allowed. Therefore, instead of aiming for a highest multiple to maximize performance, I should take this into consideration and further limit the maximum possible value, or define some criteria to better balance the decision.
* new node: GuessNiceBlockSize.
* new feature: image quilting nodes get a special block size range that uses guess_nice_block_size; also works with parallel batch but the guess must be done before parallelization in order to setup the total number of steps in pbar.
* fixes: node options using shallow copy fixed; fixed parallelization error when lookup is None; fixed edge case in bse_desc_util.py.
* misc: guess_nice_block_size can be given an alternative upper bound (needed when patching H seam); guess_nice_block_size can run bse_ft only for faster analysis.
* checks sift descriptors sizes.
* checks distances between above mentioned descriptors.
* checks freq. w/ high magnitude in ft.
* selects a size that is close to a multiple of the distances obtained in above listed analyses.
* refactored patch_search.py
* fixed H Seam position on v2
* fixed seamless node bar total steps not accounting for batch size
* added uicd logic to make_seamless2.py
* removed mains from make_seamless.py & make_seamless2.py
* other minor cleanups
- triggered error in find_patch_vx due to random gen having a value equal or lesser than zero as argument.
Was not able to reproduce the error again so far.
Conjecture: it may be the case that the min error was negative due to lack of precision when using patch v3, resulting in an empty list of candidates if tolerance is not zero; if this is the case the error should happen only when using version 3.
* remember to change LatentQuilting to follow the same design pattern!
* also found bug when using certain block_size/text size combos; suspect it is due to "extended" texture size when using parallel ( to be investigated ).
* instead of extending the texture at the bottom, last block touches the bottom edge possibly overlapping prior block by more than the overlap section.
* both solutions should now be ready for node implementation after cleaning up unneeded code.
added lookup_texture to make_seamless.py solution;
modified make_seamless.py to allow of bigger block_size in make_seamless_horizontally & make_seamless_vertically.
in case of draw only, but likely rare... consider removing this line later or add a second tolerance argument that is separate from the auxiliary generation
tested w/ coeff but when reverting back to source forgot the cv flag.
i think it is fix, but will have to look again with fresh eyes some other time...
TODO next:
1. need to clean code a bit for both implementations;
2. 2nd method does not have seamless for both directions. I can patch the texture using one of the other two already implemented fixes. However, it might be a good idea to setup both this new solution and the previous to place the seam in the same spot, so that I can re-use the code.
3. Implement the nodes and provide the relevant options.
I cannot recall by heart, but I think that point 2, or eventually 3 (if only using one node), will likely require the 1st implementation to not extend the texture size; seems likely that that option will be removed.
I want to test an alternative approach to make the texture seamless, but, in order to re-use already existing code without using ui related stuff when testing all ui related args must be optional.
Bundling them within a single type simplifies the job and improves readability.
- Renamed quilting folder to jena2020 & parallel_quilting.py to quilting.py.
- Moved generateTextureMap from jena2020/generate.py to quilting.py; renamed it to generate_texture; replaced code sections with previously defined auxiliary methods.
- Fixed zero parallelization level to work with any version.
- Version 2 now converts image to Lab color space (supposes source is in RGB); this is only done to images, not to latent images. ***
- Changed find_patch_v3 behavior.
***
cv is now imported in nodes.py. Therefore, to use any node, cv must be installed.
note that in current implementation conversion to Lab format is done in the ImageQuilting node since it is only applicable when using images.
Updated requirements.txt to include opencv.
Add patch_search option (named version) to existing nodes.
Additional notes:
- make_seamless.py should use the methods implemented in path_search.py (currently it is not, and its implementation has a bug).
- consider importing cv only in functions, this way the prior solution can still be used w/o updating requirements... the speedup is so worth though... it might mislead potential users to keep using the 1st implementation... may should remove old solution and force opencv instead? ( to decide later, after seamless node implementation )
! changed previously tested func. to use the matchTemplate, it was not set everywhere in make_seamless.py.
* matchTemplate seems to have better matching (at least when using 4 ways, not sure if the same applies when generating a texture).
* matchTemplate seems considerably faster than "moving window" pixel by pixel in a for loop.
:: Likely a good idea to replace original implementation w/ matchTemplate.
!! Once done it will be a breaking change.
! if guess_block_size proves useful, will likely add a node for it.
bmad4ever