Commit
·
ec5f313
1
Parent(s):
eb487c3
Update readme
Browse files
README.md
CHANGED
@@ -44,6 +44,10 @@ A: Use Png. Jpeg's compression algorithm is terrible for pixel art.
|
|
44 |
|
45 |
Q: Why is this needed? Can't I use a post-processor to downscale the image?
|
46 |
|
|
|
|
|
|
|
|
|
47 |
A: From my experience SD has a hard time creating genuine pixel art (even with dedicated base models and loras), where it has a mismatch of logical pixel sizes, smooth curves, etc. What appears to be a straight line at a glance, might bend around. This can cause post-processors to create artifacts based on quantization rounding a pixel to a position one pixel off in some direction. This model is intended to help fix that.
|
48 |
|
49 |
Q: Should I use this model with a post-processor?
|
|
|
44 |
|
45 |
Q: Why is this needed? Can't I use a post-processor to downscale the image?
|
46 |
|
47 |
+
Q: Is there special A1111 user-interface integration?
|
48 |
+
|
49 |
+
A: Yes... but not yet merged into the standard ControlNet extension's code. See https://github.com/thomaseding/sd-webui-controlnet/tree/teding/feat/pixelnet if you want to integrate the changes yourself in the meantime.
|
50 |
+
|
51 |
A: From my experience SD has a hard time creating genuine pixel art (even with dedicated base models and loras), where it has a mismatch of logical pixel sizes, smooth curves, etc. What appears to be a straight line at a glance, might bend around. This can cause post-processors to create artifacts based on quantization rounding a pixel to a position one pixel off in some direction. This model is intended to help fix that.
|
52 |
|
53 |
Q: Should I use this model with a post-processor?
|