Color balancing your pixel art

[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