The GIMP has a neat HSL adjustment tool that allows you to adjust the
Hue, Saturation and Lightness of either an entire image or one of six
color sub-channels (cyan, magenta and yellow are treated as additional
channels). I was wondering if anyone could help me by outlining methods
that would allow me to do the same with 2D sprites and mesh textures in
SDL. The routine should be relatively fast, but does not need to be done
in real time. There should also be an option to only work on images in
memory or to render the result to a file. Thanks ahead of time for any
replies!
The GIMP has a neat HSL adjustment tool that allows you to adjust the
Hue, Saturation and Lightness of either an entire image or one of six
color sub-channels (cyan, magenta and yellow are treated as additional
channels). I was wondering if anyone could help me by outlining methods
that would allow me to do the same with 2D sprites and mesh textures in
SDL. The routine should be relatively fast, but does not need to be done
in real time. There should also be an option to only work on images in
memory or to render the result to a file. Thanks ahead of time for any
replies!
-Mike
BTW, the project is coded/compiled in FreePascal, and uses the Jedi-SDL
wrapper. More information about the project can be found here:
An important thing you should note is that with most pixel formats,
you will lose data every time you transform a color using the
transformation techniques you describe. Here is some help to get you
started:
The GIMP has a neat HSL adjustment tool that allows you to adjust the Hue,
Saturation and Lightness of either an entire image or one of six color
sub-channels (cyan, magenta and yellow are treated as additional channels).
I was wondering if anyone could help me by outlining methods that would
allow me to do the same with 2D sprites and mesh textures in SDL. The
routine should be relatively fast, but does not need to be done in real
time. There should also be an option to only work on images in memory or to
render the result to a file. Thanks ahead of time for any replies!
Donny Viszneki wrote:> On Fri, Feb 13, 2009 at 2:02 AM, SharkD <@SharkD> wrote:
The GIMP has a neat HSL adjustment tool that allows you to adjust the Hue,
Saturation and Lightness of either an entire image or one of six color
sub-channels (cyan, magenta and yellow are treated as additional channels).
I was wondering if anyone could help me by outlining methods that would
allow me to do the same with 2D sprites and mesh textures in SDL. The
routine should be relatively fast, but does not need to be done in real
time. There should also be an option to only work on images in memory or to
render the result to a file. Thanks ahead of time for any replies!
An important thing you should note is that with most pixel formats,
you will lose data every time you transform a color using the
transformation techniques you describe. Here is some help to get you
started:
I’m not concerned with “losing” small amounts of data. The method is
intended for giving game units “user defined” or “faction” color schemes
on the fly. The source images will of course remain unaltered.
An important thing you should note is that with most pixel formats,
you will lose data every time you transform a color using the
transformation techniques you describe. Here is some help to get you
started:
'm not concerned with “losing” small amounts of data. The method is intended for giving game units “user defined” or “faction” color schemes on the fly. The source images will of course remain unaltered.
Yeah, that’ll be fine. HSL conversion is like JPEG compression: you really only notice losing data if you do it to the same image repeatedly. CMYK, on the other hand, can make things really ugly after one pass if you’ve got a lot of out-of-gamut colors in your sprite. Be careful with that one.>----- Original Message ----
From: SharkD
Subject: Re: [SDL] Color value substitution
Are you sure you need to mess with formats other than RGB for faction
colors? I just use RGB with a “reverse” colorkey method to do that, or if I
wanted smoother edges, I’d write my own function to work under the alpha.
HSL would be nicer and more intuitive for an in-game adjustment by the
player, but is there another reason you’d go this route?
Jonny DOn Sat, Feb 14, 2009 at 3:01 AM, SharkD wrote:
Donny Viszneki wrote:
On Fri, Feb 13, 2009 at 2:02 AM, SharkD wrote:
The GIMP has a neat HSL adjustment tool that allows you to adjust the
Hue,
Saturation and Lightness of either an entire image or one of six color
sub-channels (cyan, magenta and yellow are treated as additional
channels).
I was wondering if anyone could help me by outlining methods that would
allow me to do the same with 2D sprites and mesh textures in SDL. The
routine should be relatively fast, but does not need to be done in real
time. There should also be an option to only work on images in memory or
to
render the result to a file. Thanks ahead of time for any replies!
An important thing you should note is that with most pixel formats,
you will lose data every time you transform a color using the
transformation techniques you describe. Here is some help to get you
started:
I’m not concerned with “losing” small amounts of data. The method is
intended for giving game units “user defined” or “faction” color schemes on
the fly. The source images will of course remain unaltered.
Are you sure you need to mess with formats other than RGB for faction
colors? I just use RGB with a “reverse” colorkey method to do that, or
if I wanted smoother edges, I’d write my own function to work under the
alpha. HSL would be nicer and more intuitive for an in-game adjustment
by the player, but is there another reason you’d go this route?
Jonny D
I like the fact that The GIMP allows you to work with six color channels
at once. If this can be done without switching to HSL that would be
fine. The ability to use anti-aliasing/alpha-channel is also important.
I like the fact that The GIMP allows you to work with six color channels at
once.
They are not all orthogonal channels, however! HSL obviously is a bit
of a funny mapping compared to RGB. Throwing CMY channels into the mix
obviously makes it a big mess. But your point that it’s user-friendly
is a valid one
If this can be done without switching to HSL that would be fine. The
ability to use anti-aliasing/alpha-channel is also important.
What do you mean by “switching” to HSL? And this part about AA and
alpha blending is really out of left field. Why would this be
related to the color transforms you were asking us about?On Sun, Feb 15, 2009 at 10:21 PM, SharkD wrote:
I like the fact that The GIMP allows you to work with six color channels at
once.
They are not all orthogonal channels, however! HSL obviously is a bit
of a funny mapping compared to RGB. Throwing CMY channels into the mix
obviously makes it a big mess. But your point that it’s user-friendly
is a valid one
I don’t think The GIMP ever completely switches over to a different set
of color channels in the sense that CMYK is a completely different color
space. Rather, it just makes clever use of the existing RGB channels and
provides users with a bit of extra leverage in this regard.
If this can be done without switching to HSL that would be fine. The
ability to use anti-aliasing/alpha-channel is also important.
What do you mean by “switching” to HSL? And this part about AA and
alpha blending is really out of left field. Why would this be
related to the color transforms you were asking us about?
I understood the previous responses to mean/imply that HSL is somehow
mutually-exclusive to RGB. There are no HSL image formats as far as I
know, except for maybe Lab*. In any case, any transformations will be
transparent to the user and not worth worrying about.
-Mike> On Sun, Feb 15, 2009 at 10:21 PM, SharkD <@SharkD> wrote:
You can’t really calculate HSL transformations on RGB without just
converting between HSL and back. It’s fairly inexpensive. Maybe this
is what you meant by "clever use of the existing channels."On Sat, Feb 21, 2009 at 1:42 PM, SharkD wrote:
Donny Viszneki wrote:
They are not all orthogonal channels, however! HSL obviously is a bit
of a funny mapping compared to RGB. Throwing CMY channels into the mix
obviously makes it a big mess. But your point that it’s user-friendly
is a valid one
I don’t think The GIMP ever completely switches over to a different set of
color channels in the sense that CMYK is a completely different color space.
Rather, it just makes clever use of the existing RGB channels and provides
users with a bit of extra leverage in this regard.
Donny Viszneki wrote:> On Sat, Feb 21, 2009 at 1:42 PM, SharkD <@SharkD> wrote:
Donny Viszneki wrote:
They are not all orthogonal channels, however! HSL obviously is a bit
of a funny mapping compared to RGB. Throwing CMY channels into the mix
obviously makes it a big mess. But your point that it’s user-friendly
is a valid one
I don’t think The GIMP ever completely switches over to a different set of
color channels in the sense that CMYK is a completely different color space.
Rather, it just makes clever use of the existing RGB channels and provides
users with a bit of extra leverage in this regard.
You can’t really calculate HSL transformations on RGB without just
converting between HSL and back. It’s fairly inexpensive. Maybe this
is what you meant by “clever use of the existing channels.”
Actually I was referring to the CMY “channels” that were “thrown” into
the mix.
They are not all orthogonal channels, however! HSL obviously is a bit
of a funny mapping compared to RGB. Throwing CMY channels into the mix
obviously makes it a big mess. But your point that it’s user-friendly
is a valid one
I don’t think The GIMP ever completely switches over to a different set
of
color channels in the sense that CMYK is a completely different color
space.
Rather, it just makes clever use of the existing RGB channels and
provides
users with a bit of extra leverage in this regard.
You can’t really calculate HSL transformations on RGB without just
converting between HSL and back. It’s fairly inexpensive. Maybe this
is what you meant by “clever use of the existing channels.”
Actually I was referring to the CMY “channels” that were “thrown” into the
mix.
Well, that’s a little more similar to RGB, but nonetheless, the
statement “completely switches over to a different set of color
channels” doesn’t really have any meaning, as the color calculations
are still there, and trying to determine whether or not a "conversion"
takes place is like trying to nail jello to the wall.On Sat, Feb 21, 2009 at 11:44 PM, SharkD wrote:
You can’t really calculate HSL transformations on RGB without just
converting between HSL and back. It’s fairly inexpensive. Maybe this
is what you meant by “clever use of the existing channels.”
Actually I was referring to the CMY “channels” that were “thrown” into the
mix.
Well, that’s a little more similar to RGB, but nonetheless, the
statement “completely switches over to a different set of color
channels” doesn’t really have any meaning, as the color calculations
are still there, and trying to determine whether or not a "conversion"
takes place is like trying to nail jello to the wall.
There’s a distinction to draw, though. HSL maps 1:1 with RGB. There’s no color in one color space that can’t be converted accurately to the other with no loss of data. This is not true for CMYK, which has a much more restricted gamut because it’s based on a subtractive color model instead of an additive one. Try and convert a full-color image from RGB to CMYK, especially one with lots of bright colors, and you’ll end up losing data.>----- Original Message ----
From: Donny Viszneki <donny.viszneki at gmail.com>
Subject: Re: [SDL] Color value substitution
You can’t really calculate HSL transformations on RGB without just
converting between HSL and back. It’s fairly inexpensive. Maybe
this is what you meant by “clever use of the existing channels.”
Actually I was referring to the CMY “channels” that were "thrown"
into the mix.
Well, that’s a little more similar to RGB, but nonetheless, the
statement “completely switches over to a different set of color
channels” doesn’t really have any meaning, as the color calculations
are still there, and trying to determine whether or not a
"conversion" takes place is like trying to nail jello to the wall.
There’s a distinction to draw, though. HSL maps 1:1 with RGB.
There’s no color in one color space that can’t be converted
accurately to the other with no loss of data. This is not true for
CMYK, which has a much more restricted gamut because it’s based on a
subtractive color model instead of an additive one. Try and convert
a full-color image from RGB to CMYK, especially one with lots of
bright colors, and you’ll end up losing data.
Are you sure? I thought that it worked like this:
C = 1.0 - R
M = 1.0 - G
Y = 1.0 - B
K = min( C, M, Y )
C -= K
M -= K
Y -= K
There is no loss of data. All transormations that we used are
reversible. You can restore the original RGB with simple arithmetic.
The subtractive and additive colour models are pretty much equivalent.
In fact, if you use a CRT display, it works with the additive model
while your LCD display uses a subtractive one: the R, G and B pixels
are created by subtracting from the white backlight G and B for R, R
and G for B and R and B for G. Mind you, the so-called "white"
backlight itself is actually a result of an additive mix…
The CMYK instead of CMY space is used in printing simply because it is
technically quite hard to find C, M and Y dyes that generate a perfect
black. So, for the common part of C, M and Y (i.e. the gray component)
they use a proper black dye, which is both better and a lot cheaper. But
there is no inherent mathematical limitation in the colour space.
In real-life printing there are issues, as a real dye doesn’t subtract
but attenuates, it’s spectral curve is not really a narrow-band filter
and so on. To a degree the same thing applies to the RGB model, though
it’s much easier to create a monochromatic light than to make a filter
that passes everything evenly except one particular wavelength.
However, that’s only relevant to the actual physical materials we use,
not for the mathematical model as such.
you could use GEGL (http://gegl.org/) and BABL (http://gegl.org/babl/)
like Gimp does… you should be able to work with SDL surfaces
through babl.On Monday 23 Feb 2009 21:34:25 SharkD wrote:
Back on topic: how would I do this in SDL? I like The GIMP’s method
best, so I want to copy that exactly.
