This forum has been archived. All content is frozen. Please use KDE Discuss instead.

Implement Indexed-Mode for Pixel Art

Tags: pixel art, indexed, palette pixel art, indexed, palette pixel art, indexed, palette
(comma "," separated)
User avatar
tushantin
Registered Member
Posts
33
Karma
0
OS
Not entirely sure if this has been requested already, which is why I was hesitant for so long about posting this, but I hope somebody gets on this.

I know a lot of game-developers use Godot these days, but I still have some fondness for old engines that use Indexed PNGs / GIFs with .PAL / .ACT colour-palette exports. As far as I know, only Photoshop and Paint Shop Pro manage that effectively (besides other niche pixel-art specific software as elaborated in GDC), but while GIMP possesses this to some degree it's still pretty limited.

Krita, on the other hand, doesn't even have it. This is important because a lot of pixel artists seem to love Krita for what it can do so quickly and easily. Adding an Indexed mode is going to help a lot.

Current GIMP 2.10's Indexed mode is quite nice (compared to Photoshop, at least from my previous usage) in the sense that it doesn't flatten your image. When change the mode from RGB to Indexed it'll ask you which Palette you want to use, and you can specify a palette you may have already created. It then applies that palette individually to every layer, so that you can continue drawing non-destructively (unless, of course, there are gradients involved).

Krita can do something similar, in my opinion, except it doesn't have to be limited to just layers, but also frames. The reason being it's not easy to create a complex pixel animation in GIMP and export the frames as indexed PNG sequences along with the palettes as .ACT / .PAL. Krita's animation system can solve that problem really well because its layer and frame systems are different.

Another issue that GIMP possesses is that, while creating palettes is fairly easy, when you index your document it copies your created palette to each layer rather than connect them mutually. In other words, if after indexing you decide to add / remove some more colors, you can't do that by merely changing them in the palette, because it won't reflect on the art, nor can you just "change" an existing color to something else on the fly. No, you have to change it back to RGB, change the palette, modify each layer accordingly, and then turn everything indexed again with the new palette.

Krita can solve that issue by taking cues from how OpenToonz handles color and palette (even though OpenToonz doesn't use Indexed mode). That way, if an artist wants to just change, say, the color of the character's clothes or create variants of the same character, all he'd have to do is change the palette's Blue to Red, for instance.

I understand that some folks might argue that modern computing does not require indexed color-management, and I get that. However, I would also suggest taking a look at this glorious thing for what indexed colors can do: https://www.youtube.com/watch?v=aMcJ1Jvtef0

Anywho, if somebody is able to code that into Krita and make it a joy to use it, I'd very much appreciate it. I'm sure that pixel artists would largely love it too.
User avatar
halla
KDE Developer
Posts
5092
Karma
20
OS
I doubt you'd get anyone to spend the amount of time necessary to make something like this work and then maintain it...

It would mean implementing a completely new color engine plugin, something that hasn't been done since 2007. We used to have four color engines (lcms-based, openctl-based, unmanaged and spectral_ but the people who coded the openctl-based and spectral color engines disappeared, and that means the engines were unmaintainable. Working on this requires a real commitment from someone who is really good with C++.

Also keep in mind that pixel art isn't part of Krita's vision; it is not a use-case we keep in mind when designing new features or enhancing existing features, just like photo editing or astronomical analysis. It would need a really strong advocate showing up with code and commitment to change that, at the very least.
User avatar
tushantin
Registered Member
Posts
33
Karma
0
OS
Hmm, that's a shame. I understand this isn't part of the vision, just thought it would be cool to have. If somebody could, theoretically, make a plugin for it, that would be pretty cool too.
User avatar
halla
KDE Developer
Posts
5092
Karma
20
OS
Oh yes, if someone would start on the code, that would be very cool; even more than that, it would prove the author's credibility as a very accomplished coder.
SouthernYago
Registered Member
Posts
5
Karma
0
tushantin wrote:I understand that some folks might argue that modern computing does not require indexed color-management, and I get that. However, I would also suggest taking a look at this glorious thing for what indexed colors can do: https://www.youtube.com/watch?v=aMcJ1Jvtef0


That is true, and I knew that video, very inspiring. Unrelated with the hardware being more powerful today, and just considering the workflow matter, I worked at a company doing quite serious stuff (around 2005, pixel art was indeed a must), a bunch of 2D games in pixel art, and I created all that in RGB, without issues. When needed extra playing with the PAL stuff I even wouldn't use Photoshop features for it, and instead, specialized, free (better said, freeware and open source) standalone utilities (some not even with a GUI. One of them was Imagemagick, but combined with others. )

While all what the OP says is true (I remember a boxing game where adding new enemies would mean just changing the hue through the palette...still you can replicate that workflow in other ways, in RGB, just as easy), just giving here a testimony about the fact that you can (and in certain software apps, like PS, this even has interesting advantages) produce high quality pixel art, keeping all the style and stuff, just in RGB mode. You only need to know some tricks, and use certain workflows. This does not pretend to remove any value to what the OP said. Besides, maybe I'm alone here (I'm usually alone :D ) but I found that the features for palette handling in PS and similar products, even in PSP, was too limited compared with what very specialized freebies could do (or what Deluxe Paint could do in its days). I prefer if the painting software is the best it can be for painting and pixel pushing, and then use external specialized jewels. In another very different workflow, doing 3D toon-rendered character animations, that is, toon rendered for 2D, to integrate -as we did, successfully- into fully 2D Flash games (with illustrated backgrounds, etc), years ago, I ended up preferring to use external batch utilities to perform a bunch of batch edits over all the frames. You could do that very powerfully with PS and it's folder batch processing, combined with Actions (excited to see that Krita 4 supports Python), it is indeed very powerful, but I could get quite some more flexibility with the external batch tools. Sometimes it can't be all in the same UI....my 2c of the dangerously growing euro.


Bookmarks



Who is online

Registered users: Bing [Bot], Google [Bot], Sogou [Bot]