Color balancing your pixel art

[Helm]

Recently I posted somes older game art I did for a client on pixeljoint, here's the image for Pix as well



I got a few questions about how I pick colors, something that I've been asked a lot, generally, but more important to me lately because I have something useful to answer with.

Never was much for colours, honestly. On paper I am a black and white, ink or wash tone artist. I literally learned color through pixel art, and the idiosyncratic aspect of me was very interested in 'symbolic colors' from early on. I wasn't so much interested in realistic representation with color, instead I would use, say, a green tint as some sort of visual language (green for me for example is usually sickness, evil, depression, stuff like that - very common interpretations).

So, influenced by certain demoscene artists at the time and from the pixelation kind of way of doing things (which was at that time being in a constant feedback state, it wasn't set in stone) I would spend a lot of time trying to

1. get palettes to be small, usually sub 16 colors, and
2. get a lot of hue representation in there, what we ended up erroneously calling 'hue-shifting'.

Good sense on which hues to choose to move towards and through which grey steps I never felt comfortable that I could explain or 'teach' in any capacity. This isn't what this thread is about. When people, 5, 8 years ago would ask me how I choose colours, I didn't have anything interesting to say, I don't think.

What I can tell you now is that my choice at that time of introducing a lot of grey slots between more saturated colors created a very certain 'look' that I wanted to move away in the last few years. And one of the tools I now use to do this (and I used it in this piece as well), is that I go in photoshop and use color balance somewhere in the middle of creating a palette.

I'm sure you can do it in some other program, but the concept is the same. RGB sliders for shadows, mid and highlights, in a 24bit color space, regardless if you're going to end up with 16 colors or what.

Why is this useful?

Building on my ideas about symbolic colors, an overarching tint to a picture can be very useful, especially a balance between two tints. Above the attempt was between the yellow/orange in the earth and the purple and cyan in the shadows and sky. For me that's a picture of summer. But it didn't start out with this colorspace. At one time the hand-picked shades were more in the middle of what's going on here:



I did a lot of color correction, then back to manually changing every palette entry, then back to color correction, then back to manual editing.

What is the benefit of this? It removes a lot of the muddy gray identity that a lot of my past art was left with. Nowadays I don't have this problem as much anyway because I do not use unlimited bit depth for my palettes so everything ends up quite saturated anyhow, but I know most pixel artists at this time are choosing their colors from a very large bit depth, so some sense of overarching tint would be useful for their process.

The theory is very simple - when you're adding +2 to red in the middle part of the values, if it finds a 20,20,20 color (a gray) it's going to make it 22,20,20, so from a gray it is now a gray-with-a-bit-more-red. If you take it really easy with this process, you can get an environmental effect, something like a soft bloom to work even for your pixel art.

As an activity, you could post pixel art (esp background art and tiles) that you think could benefit from this, before and after color correction and manual calibration.

Is this making sense, do you get what I'm going on about?

[DawnBringer]

You're touching on several issues here...not quite sure what the focus is.

[Helm]

Hm, let me put it in a concise way

Pixel artists edit their palettes index by index.

What I am suggesting is that it's good to do this, then do a holistic color balance pass, then back to index by index. 



This is what I'm talking about, btw

[32]

There's still this niggle I have about "dirty tools", a sense that real pixel art is all chosen pixel by pixel colour by colour. I completely don't believe that at all these days but it still sits in the back of my mind.

Now I'm very much prone to taking the easy route and using whatever tools will get the job done including colour correction or index painting or using animation software. Problem is it's always a chore to do this stuff, I have to export my images and lose my layers and frame layouts I've got set up in GraphicsGale to move over to the other software. It doesn't fit very nicely into a workflow to use the tools that should ostensibly make life a lot easier. It is very much a software issue for me, the pixel specific programs are so good at what they do I don't want to give them up but they really do force your hand a bit on some of the purist aspects. I would really like to see psd support in GraphicsGale, does Pro Motion have it?

Regardless I agree with this approach, I do it all the time in my non pixel work. Sometimes just messing around with sliders is the only way to tease out the right colours, no one gets that right on their first go. Next time I'm doing something that calls for it I'll definitely make a conscious effort to put it through some colour correction earlier in the process.

[Helm]

Nope, pro motion has a very silly way of handling multi-layered images, as in, it hijacks the frame animation system. So it's either animation, or layers, not both at once. Yep, you have to export and mess with in a different project as far as I know if you're using pro motion and you want detailed color balance.

[32]

Sounds similar to how photoshop handles the two actually. Each "frame"is just a set of which layers are visible. GraphicsGale's solution is each frame has it's own set of layers. Most animation programs each layer has it's own set of frames. I think the latter is the best solution but that's a different discussion entirely. I wish there was some standard image format for multi-layer multi-frame images. Doing inter-program work is a grind. I guess that's probably how they like it though .

[Helm]

Yes, ideally every frame of an animation should have its own independent layer structure, with capacity to copy/paste and alter layer x from frame y into layer x on frame y+1 and so on. But that's besides the point for this thread.

[Cyangmou]

about the balancing:

Hm, let me put it in a concise way
Pixel artists edit their palettes index by index.
What I am suggesting is that it's good to do this, then do a holistic color balance pass, then back to index by index. 

erm I think you can't generalize that.
It completely depends on the software you are using.
While GG and Pro-Motion might not have an overall color adjustment tool, Photoshop and Gimp come with a wide varitey of different tool.s, gradiation curves, saturation changes and a lot more stuff for very specialized use.

However
As for every tool we use it's not about the tool, but about the person behind the tool.
If you know your goal and you change your colors in order to achieve that goal, how you do the changes is completely irrelevant.
We can edit single indexes alone or we can edit multiple indexes with that color balance and a quick preview at once.
While from hand it would take hours to get to the same result, the tool allows quicker experimentation, more versions with a quick preview.
It's up to everyone himself to use the tools available. No need to discuss "true" or "untrue" in there.

Color adjustment is sure a nice and very common used process for everyone who wors with PS/Gimp etc. or opens a piece in those programs just for that.

I think it's a completely different thing with the gray in your palettes.
The matter you described with it seems to be a consideration because of the limited colors and to use every hue everywhere. Gray istself is neutral and works next to each color.
Of course if you are using gray you are graying out parts partially which has a completely different look than not using gray.
The question is if the gray is in the ramps because of the limitation and it's multiple uses in the pieces, or if you would consciously use gray even if you have mor ecolors at hand.

Then it's very easy to forget about gray as a color on it's own and don't use it at all in any of our palettes - which leads to a very colorful and cartoon-style direction. Where "gray" has rather green or blue tints or is even purple - look at a lot of zelda games.

In respect to games:
However it's impossible to set accents or to bring the attention to something special (in a game it's always very bad if the bgs are so color-flooded that it's for the sprite artist impossible to make the sprites popping) - that's why I would have to see the whole thing build together.
You could either go very black or very white with the sprites - so with a clear value separation, but it will get pretty hard with a color sepearation (unless you use red, which I think would disturb the overall color scheme)

The difference?
The main change from this piece to a lot of your older pieces is that it has very clear complimentary colors - yellow - purple in the house, orange - blue for foreground background.
Even the green in the middle appears because of the atmospheric density more as blue for the overall scheme, while we know it's pure green.
Since you completely excluded reds in your palette, the green also isn't as striking as the other 2 complimentary pairs.

What I think:
For me it's just a different style how you considered the nodes in your palette which leads just to another impression.
Since most of your stuff was pretty dark themed, the gray never felt out of place to me.
Your usual way of working might not have worked that great for the summer-scene example.

[DawnBringer]

@Helm: Ah, ok. Hmmm...are you implying this is an uncommon practice? If an artist is working with +20 color palette and feels it needs a bit more red...I hope his program allows for some method to tweak all or a selection of colors at once.

On a more technical note; I'm glad you brought up color balancing rather than hue-shifting which usually offers less control and can be a bit destructive.

At least Grafx2 provides very good palette control, and while I have lua-scripts that can perform every thinkable color-modification, I still find that manual RGB-slider tweaking suffice 95% of the time.

I don't think there's anything wrong with a bit of color-balancing, hue-shifting or any other color-tweaking, if it will help the artist fulfill his vision. Esp. if one is working on larger scenery with a certain mood/atmosphere (like your recent image) it's quite applicable to make (some) broad-spectrum adjustments rather than constantly tweaking individual color indexes.

[ErekT]

It's a good trick. I've been using it a lot to try and accentuate certain moods or just add uniformity. Colors start to look obviously processed when I do (to me at least), so more manual palette tweaking after the fact usually follows. Or sometimes just a semi-transparent blend between the color-balanced image and the old until I feel it looks right.

But I've been getting a big kick out of playing with limited bit depths lately so there's been less use of this approach nowadays. Limited bit depth is strangely liberating, colors go where they want to be almost automatically. It almost feels like cheating

As for every tool we use it's not about the tool, but about the person behind the tool.
If you know your goal and you change your colors in order to achieve that goal, how you do the changes is completely irrelevant.

But if you don't how to most effectively make those changes or even have a clear idea what your goal is then methods like this can be very helpful. I never know precisely the colors I'm gonna use up front. I have a certain idea, but the end palette is never what I had in mind originally. It's always a process of experimenting and tweaking until I end up in a place I'm satisfied with.

[Cyangmou]

As for every tool we use it's not about the tool, but about the person behind the tool.
If you know your goal and you change your colors in order to achieve that goal, how you do the changes is completely irrelevant.

But if you don't how to most effectively make those changes or even have a clear idea what your goal is then methods like this can be very helpful. I never know precisely the colors I'm gonna use up front. I have a certain idea, but the end palette is never what I had in mind originally. It's always a process of experimenting and tweaking until I end up in a place I'm satisfied with.

Well that's exactly what I put in the next sentence.
Experimenting is good  tools help to quickly experiment 
But if you are going for a special form of light or ambience, you usually know how it should appear (you have an idea) or you look in the process at a reference and you know what to change.
But you also have the same idea if you would tweak every color on it's own.
The tools obviously don't help in a good way if you don't know that there is different colored light which differently affects planes of different materials - you could get somewhere just by observation, but understanding is usually much more effective than guessing.

However
As for every tool we use it's not about the tool, but about the person behind the tool.
If you know your goal and you change your colors in order to achieve that goal, how you do the changes is completely irrelevant.
We can edit single indexes alone or we can edit multiple indexes with that color balance and a quick preview at once.
While from hand it would take hours to get to the same result, the tool allows quicker experimentation, more versions with a quick preview.
It's up to everyone himself to use the tools available. No need to discuss "true" or "untrue" in there.

[ErekT]

Oops, I need to read more closely :p

[Helm]

Do note I didn't say anything about the 'true' or 'correct' way to do things, it's really not to my interest to engage in metaphysics here.

On that 'the same result can be achieved manually', well, of course. The main asset of this trick I am advocating for is that you're editing more than one color at once in very fine ways and you immediately get visual feedback. Were you to do it manually, you'd have to do 20 different color alterations one by one, save the new state, go back 20 steps and swap between the two.

For me being able to work fast is a big part of becoming a better artist because the faster you do it, the more often you do it, and the faster you do it the less disinclined you'll be to try it when you need it.


Of course at the end of any color balancing trick you would have to manually readjust every index entry to maximize what you're doing with them, that goes without saying.


Dawnbringer: does Grafx2 allow for pallete alteration like this? If so, it has an extra leg up on pro motion. This is a very common practice in CG drawing, but not in pixel art, I've found.

[rikfuzz]

I'm constantly dicking around with levels, colour balance, vibrance, curves, etc.  It's fun, and, certainly quick and useful.  But I think, actually, what people are asking when they question how Helm arrives at his colour choices isn't the subtle tones over-arching the palette, but his generally surprising choice of hues in a small area. The branch is made up of orange, mustards and green with vibrant purple shadows, for example. 

I often find I use more interesting colour combinations this way when I'm using a limited palette. But best when it's a sort of generic one, for various scenes/objects.  If the palette was tailored specifically for that one scene/item, I guess I'm afforded the option of being more conservative. 

[RAV]

I remember once having had a similar talk with DB about palette "after-effects".
I have a global-modifier key, that when held, colour-modification keys affect the whole palette, not just the selected slot.
Since the fluid changes are seen realtime "in-game", this makes for some pretty dramatic mood swings, in a good way.
It's just one of those little simple things you don't wanna miss once tried. So, I guess I just wanna say: hell yeah, baby.
not that it matters...

[DawnBringer]

@Helm: Grafx2 allows you to, in realtime, change any color-channel for one color or a range of colors. The buttons on the right also allows to change the brightness of the selection (+/- 1 to all three channels). There's also HSV controls. (However there's no automatic brightness preservation etc.) You can quite easily re-arrange the palette if you need to group the colors to be affected. Nothing really advanced, but it works very smoothly.



As for the scripts, they can do pretty much everything...but they don't have interactive controls, thus not updating in real time   So it can require a bit of trial & error. Although it IS possible to write interactive/updating scripts controlled via keyboard.

[0xDB]

Nope, pro motion has a very silly way of handling multi-layered images, as in, it hijacks the frame animation system. So it's either animation, or layers, not both at once.

Spoiler

Please excuse this bit of off-topic thread pollution but it is possible... just not all that intuitive to set up. I hope this explains how animation&layers are achieved simultaneously in Pro Motion (v.6 and 6.5 (do not know about earlier ones)):





A: First you create one project per layer (do not yet activate the layers button). Add as many frames as you want per layer (does not even have to be the same frame count). You can change these projects later as well, either individually or while working with them all at once, utilizing the extra project in step B.

B: Create another project. That project is not a layer itself but it is the project you use to manage the layers, it does contain only layer definitions but no actual image data. There is no "Layer Management Project" type to select when creating a project, just calling it that because that's what the project does, it merely defines layers and a frame count but has otherwise no own content of any kind.

C: In the "layer management project" activate the layers button. Now add as many layers as you like and in each layer properties, set the "Source Of Frame" property (D) to respective animation project from step A to display inside that layer. You can even select opacity and transparency per layer.

Now add frames to the layer management project and it will just display whatever it pulls in from the other projects into that frame and note how clicking on a layer makes the project that is displayed at that layer the active project.

And there it is, multi layered animation in Pro Motion. Not very intuitive but once you know how it works, it seems like a clean and logical way to do it.

When you save the layer management project and later open it again, each layer will display an info string, notifying you of any "linked projects" which are not currently loaded.

[Helm]

What- W-What? I'll check this out at work first thing tomorrow, thank you!

but his generally surprising choice of hues in a small area. The branch is made up of orange, mustards and green with vibrant purple shadows, for example.

I have no idea how to communicate this to people because they don't look surprising to me.

It'd be cool if someone ported the color balancer to pro motion as some sort of plugin. I'd use it more often if I didn't have to swap programs all the time.

[Ai]

There's also HSV controls.

HSL, actually.

I made a GIMP plugin awhile ago to ease the pain of this kind of adjustment. It turns your palette into pixels on a layer that you can then apply whatever filter to and ultimately transfer back to your palette.

This allows the preservation of palette order, which addresses my primary issue with converting to RGB in order to do Hue/sat/etc adjustments -- it normally destroys your palette order (and also some of your image data, if you happen to set two colors the same.).


There are some interesting filters in the GIMP GMIC filter collection that anyone considering this general technique may like to try. I made up a simple album here.

@Helm: IMO your color choices are like applying a Sharpening filter to the Hue channel only, with a small radius; you 'blow out' the color identity of the object a little and obtain more pop. You can contrast this with much of pixel art, where, if anything, the sharpening is only applied to alter the colors of the basic ramp (ie. exaggerate hue and saturation differences), for the same reasons -- more pop. So you are doing spatially what most pixellers only do to their palette.

I don't know if this is a digestible explanation for others, but if you have a basic understanding of how Sharpen works, it fits your general pattern of hue choices well.

[Helm]

Honestly, not sure I get it

[Ai]

Another way to think of it is as strategic JPEGification. Which I'm sure you are horrified by, but I'm just trying to hit something you understand here -- JPEGification, especially at high compression levels, generates a lot of noise in high contrast areas, and hue distortion. It's not as close a match as simply sharpening the hue channels, but perhaps you can relate to it easier?

Anyway, I took a likely looking image from PJ over here, and applied various sharpening filters on the Hue or a+b channels (these are roughly equivalent). This is easy to do with GMIC, don't know another tool that lets you do that easily.


This includes the original for comparison.

Various degrees of resemblance to your color choice are apparent. It is most accurate, IMO, on the rocks. The rocks retain their overall color identity but, when zoomed in, the hues near edges are exaggerated in a way that increases contrast. In one frame the mammoth in the background gets a green highlight on its tusk, which struck me also as a choice you would make.
The overall effect is IMO better than just a standard sharpening (much more common, pretty much everyone does -that- AFAICS). It might be especially helpful for partially colorblind people.


A simple explanation of Sharpening might be:  it looks at the values in an area, and moves the resulting pixels 'apart' visually in proportion to how different they are. It increases local contrast, as compared to using, say, Contrast/Brightness tool.
Contrast/Brightness affects global contrast/brightness because all pixels of a given color are output as the same color -- the pixels around them do not affect the result. Neither of them need to be applied on any particular kind of channels, they are completely channel agnostic. Applying them on the three channels R,G,B is just the most commonly useful choice.

(I don't know what I definitely need to explain here, so don't be offended if I explain something you already know. I'm not really sure who knows what, though I'm getting the impression that a technical understanding of filters an artist might commonly use is relatively rare.)

EDIT2: I guess another point worth making is that this effect that you do with colors works better than it might otherwise because you tend to choose more faded/greyed colors as base colors to start with.. Kind of like squeezing most of the color to the edges like water in a sponge.

[0xDB]

It'd be cool if someone ported the color balancer to pro motion as some sort of plugin. I'd use it more often if I didn't have to swap programs all the time.

I have had "look into Pro Motion plugin development" on my things-I-want-to-try-sometime list since forever, so this might just be the thing I will use to get into it. Here's an early work in progress screen (in spoiler along with ramblings):
Spoiler

I think I will need at least another day or two to get even a rudimentary working version done (it involves some archaic Win32-API programming which means 90% of the time, I am not writing any logic code but wading through old API documentation or writing system/initialization/cleanup code which is necessary but does not really have anything to do with the concept of color balancing or communicating with pro motion).

I have no clear concept of how the color balancing works in other applications though, so I have a straightforward approach in mind on how to do it. I will normalize the slider position to a value ranging from -1.0 to +1.0. Then I will modify each RGB triplet by multiplying each component with a factor derived from the slider value as mf = (1.0 + sliderValue) and cap the result at 255.

This will probably need some tweaking though because component values above a certain level would quickly climb towards their maximum as the slider gets pulled further to the + side.

And what happens for example if the R component is already capped at 255 (e.g. by starting at 170 and being multiplied with 1.5 (first slider halfway towards full red)). Pulling the slider further from that point forward would leave the R capped at 255 and unchanged... should the "excess energy" then be used to pull down the G and B components to make the RGB triplet more red as a whole?

Or should the modification perhaps be non-linear, so that capping never happens? This could be done by subtracting or adding a fraction of the distance of the component towards its minimum or maximum value. e.g. if slider value is negative do: component = component - sliderValue*component, and if the slider value is positive: component = component + (255-component) * sliderValue.
This way, e.g. R 170 with slider 1.0 would end up at 255 and so would R 128. Hm... not sure if this sounds right though as then with a full red slider, each R component in every color would end up as full red no matter how not-red the R component is before the adjustment, even R 0 would become full red at +1.0 this way.

I will need to experiment with this... maybe even have different options in the end.

I think it should also have at least three palette states to store/restore upon clicking some extra buttons for that:
State A: The palette as grabbed from Pro Motion upon starting the plugin (so one can always undo any damage by sending that back to pro motion).
State B and C as two different sets of slider states which can be stored retrieved to quickly switch between alternatives for making a decision which one suits the piece more.

Thoughts?

[Helm]

Whoa, I didn't expect anyone to actually do it. Perhaps this link helps? http://www.retouchpro.com/forums/input-output-workflow/33347-how-does-photoshop-color-balance-command-work.html

[0xDB]

Hm... not sure about the information in that link... seems to be a lot of wild speculation in there.

I am done hacking up something fairly usable now (oh how the hours melted away like minutes...in a bad way sometimes... the Windows-API is just so...yuck! (but I love Pro Motion so it was totally worth all the trouble)).

It does not have a proper website yet but here is a screenshot and links to the thing itself(<- download) and instructions (also included in the .zip). Let me know if anything needs clarification.

[0xDB]

Hm... color balancing is interesting. Took two old pieces of art and played around with the color balance plugin:

--after balancing-->

--after balancing-->

So... that looks like crap right (they have many structural/pixel-technical problems too but the focus is on the colors and tones now)? Why is it interesting then?
What I think is going on: the source images do not have a good range of lows, mediums and heights. Each of those source images has an overbearing tint to it(first one towards orange and the second one towards yellow and magenta) and some of the original color choices are, independent of tint, not what they should probably be in tone either (most obvious example is the lower side of the cloud which should be much darker).

So what did the color balancing do? It quickly revealed that strong tint (I honestly did not notice that before I started playing with the sliders) and on top of that also revealed the tone range problem. This leads to both color balanced variants to look a little washed out and the first one also ended up very dark (second one feels a bit dark as well). If the initial tone range was better, as in, had lows and heights that made more sense (e.g. much brighter sky in the first example and a better transition from mediums to lows), the color balanced versions could look a lot more natural.

The conclusion I draw from this is: If it is impossible to isolate a certain area I see within the image as either lows, mediums, or heights within the color balancing, then the primary problem is not with the tint of the colors in the palette as a whole but with the tone(brightness) of the object in the scene.

Does this makes sense?

[Helm]

DANGGG you are a hero. Thank you very much. Can't believe a few days ago I was wishfully thinking for this feature and now it exists. I've tested it and it works fine for me. Actually, if I can do anything for you to pay back your work hours let me know, Dennis.

The values versus tones issue you brought up seems to be correct to me. A lot of issues with colors are often issues with values that people misunderstand as colors.

[0xDB]

DANGGG you are a hero. Thank you very much. Can't believe a few days ago I was wishfully thinking for this feature and now it exists. I've tested it and it works fine for me. Actually, if I can do anything for you to pay back your work hours let me know, Dennis.

The values versus tones issue you brought up seems to be correct to me. A lot of issues with colors are often issues with values that people misunderstand as colors.

I am equally surprised. I did not think I still had it in me to produce something useful and not get distracted, bored or fed up with it halfway towards the goal. I have been playing around with it a lot and having it is already a reward in itself. I am happy it works for you as well and I can not think of any payment. Just continue to make great art and to give great critique/advice and maybe spread the word that this exists where appropriate.

I am really happy right now and glad I could contribute something of use.

[DawnBringer]

Impressive, but I assume you haven't implemented functions/options for brightness-preservation which is key to quality color manipulation (however that can be a tricky sucker, one of the most challenging problems I've encountered...I landed on an iterative error-correction)

[ptoing]

This is the best shit ever! Go and write an email to Cosmigo so they put it on their page so people can dl it from there as well.

[0xDB]

@ptoing: Thanks.
I might send them an email but I should probably make a proper project page with a little description and screenshots first (I already tweeted about this @cosmigo but there was no reaction, so I guess they are just too busy anyway.) and let it rest for a couple of days or weeks to make sure I am really done with it and that I do not wish to suddenly add or tweak some feature(s).

@DawnBringer:
Yes that would be tricky because the task is to solve a single equation containing two unknowns after modifying each component of the color triplet... so there are three equations and six unknowns in total.

The relative luminance (I just call that brightness here) is calculated as:
yo = 0.2126 * Ro + 0.7152 * Go + 0.0722 * Bo
o = original
m = modified

In the Color Balancing Plugin I apply each modification sequentially, first red, then green, then blue, according to the user supplied slider values and depending on what the calculated brightness is.

So for example, when Ro becomes Rm, then the new brightness is:

ym1 = 0.2126 * Rm + 0.7152 * Go + 0.0722 * Bo

and to keep the brightness yo, so that yo == ym, the task is to modify Go and Bo or in equation form:
yo = ym1 = 0.2126 * Rm + 0.7152 * Gx + 0.0722 * Bx

One equation. Two unknowns. No unique solution to the equation. Could solve it for either Gx and keep Bx unmodified or solve it for Bx and keep Gx unmodified (or randomly keep "guessing" a solution where both are modified a little until ym1 is approximately the same as yo).

I decided against trying that because that would have an impact on the next two component modifications. The final Gm and Bm would end up being based on something else than the original color triplet, something which might be against the artists intent.

So I leave brightness preservation as an exercise to the trained eyes and capable hands of the artist who is in control of the sliders. If they pull down/up one component, they can tweak the other two components into the respective opposite directions a bit, in a weighting of their own choosing, to counter the decrease/increase in brightness manually and in a way that suits their intended result best (or even not do that if their intent is to darken/brighten via color balancing).

Pro Motion also already has palette editor where user selected ranges of colors can be tweaked by hue, saturation, brightness and contrast simultaneously, so using the built-in palette editor and the color balance in combination back and forth already provides the artist with all the control they need to reach the intended result (or to play and arrive at a visually pleasing result via happy accident).

[DawnBringer]

@Dennis. Oh, young padawan...that's not even half of it.

[Helm]

It's not the half of what? Am I missing something?

Dennis: much thanks again, I've been already using this at work.

[DawnBringer]

@Helm. Not so much a problem for the artist as the programmer. Brightness is exponential in nature, so when color-balancing you need to adjust for this to maintain the pereceptual brightness level. Then you have the boundary problem; 0-255...some requested adjustments simply can't be done to all colors without overshooting and corrupting the integrity. So you have to figure out how much change can actually be done to each color.

And if you wanna take this problem even further; there is this phenomena where colors approaching pure primaries appear "stronger" relative their brightness. I'm struggling to understand and quantify this effect, and I don't know if there's any colormodels that account for this (if someone has any info let me know). But in general I think the concept of brightness becomes muddled for more pure colors, esp. for red which is a "recent" evolutionary addition to the eye. Try comparing the brightness of pure red to grayscales...it doesn't quite compute.

[Helm]

Factoring in brightness shift for our purposes in color correcting pixel art is not such a big deal because most color correction (to my experience thus far) is about minute, -+4 alterations, not pushing something out there full bore. If one wants to play with really extreme variations, they can still take it to photoshop and turn on 'preserve luminosity'.

[Ai]

Then you have the boundary problem; 0-255...some requested adjustments simply can't be done to all colors without overshooting and corrupting the integrity.

This one, at least, has an obvious solution: HDR imaging. Which is not really any less applicable to pixel art than other things, it's just that no dedicated pixelling app supports it. (as opposed to Photoshop, Krita, etc which do, one way or another.)

https://en.wikipedia.org/wiki/Helmholtz%E2%80%93Kohlrausch_effect is the intensity problem. Nobody seems to have yet determined a colorsystem which is both a) easy to transform from/to, and b) accounts for the Helmholtz/Kohlrausch effect.

[0xDB]

@DawnBringer and @Ai:
Like I said, I leave it to the eyes and hands of the artist to decide what they want and theoretically, solving the equations I gave earlier (in whatever way: like I pointed out there is no obvious unique solution because the equation system that needs to be solved has more unknowns than number of equations and modifying the unknowns modifies the original tint (so the cost of preserving the brightness for brightness sake would come at the cost of losing the base color) either for each component modification sequentially or for all of them after fully applying all modifications, is the FULL description of the problem of brightness(relative luminance) preservation that needs solving if one wants to do that.

The wiki page that Ai linked to gives another reason why it is a good idea to leave it to the control of the artist and not some algorithm, because the lightness/brightness is perceived different by different humans (slightly relevant: that debate about gold/white black/blue dress (the point is that both tint and brightness perception also vary on context(what other colors are around/near a patch of any color so a full featured attempt at preserving that would require not only palette manipulation but also analyzing each individual pixel and comparing relative luminance and tint variations in both local areas of the image and globally for the whole image... but to do that right, you would need to hook into the users brain as well as the perception is different for everyone... so I dare say it is one of the problems which can not be solved in a one-size-fits-all algorithm... you might need to conduct extensive studies with thousands of different people, artists and non-artists and analyze their perception with extensive tests(of whatever yet to be determined scope and content) and then present a dialog with a hundred or two-hundred different sliders to configure the yet-to-be-found algorithm with the parameters of their individual perception... so yeah... if you have the time and dedication... go ahead, I'll pass). Going out of the 0-255 boundary is not a problem in my algorithm because the adjustments I make are not linear but based on the distance of the component towards either extreme of the number value range. I still cap it in the end which would theoretically be unnecessary because the formula makes it impossible for a value to go out of that range, I only cap to counter potential rounding errors in the floating point unit.

@Helm:
It can be used for some pretty extreme modifications as well, even change the perceived time of day or environment effects. 
The magic black-rock-mountain apocalypse is upon us! (color balance and some additional palette entry modification)


(Seems like there is a cut in the sky above where the axe rests in the stump.)


editI just compared this to Photoshop(CS2, that leaked "free" version from a while back) a bit and I have found that what the plugin does is actually more comparable to the output of what Photoshop calls the "channel mixer" while "color balance" in Photoshop seems to do something completely different (in both cases with or without preserve luminosity checked). For me, this is not a problem, as I find the output of the plugin predictable whereas when I drag around the sliders in the Photoshop color balance dialog, I can not imagine accurately what the output will end up like. So their idea/algorithm of "color balancing" must be very different from mine.

[Ai]

@DawnBringer and @Ai:
Like I said, I leave it to the eyes and hands of the artist to decide what they want and theoretically, solving the equations I gave earlier (in whatever way: like I pointed out there is no obvious unique solution because the equation system that needs to be solved has more unknowns than number of equations and modifying the unknowns modifies the original tint (so the cost of preserving the brightness for brightness sake would come at the cost of losing the base color) either for each component modification sequentially or for all of them after fully applying all modifications, is the FULL description of the problem of brightness(relative luminance) preservation that needs solving if one wants to do that.

Yes, that's a hard problem.

An easy problem (in terms of improving output quality) is to correctly remove gamma companding from the RGB values before performing the adjustment, and re-applying gamma companding afterwards. A quick-and-dirty* way of doing this (given RGB values in range 0..1), is to calculate

channel = pow(channel, 2.2); for each channel, then perform the adjustment, then apply adjustedchannel = pow(adjustedchannel, 1/2.2).

(this is what DB was alluding to with "Brightness is exponential in nature, so when color-balancing you need to adjust for this to maintain the pereceptual brightness level. ")

Helm does have a point that for small adjustments, <5%, the mathematical errors caused by not doing this don't impact the quality of the output a lot, though.

* 'quick-and-dirty' because sRGB companding is actually a piecewise function with linear and gamma 2.4 segments, but gamma=2.2 is generally considered an acceptable approximation of the overall response curve.

There are colorspaces that do a better job of preserving brightness relationships than RGB or CMYK -- LAB was specifically designed for this, and achieves it to a reasonable extent -- but I suppose that's OT.

[0xDB]

An easy problem (in terms of improving output quality) is to...

Not to be particularly argumentative/defensive but if the algorithm is changed then, of course, the output also changes. One can however not make any statement about the "quality" of the output when comparing two algorithms which each attempt to reach different results.

Specific to this case: It might be possible to compare two different algorithms which both try to preserve the brightness(in two different ways) to each other in terms of quality (which still is subjective and different for everyones perception) but it is not possible to make a generalized quality statement (saying x is better than y) between an algorithm which tries to preserve brightness and one which does not try to do that at all because which result(each arrived at under a different premise) is "better/has higher quality" in an apples vs. oranges scenario like that depends entirely on the result the artist is trying to achieve and on their personal preference.

If there is genuine demand for it, I can implement a variation to the algorithm which factors in/out the gamma-companding as you just described it but unless I am missing something, that would still not preserve the relative luminance in the output because the other equations would not change, they would only evaluate to different results. The modified brightness would still be different from the brightness before the modification and the equations would still need to be solved (and that would still modify the base color or the intermediate color if looking at it sequentially after each component/channel modification, so while one might preserve the relative luminance, the original color would still be lost in the process and the resulting color becomes unpredictable, even can end up looking like a glitch, like a completely different color than original-but-with-modified-tint in which case preserving the brightness is most likely not what the artist wants because then parts of the result jump out as "errors", leading to a tint that the artist does not want there, despite being mathematically "correct"(according to any brightness formula) when only looking at the isolated brightness / I think this is even related to the phenomenon that people often mix up tint/value when judging brightness).

In summary:
I do believe that I have a solid understanding of the definition of the problem (the FULL problem and not less than HALF of it (I really hate that "young Padawan" comment... just saying this explicitly again in case that still is not obvious yet) and I have, as already explained, good reasons for not trying to solve it. I believe it is a problem that should not be solved by any "color balancing" algorithm but rather be dealt with in a separate step (because it actually is a different problem-domain... maybe that it why it seems hard to solve in the first place because everyone tries to solve it as part of the wrong problem-domain while it actually is a separate issue (one can only speculate why Photoshop combines these two issues into the same dialog)) by manually adjusting contrast, saturation and brightness for the whole image AFTER changing the color channels in the palette as it can not accurately be solved by only looking at individual color triplets and needs to take into consideration each pixel/cluster/area in its context within the image (to do that one would also need to have a way of detecting objects in a scene). I will gladly leave that as an exercise to the highly paid specialists at Adobe or other digital imagery scientists and biologists who spend their lives researching color spaces and human perception. I have no illusions of being able to do this myself without putting in years of research (and I do not intend to do so as I have other interests in life).

[Ai]

An easy problem (in terms of improving output quality) is to...

Not to be particularly argumentative/defensive but if the algorithm is changed then, of course, the output also changes. One can however not make any statement about the "quality" of the output when comparing two algorithms which each attempt to reach different results.

No, in the case I describe, doing the math without removing the gamma companding means you are using incorrect terms in your calculation. It's equivalent to adding two values on a logarithmic scale together and expecting the result to make sense on a linear scale.
It's extremely common to fail to remove gamma companding, because you can often get away with it. But there is no reasonable argument that the output can be consistently better quality (by anyone's standards).

To put it another way:
Handling the companding attempts to maintain relationships between channel intensities in a minimal way.
Not handling the companding actively mangles relationships between colors.

It's all about how sRGB is an encoding, not a linear scale. Failing to decode the data before manipulating it equals wrong math.

Since I haven't seen the source, I can't guarantee that you don't account for gamma companding. But, since your reply wasn't "I'm already doing that!", I guess you probably aren't doing it.

'Young padawan' was uttered by DB. I think it's silly too, don't attribute it to me.

[0xDB]

I do not attribute it to you but I am under the impression you are missing the point of my post.

Which math is the "correct" math depends on what the intended result is. There is no "fail" in not doing something if not doing something is exactly in line with the intended result.

To me, it is obvious since a couple of posts ago, that we each, you, me and DawnBringer have different things in mind(this is what is causing the communication problem here) of which we unfortunately think under the same term "color balance".

Look back at the very beginning of the thread:

The theory is very simple - when you're adding +2 to red in the middle part of the values, if it finds a 20,20,20 color (a gray) it's going to make it 22,20,20, so from a gray it is now a gray-with-a-bit-more-red. If you take it really easy with this process, you can get an environmental effect, something like a soft bloom to work even for your pixel art.

So the premise was that we were looking for an algorithm that changes a neutral color like gray in a way that it gets tinted towards something else, so that it would end up not being that perfectly neutral gray.

The thread title says "color balancing" your pixel art. What you and DawnBringer have in mind is more like what "color balancing" is as described on Wikipedia, something that aims to keep neutral colors like gray neutral. That is also what I believe Photoshop attempts (the brightness preservation is a separate problem in any case regardless of the idea of what "color balancing" should encompass).

So "color balancing" here for the given premise could also be called "tint adjustment" or "channel mixing"(Photoshop has an option named like that as well and the results of that are comparable to what I implemented).

The algorithm I implemented is correct as it does exactly what it aimed to do, to make the tint adjustments as described in the opening post. It does not "fail" to take into account anything (I will not repeat my reasons for not even trying to preserve the brightness).

It probably should not be called "color balancing" though as that term seems to describe something other than what is described in the opening post. I guess I should rename it to "tint adjustment" plugin to avoid any confusion that might arise from what appears to be the commonly accepted idea of "color balancing" which is something different from what this does.

[DawnBringer]

Maybe this will make it clear; this is what my Grafx2 colorbalancing script will produce when adding 255 red in three different modes: basic add, loose brightness preservation and strict brightness preservation.

[Ai]

Which math is the "correct" math depends on what the intended result is. There is no "fail" in not doing something if not doing something is exactly in line with the intended result.

If you actively intend to modify the balance by variable amounts per unit of change, then of course this is true.
I'm not sure why you would intend to do that, though.

The thread title says "color balancing" your pixel art. What you and DawnBringer have in mind is more like what "color balancing" is as described on Wikipedia, something that aims to keep neutral colors like gray neutral. That is also what I believe Photoshop attempts (the brightness preservation is a separate problem in any case regardless of the idea of what "color balancing" should encompass).

I'm not sure what DawnBringers idea of color balance is.
But I don't even have one here other than 'arithmetic operation that modifies color channels'. I'm not that familiar with details of color balancing algorithms, I just know that using wrong data leads to wrong results, and treating encoded data as if it's decoded is using wrong data. That's all that the gamma companding comment is about. It's a factor that is involved in any operation that alters RGB channels in any mathematical way, whether this is compositing, hue/sat/val adjustments,  'color balance', inversion, randomization, decimation(scaling down) or interpolation. For example, Eric Brasseur demonstrates the way that failing to account for gamma companding destroys and distorts image content when scaling down images.
The only way to not be affected by gamma companding when using standard sRGB images, is to not do arithmetic on channel values.

[0xDB]

Maybe this will make it clear;

Please, please, immediately stop keeping to imply that it is not clear what you are talking about. It already was/is perfectly clear and I already told you that my implementation does not attempt to preserve the brightness, so there is nothing I can show you which could be compared to either of your brightness preservation strategies.

All I can show you is what my implementation does for +1.0 on R in the "All" tone range which is comparable to what your basic, non-brightness-preserving mode does.

Here you go:


The algorithm is simple (Ai, it is not taking into consideration any gamma companding except if we assume a linear gamma "curve") and straightforward (I described it a couple of pages ago), changing the tint of every palette entry (if it falls into the selected tone range):

Each slider value is normalized to the interval [-1.0, +1.0] while each component stays in the [0, 255](integral steps) interval.

And the adjustment, in pseudo code for a single component is this:
if sliderValue < 0.0
  newComponent = oldComponent + sliderValue * oldComponent
else
  newComponent = oldComponent + sliderValue * (255.0 - oldComponent)

It is not wrong. It does what it intends to do, changing the tint according to slider values as initially described. There is no attempt being made there to preserve the brightness. A black (which is the same as a uniform "gray" 0,0,0) gets tinted to a full red if the red slider is +1.0.

To me, this discussion feels a bit like I implemented a rectangle tool which draws perfect rectangles and you keep pointing out how the output of my rectangle tool does not look like circles and like you are implying that I do not know what a circle looks like whereas I never even intended to have my rectangle tool draw circles. Frankly, this upsets me. A lot. My obsessive compulsive trait forces me to keep explaining this shit until harmony is restored. Because I care but I should probably just walk away or try to implement brightness preservation so that we could actually start comparing things. But as it is, we really can not because metaphorically speaking "a rectangle is not a circle".

[RAV]

Thanks for your good work, Dennis. Thanks everyone for sharing your insights on the general topic. It's been "illuminating" on the issue. =p

Advanced colour features have been further down my to-do list so far, but I looked into it a bit more lately myself, and it's fun stuff to explore.

[DawnBringer]

Please, please, immediately stop keeping to imply that it is not clear what you are talking about.

So you actually think that I took precious time, not to clarify an issue where I perceived you to be a bit off, but just to belittle you!?

Ok, I won't bother you with any more insights and let you get back to your rectangles...

[0xDB]

Thanks RAV, I think it is interesting as well.

So you actually think that I took precious time, not to clarify an issue where I perceived you to be a bit off, but just to belittle you!?

Apology accepted.

Meanwhile I have spent the last couple of hours inventing and then implementing a brightness preservation strategy. It is not free of visual glitches in some slider configurations and highly unlikely to be as sophisticated as in professional imaging software but the output is decent.

Here is a link to v20150228 of the plugin for all Pro Motion users who would like to play with it. The brightness preservation attempt is activated by default and the old behavior can be activated by unchecking the entry in the command menu.

It also tries to preserve as much of the original tint as possible unless one explicitly "drags that out".

It does all of that without taking into consideration the different weight of perceptual brightness in different components (R, G and B) and also without calculating in and out compressions from any non-linear gamma curve. I do not have a solution for either of those problems.

It does calculate in the weight of different components when determining the brightness before and after all components are modified but not between individual component modification as I still can not solve those other equations and then the resulting brightness is adjusted by the ratio between old and new brightness by scaling each component in the result by the same factor (which is incorrect but it seemed like taking the weight into consideration caused more glitches and I am tired so I did not try to factor the weight in correctly for each component in the final brightness adjustment after modifications... might try to get back to that when I am well rested).

But enough with the words, here is an image (all modifications applied to the "All" tone range):

First is the unmodified sample image provided by DawnBringer.
Second is my algorithm without attempting to preserve brightness (+1 0 0).
Third is my algorithm while trying to preserve brightness and as much of the original tint as possible (+1 0 0).
Fourth is my algorithm while trying to preserve brightness but with green and blue "dragged out" (+1 -1 -1).
And fifth is the same as fourth but afterwards yanking up the Saturation by 33% using the Palette Editor in Pro Motion.



edit/append:
And here is an output where all 12 sliders (3 per range "lows" "mediums" "heights" and "all") are configured simultaneously like this:
(+1 -1 -1) (+1 -1 -1) (+1 -1 -1) (+1 0 0)

[Scuba Steve]

I really like this idea.

[0xDB]

Okay, today while I was not as dead-tired as when I wrote v20150228, I made some fixes and also added gamma companding now because I wanted to see if it has a big impact on the result (I have to look really closely to see the difference in the output but it is definitely there and maybe is more obvious for source images where the local brightness changes are more "steep").

Pro Motion Color Balance Plugin v201503b

change history

Code: [Select]

v201503b fixed a small value error in non-All range calculations caused by releasing too fast
v201503a fixed visual glitches caused by a += where a = should have been in the code
         fixed visual glitches caused from negative slider values being weighted incorrectly in the calculations
         color component alterations and brightness calculations are now performed respecting gamma companding (when the brightness preservation strategy is activated)

v20150228 implementent an optional rudimentary brightness preservation strategy
          (is active by default, old behavior can be set by unchecking the mark in the command menu)
          (it is not free of glitches and probably not very sophisticated)

v20150224 initial version

Comparison shots (slider values for the "All" tone range).

previous version v20150228 (no gamma companding):


v201503a (wide image is wide!):
Unmodifed DawnBringer sample / no brightness preservation (+1 0 0) / bp (+1 0 0) / bp (+1 -1 -1) / bp (+1 0 0) x 2 / bp (+1 0 0) x 3


Thank you Ai for bringing up gamma companding and thank you DawnBringer(even though I really did not like the tone in which you did so but maybe you really had no intention to be an ass) for keeping to go on about brightness preservation which caused me to make an attempt at doing so myself. Without those comments (which really felt like insults to me, maybe I am a little oversensitive) this version (and I like these different outputs a lot as they allow huge tint manipulations which are not manually possible without calculated brightness preservation) would not exist. (Of course this is not meant as an invitation to intentionally insult me in the future just so that I would make stuff.)

Not to boast but I even like the output of this latest version better than what the color balancing dialog in Photoshop(CS2) produces.

edit updated to 201503b (in case anyone already dloaded version a (should get sleep it is late again))

[Ai]

Yeah, I agree, the brightness preservation is working quite well. Definitely outclasses GIMP (though I haven't tried the newer 2.9 version, it's too slow to be practical):

Gamma handling generally will have the least effect on continuous-tone images like these IME -- changes in intensity relationships are far more obvious when you have only a few unique, contrasting colors (like pixel art in general). So yes, steep changes.

[Helm]

Dang so this is even better now! You're a superhero 

[Friend]

personally I discovered I could improve balancing when I stopped using gimp with all of its sliders and curves and other tools.  I guess it is somewhat intuitive, since I feel pixel art technique is improved when you stay within very restricted tools. To me , all of the options and index sliders for color balancing just pixels  devolves into an obsessive process that forgets the figurative bigger picture.  I think it can be helpful, for instance to boost some saturation or change hue in a snap to immediately alter the mood from say lively to grungey.  Overall though, I feel if this was necessary, an error was made in the beggining stages, akin to progressing with a piece that has poor anatomy.  I agree with Dawnbringer that RGB sliders are perfect;  the pixel art tool equivalent to say your bucket fills and line tools.  It's obviously not about discovering that "perfect shade or value", but rather just how the colors harmonize, and rgb sliders and no more work for this mentality.

  what I love about grafx2 is a new piece will automatically have a wide range of colors in the menu to choose from right off the bat.  It's very easy to pick the base color by eyeballing and selecting one of these colors and I don't have to worry about focusing on anything but how the colors I choose play rather than tweaking endlessly.  Then the rgb sliders just help me think of the colors as you would with a handful of real life pigments, rather than the thousands of colors drawn in digital painting, and the million colors implied in color index tools.  Once I already become content with the colors I manually harmonized, then the sliders are a good way to refine.  That's how I see all pixel art processes.  Make dirty > make dirty work > make dirty pretty.

I also like the rethinking of the concept of hue shifting. Hue shifts in ramps should receive much of the attention in terms of how shifts in hues harmonize not just the ramp it's on, but to the piece as a whole.  Simply having a base color  and doing the method of " increase value and make yellower or decrease value make bluer" is not a good approach to those seeking more "magic" to their colors in pixel art. I suppose this approach isn't optimal simply because you can't mix pixels exactly like you can paint, and does not consider how colors and ramps flow more organically into each other.  It also just leads to unoriginal colors to beginners.. The Crimson Reds, the oranges, sunflower yellows and deep purples beginners choose often when learning hue shifting begin to get old and unexpressive quickly.  I find a lot to learn in how Helm, Adarias, Dawnbringer and Jinn select colors.  Regardless of the methods used, an end result I often see is surprisingly outlandish color combinations,  and blending (as well as smoothing with good understanding of neutralization and balancel) which actually evoke how artists translate real life nature to canvas  painting- there's a quote that says to throw more red in your stem and throw more green in your rose to make it sing in harmony."  What I see in these great pixel artists is this sort of mentality translated seamlessly to pixels by way of refined color choices, but also just good pixel technique.  I think this is where hue shifting necessitates the utmost care, since the goal is a small palette, and again pixels can't blend as infinitely as paints. . The more ramps can link and intercept (maybe ramp blocks could include the same ramp jutting from multiple areas to demonstrate this), the more open is the door to combine and harmonize colors in outlandish, yet entirely more organic ways. 

In summary, I think an aid is to actually REMOVE  the training wheels of index sliders, or at least develop a process in which you can think more about organic, inter- hue play and ramp connectedness.
 I think a goal to achieve by pixel artists is somewhat to understand how it can be possible to translate an organic harmonizing of hues to a small number of colors that can not mix like real paint.  Perhaps at once it is not only about trying to simplify the process into the restrictions of pixels, but to understand deeper the complexities of color, so that the artist can learn how to tweak the process to fit into said restrictions.

[Helm]

See, you put me in a group there with other artists whose work - although I respect it - I find their choice of colors is tacky, just a bit random, or it was at least, in the past (artists grow). I don't want to speak ill of fellow artists, it's just to say that this is *exactly* what I want to move away from, if this is how it's percieved from people on the outside, to be part of that group of people who use huge jumps in hue to see if they can make them work. We can. We've done it for 10 years. Proper artists have been doing it for god knows how many decades. So what's next? Some cohesion, perhaps? A symbolic language of color? Something more involved than putting the green from the shoes as a buffer in the skin.

It's this preciousness about control & maximization of utility of every SINGULAR thing that drives pixel artists into making choices that holistically aren't attractive to me - but it just might only be me, so 

[0xDB]

From zilch to hero to superhero in a couple of days, heh, feels good to have one's work appreciated. 

I am very guilty of choosing different hues for different light/shadow situations just for the sake of looks kinda cool/magical/"advanced" in my old Pixel Art. So far I only produced a single piece of Pixel Art where I actively made the decisions for the colors based on the emotions and ideas that I wanted to express (of which I became aware in Ergotherapy in 2013 (before that I was completely unaware that colors have so many different connotations to them (except for some obvious blue=cold, red=warm, green=sick stuff), especially for connections between color and different states of mind/emotions/feelings).

Spoiler

made proper website for plugin and informed cosmigo by email of its existence as suggested by ptoing earlier

[rikfuzz]

their choice of colors is tacky

That was so amusingly unnecessary.

[Friend]

See, you put me in a group there with other artists whose work - although I respect it - I find their choice of colors is tacky, just a bit random, or it was at least, in the past (artists grow). I don't want to speak ill of fellow artists, it's just to say that this is *exactly* what I want to move away from, if this is how it's percieved from people on the outside, to be part of that group of people who use huge jumps in hue to see if they can make them work. We can. We've done it for 10 years. Proper artists have been doing it for god knows how many decades. So what's next? Some cohesion, perhaps? A symbolic language of color? Something more involved than putting the green from the shoes as a buffer in the skin.

It's this preciousness about control & maximization of utility of every SINGULAR thing that drives pixel artists into making choices that holistically aren't attractive to me - but it just might only be me, so 

I can begin to understand your view. But I dnot necessarily mean the strange jumps in hue to the extent where it becomes random. I don't think there are many artists here who wouldn't agree the artists I named have a more attuned sense of color. Yes as you say there are errors create in advanced techniques, but I would still classify the color demonstrated by these artists as advanced and I'm sure most would agree.

Again I can see your perspective, and sorry if you took offense to being included.  I'm more referring to an indescribable magic of color usage these artists cultivate. I do seriously believe the ability to combine hues more organically is a big part of it.

Anyway I'm super curious to read more of your persoective :]

[Helm]

their choice of colors is tacky

That was so amusingly unnecessary.

Be fair, I qualified it further than that.

[32]

Using the proverbial shoe green in the skin ramp isn't what makes this latest piece interesting to me. I'm liking the way you're using multiple ramps to describe a single material, it's not as simple as, the wood has these colours in it and this is the light one this is the middle one and this is the bright one. You're throwing in some alternate mid tones and shadows that could be all described tonally by a single colour. Certainly evident in some of your other work but stepping to the fore a bit more here. Colour for colours sake is a rarity in pixel art I'm realising, probably cause we're always pushing so hard for low colour counts.

Also awesome work Dennis another reason I have to get ProMotion.