A little background on me - I'm a professional game developer and I've been working in AAA for about 10 years now. I've always had a soft spot for pixel art though, and even though I'm by no means a great artist, I still enjoy making it on occasion. I'm always trying to think of ways to make pixel art easier and faster and when I found out about Dan Fessler's HD Index Painting (http://danfessler.com/blog/hd-index-painting-in-photoshop) I was amazed!

For my next side project, I did a fairly big (for me at least) pixel art illustration using the technique and it came out fairly well. However, I discovered a few problems with his method - it was clunky to have to set up the layer filters for every layer, it was very difficult to use more than a few colors in each layer, you couldn't really control the colors that it was generating, the white+black to color ramp conversion made things more complicated, the dithering pattern was decent (but there are a lot of ways to dither an image), etc. Last year I chatted with him briefly about an idea I had for an evolution of his method, and he seemed cool with the idea. It's been kicking around in my brain for a while now but I've finally gone and implemented it.

Presenting the pixel art filter for Krita



This filter overlaps with some of the functionality in the pixelize filter and the index colors filter and also add support for a bunch of different dithering algorithms. It differs from the index colors filter in that it lets you specify a palette of colors to compress the image on to. You can create a filter layer to draw with the filter in real time, but most of the error diffusion filters such as Floyd-Steinberg have performance issues on larger images. I don't know if this is fixable since those algorithms are not very parallelizable and require the entire image to be processed. Anyway I think this will be of great benefit to the pixel art community.

Here is the code
https://invent.kde.org/nweihs/krita

Here is a windows build in case anyone would like to test it
https://drive.google.com/open?id=1RbcYcvZdFlUaCzTpb2xl6GJEkLdQJfbr

You can access it by going to Filters->Artistic

General feedback is appreciated, but I have some specific questions for the krita devs.
1. Is this something that I could get mainlined for the next krita release?
2. Would it be feasible to integrate krita's built in palette system to select palettes from?
3. Is there a better name than Pixel Art for the filter?
4. Is the overlap with the other filters (index colors and pixelize) problematic?

nweihs wrote:1. Is this something that I could get mainlined for the next krita release?
2. Would it be feasible to integrate krita's built in palette system to select palettes from?
3. Is there a better name than Pixel Art for the filter?
4. Is the overlap with the other filters (index colors and pixelize) problematic?

Lovely work!

1: Yes. It's planned for september or october, depending on my progress with the resource handling rewrite
2: Yes: there is a generic widget to get a palette from the available palettes
3: I think it needs to have someting with "dithering" in its name, to distinguish it from the new Posterize filter, which also reduces the number of colors.
4: No, I don't think so.


Note: make sure you update the header copyright blocks with you name and the correct date. They read Michael Thaler 2005 now

Seems to have quite bit of overlap with palettize filter.

Yes... But the dithering is quite different, isn't it?

Yes, more dither methods than just ordered that palettize supports.

Wow the palettize filter is really close! I wasn't aware of this filter when I started working on my filter. I wonder if it would be prudent to fold my work into that one instead of making a whole separate filter.

nweihs wrote:Wow the palettize filter is really close! I wasn't aware of this filter when I started working on my filter. I wonder if it would be prudent to fold my work into that one instead of making a whole separate filter.

I would love that

Just posting this conversation I had with surt over PM so that the over krita devs are in on what's going on

Hey man,

I took a look at your palatalize filter and it's really cool! The quality of the ordered dithering is great (better than mine at least), and there are some interesting options for configuring it that I didn't consider, particularly with alpha. So would you be cool if I added some of the work I did to your filter instead of making a whole new filter? If not, we can just do our own thing, no worries.

The changes I'm thinking are
- Add error diffusion algorithms as an option for dithering
- Add the ability to pixelize the image before applying the palette/dither (not absolutely necessary, but potentially makes it easier to work with error diffusion filters)
- Display the name of the palette you have selected (and possibly the number of colors) on the configuration widget
- Add the ability to import .png and .gpl files for the palette directly from the widget

Again, great work dude, and looking forward to hearing from you.

I'm just a new Krita dev my self, so I don't hold any sway and don't take anything I say as gospel.
Could be good to keep this discussion on the forum so can get input from proper devs.
Feel free to copy my response if you want to respond there.

So would you be cool if I added some of the work I did to your filter instead of making a whole new filter?

Would be ideal.

- Add error diffusion algorithms as an option for dithering

I had considered adding error diffusion, but didn't think it could really be updated on just the edited parts of the image due to the error needing to propagate from pixel to pixel and scanline to scanline.
For filter layer purposes I think it's important that it updates fast enough to remain relatively interactive and doesn't seem to lock up with larger images.
I'm all for it if it can be done in a responsive way.

- Add the ability to pixelize the image before applying the palette/dither (not absolutely necessary, but potentially makes it easier to work with error diffusion filters)

This kind of functionality is definitely something I want, so I can paint in high res and high colour while seeing the downscaled and quantized result.
Ideally this would actually change the resolution of the composition pipeline so you can apply any filter at the new pixel density.
I've been considering some kind of upscaling/downscaling layer type which could be used for such resampling or for scalers (https://en.wikipedia.org/wiki/Pixel-art ... algorithms), but I expect that'd be a pretty big job.

- Display the name of the palette you have selected (and possibly the number of colors) on the configuration widget

That'd be cool. I had considered dropping a label beside the palette popup button just to use up the empty space.

- Add the ability to import .png and .gpl files for the palette directly from the widget

You can already import palettes from palette file formats (open button at bottom of palette selector popup). Importing palettes from image files should probably be added to the global palette import functionality then it should be available in filter by default.

I had considered adding error diffusion, but didn't think it could really be updated on just the edited parts of the image due to the error needing to propagate from pixel to pixel and scanline to scanline.
For filter layer purposes I think it's important that it updates fast enough to remain relatively interactive and doesn't seem to lock up with larger images.
I'm all for it if it can be done in a responsive way.

I don't think this is going to be possible using the current set of algorithms unless the image is very low resolution or is being downsampled heavily. However it might be possible to do a new version of an error diffusion algorithm that's more real time friendly by doing it in a more parallel way. Usually error doesn't get diffused more than a handful of pixels away. I'll have to think about it more, but I think there could be something there. Maybe do something like a Bayer kernel to scale the the error that gets diffused to neighboring pixels?

This kind of functionality is definitely something I want, so I can paint in high res and high colour while seeing the downscaled and quantized result.
Ideally this would actually change the resolution of the composition pipeline so you can apply any filter at the new pixel density.
I've been considering some kind of upscaling/downscaling layer type which could be used for such resampling or for scalers (https://en.wikipedia.org/wiki/Pixel-art ... algorithms), but I expect that'd be a pretty big job.

It would be amazing to have that feature to automatically upscale/downscale the image, but I think for now it would be good enough to just do what the pixelize filter does. In another art program I worked on, I just added the ability to downscale/upscale the image when you export to png. Maybe that would be a more viable alternative here.

The rest seems like we are in agreement. I'm excited to get back to this when I get some more free time.

Link to the scaling algorithms mentioned in the thread (the one that got broken after copying from PMs): https://en.wikipedia.org/wiki/Pixel-art ... algorithms

You could also try if two transform masks - upscale, [filter masks, transform masks, etc.], downscale helps in the workflow. (It's just an idea how to approach it using already available resources in Krita - of course not ideal even if it works because of the three or more masks needed to achieve it).

nweihs wrote:I don't think this is going to be possible using the current set of algorithms unless the image is very low resolution or is being downsampled heavily. However it might be possible to do a new version of an error diffusion algorithm that's more real time friendly by doing it in a more parallel way. Usually error doesn't get diffused more than a handful of pixels away. I'll have to think about it more, but I think there could be something there. Maybe do something like a Bayer kernel to scale the the error that gets diffused to neighboring pixels?

Sounds promising. A quick web search suggests there are a few parallel methods about.

tymond wrote:You could also try if two transform masks - upscale, [filter masks, transform masks, etc.], downscale helps in the workflow. (It's just an idea how to approach it using already available resources in Krita - of course not ideal even if it works because of the three or more masks needed to achieve it).

That's a great idea. I hadn't thought of that. And by transforming then reversing the transform it gets around my biggest issue with transform masks being that you can't edit in the transformed space.