Astropulse / sd-palettize

Automatic1111 Extension for palettizing generated images
120 stars 10 forks source link

[Request] Semi-predefined palette? #4

Open giteeeeee opened 4 months ago

giteeeeee commented 4 months ago

Say, I have a 8 bit image/url input to dictate the extension to generate from, while still wanting a 32 bit image. This means the other 24 bit will be decided by the extension while 8 dictated by my image/url input.

Will this be possible to implement?

Regardless, highly appreciate the extension :)

Astropulse commented 4 months ago

For the sake of clarity, are we talking about color count or true 'bits'? I'll proceed with the assumption that it's color.

This should be possible to add, though there is a very good chance that the manual colors will go essentially unused, since the 24 selected by the code will almost always be a better mathematical fit.

With the methods I'm using there is no way of biasing the algorithm to prioritize the manually selected colors.

giteeeeee commented 4 months ago

For the sake of clarity, are we talking about color count or true 'bits'? I'll proceed with the assumption that it's color.

This should be possible to add, though there is a very good chance that the manual colors will go essentially unused, since the 24 selected by the code will almost always be a better mathematical fit.

With the methods I'm using there is no way of biasing the algorithm to prioritize the manually selected colors.

Yes I'm just talking about the number of colors.

Ah I see. Then will it be possible if the 8 or whatever number of colors dictated by input also comes from the algorithm? Like, I would generate a 8 colored image using the extension to dictate the core colors, forming the backbone of my palette. So now this "constant" palette will be equally treated by the algorithm to the "variable" palette for subsequent generations? Though I assume the algorithm preference varies per generation?

The purpose for this is because a pixel art asset containing multiple sprites should have an unified palette or the number of colors, for a unified look. But this is often too restrictive. So the solution is to have one backbone palette to unify the main style across multiple sprites, while each specific sprite can decide the rest of its variable palette.

Astropulse commented 4 months ago

I'm not sure how I would implement that, but you're more than welcome to try and make a fork/pull request if you figure it out.

giteeeeee commented 4 months ago

I'm not sure how I would implement that, but you're more than welcome to try and make a fork/pull request if you figure it out.

The workaround method I proposed earlier is actually manual not code-based. That I manually generate a 8 color image using the extension. Then feed that to the image input. Then ask the extension to generate a 32 color image like usual, letting the extension decide the rest of the 24 colors. You previously said it's possible but the algorithm won't bias towards my custom 8, but now the 8 is actually from the algorithm (though manually generated from a separate run). So not sure if that will remove the bias given the bias isn't per run?

Sadly I'm more of an artist than programmer :(. That's why the request. But yeah I understand that's a really niche request. It would make sense not to bloat the extension with it.