Sent on the move...
On 2 Jul 2012, at 21:20, Stefan Stavrev stavrevste...@gmail.com wrote:
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
My recommendation for all of these ImageBugAlgo implementations
(contrast, histogram adjust, box filters, etc) is to completely ignore
color space.
I have reviewed the book referenced by Stefan, and I agree that it
makes a strong case that many image processing operations achieve
superior
Thanks for helping out Jeremy!
Just a small example to confirm I understand what you say:
Let's say that some algorithm needs hue and saturation. To achieve the
flexibility you talk about, I will need to keep anything color conversion
related outside of my functions. The documentation will say
Exactly!
So if your algorithm assumes an HSV like input, just note this super
explicitly in the documentation. (which channels each component is
in). And then leave it up to the user to perform the conversion.
Which algorithm, by the way, are you thinking of that requires hsv?
-- Jeremy
On
Jeremy, the box filter for color images I told you about needs hue and
saturation. I can't just apply the grayscale version of the box filter to
all channels independently, from what I have read it leads to bad results.
So I will have a general case where you can apply the grayscale box filter
to
Am I wrong to think that HSL (using some perceptual basis for getting luminance
from RGB) would be in all cases superior to ad-hoc HSV or HSI, which would not
have perceptually uniform brightness for all hues or saturations?
On Jul 3, 2012, at 11:44 AM, Stefan Stavrev wrote:
Jeremy, the box
This is more complicated than you think.
Do you really need to convert to HSL, manipulate, then convert back to RGB? Or
is enough to just be able to compute the luminance for each pixel and then do
scaling based on that? (Am I wrong to think that once you know the scaling
factor, you can
