AuthorTopic: Color balancing your pixel art  (Read 28667 times)

Offline DawnBringer

  • 0001
  • *
  • Posts: 51
  • Karma: +0/-0
    • View Profile

Re: Color balancing your pixel art

Reply #30 on: February 26, 2015, 08:24:21 pm
@Dennis. Oh, young padawan...that's not even half of it.

Offline Helm

  • Moderator
  • 0110
  • *
  • Posts: 5159
  • Karma: +0/-0
    • View Profile
    • Asides-Bsides

Re: Color balancing your pixel art

Reply #31 on: February 26, 2015, 08:40:14 pm
It's not the half of what? Am I missing something?

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

Offline DawnBringer

  • 0001
  • *
  • Posts: 51
  • Karma: +0/-0
    • View Profile

Re: Color balancing your pixel art

Reply #32 on: February 26, 2015, 10:08:16 pm
@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.

Offline Helm

  • Moderator
  • 0110
  • *
  • Posts: 5159
  • Karma: +0/-0
    • View Profile
    • Asides-Bsides

Re: Color balancing your pixel art

Reply #33 on: February 26, 2015, 11:48:28 pm
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'.

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile

Re: Color balancing your pixel art

Reply #34 on: February 27, 2015, 12:11:50 am
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.
« Last Edit: February 27, 2015, 12:37:08 am by Ai »
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.

Offline 0xDB

  • 0011
  • **
  • Posts: 873
  • Karma: +0/-0
  • Dennis inter-is.
    • dennisbusch_de
    • http://pixeljoint.com/p/1287.htm
    • 0xdb
    • View Profile
    • 0xDB

Re: Color balancing your pixel art

Reply #35 on: February 27, 2015, 11:37:33 am
@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.  :crazy:
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.
« Last Edit: February 27, 2015, 12:27:53 pm by Dennis »

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile

Re: Color balancing your pixel art

Reply #36 on: February 27, 2015, 12:41:06 pm
@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.
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.

Offline 0xDB

  • 0011
  • **
  • Posts: 873
  • Karma: +0/-0
  • Dennis inter-is.
    • dennisbusch_de
    • http://pixeljoint.com/p/1287.htm
    • 0xdb
    • View Profile
    • 0xDB

Re: Color balancing your pixel art

Reply #37 on: February 27, 2015, 02:21:18 pm
Quote
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).

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile

Re: Color balancing your pixel art

Reply #38 on: February 27, 2015, 10:57:29 pm
Quote
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.
« Last Edit: February 27, 2015, 10:59:50 pm by Ai »
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.

Offline 0xDB

  • 0011
  • **
  • Posts: 873
  • Karma: +0/-0
  • Dennis inter-is.
    • dennisbusch_de
    • http://pixeljoint.com/p/1287.htm
    • 0xdb
    • View Profile
    • 0xDB

Re: Color balancing your pixel art

Reply #39 on: February 28, 2015, 01:24:30 am
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:
Quote from: Helm
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.