On Jul 2, 2012, at 1:20 PM, Stefan Stavrev wrote:
> The box filter algorithm for color images works exclusively in HSI, it needs
> hue and saturation for each pixel. Other algorithms need only the luminance
> component as you said. I need separate functions for H, S and I, since
> sometimes you need some of them and not all. But for some spaces there is no
> escape from calculating one in order to calculate another.
Is HSI the same as HSL?
I understand that some algorithms will need to modify HSL individually. Am I
wrong in understanding that adjusting contrast can be done on the original
channels once you know the scale factor?
> There is no escape from this I am afraid, color image processing is
> completely different than grayscale image processing. Sometimes you can apply
> the same thing to all channels in RGB image as you would for a grayscale
> image, but the results are usually bad. So you want to go to other space such
> as HSI and get the job done.
Oh, and indeed it is possible that some IP algorithms make basically no sense
if the channels are not "RGB" and for those, it's fine to reject images that
aren't RGB/RGBA/gray, or to operate only on channels easily identifiable as RGB
and leave others untouched. I'm not sure if contrast adjustment is one of
those, or if it just boils down to linear scaling of all channels (in which
case you may as well not be very picky about what chose channels mean).
> I am talking about "conversion" only internally. The input image is still RGB
> and the output image is RGB.
I did understand. I'm just trying to see if you can simplify the math.
For example, if I said that I wanted everything twice as bright, you could do:
color3 hsl = rgb_to_hsl (pixel[0..2]); // basically a matrix multiply
hsl[2] *= 2.0;
pixel[0..2] = hsl_to_rgb (hsl); // basically a matrix multiply
or, you could realize that the following is equivalent:
pixel[0..2] *= 2.0; // just nchannels multiplies
Excuse my shorthand, I realize this is not valid C++. I'm just trying to get
to the concept that there may be simpler ways of doing some things if you know
they are just independent linear operations on the channels. Just because
something is expressible in terms of operations on channels after you convert
to HSL (or some other space), doesn't always mean that it's the simplest or
most efficient way of doing the operation.
> You mean it is complicated because conversion formulas are expensive, or lack
> of agreement in the whole color spaces thing? I mean, there is a lot of
> confusion about the color spaces, different names for things, different
> standards, I guess that is what you mean?
I mean that if you think the contrast() operation is to "adjust the luminance
range of the image", it begs the question of what the original channels *mean*
and how to compute luminance from them in the first place. You could use the
formula I have you (a common one) for a perceptual luminance metric, but if
you're going to be picky you should understand that the formula itself makes
some assumptions about exactly what R, G, and B mean and how they are encoded
(specifically, it assumes a linear encoding of the Rec709 color primaries).
You said, "give me the formula", and it's not that simple. Do we want to assume
a particular color space and encoding? Allow for others? Detect it
automatically?
--
Larry Gritz
l...@larrygritz.com
_______________________________________________
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
