Taking a quick look at what you have posted, a few things come to mind.
Why do you want to clamp the result?
Why are you defining color in different terms from Luma?
For color, why are you defining it in terms of 8 bit int? I thought
the discussion of over basically led to the idea that everything
should be done in terms of 32 bit float, unless there was some
overwhelming reason that was incorrect.
For channel handling, is there any reason to care about what the
channels are? If somebody sends the function an alpha channel to
contrast, or a Z-depth image, why does that matter? In your previous
email, you said you were working with the assumption that a color
image has exactly 3 color channels. Why is that a useful
restriction/assumption? If we expect the user will supply channels
that they don't want effected, maybe we should just have a concept of
a channel mask object? That way if I have an odd image with "wide"
spectral color, and lots of aux like
Image( Red, Alpha, Z, Orange, Z2, Yellow, ID, Green, Blue, Indigo,
Violet, Temperature)
I can make a mask object like
ChannelMask(true, false, false, true, false, true, false, true, true,
true, false)
to pass to ImageBufAlgo's like Contrast. It would only operate on the
marked channels, without having to put intelligence into the algo.
Does OIIO have something like this already? I tend to think in
old-school terms, so I would probably just use bits in an int for this
sort of thing. Would we need more bits than that, or more complicated
behaviors or semantics? This would enable a simple idiom for algos in
the form of
foreach channel in channels:
if mask[channel]:
doAlgorithmOnChannel(channel)
This would provide a consistent set of knobs for a user of the API to
learn, and help enable consistent behavior.
Does it make sense for the center of the contast (the 128 in your
color example, would presumably be 0.5 in float) to be a user supplied
parameter?
Stefan, it looks great that you are forging ahead and making progress.
It's exciting to see so much forward movement in OIIO.
On Fri, Jun 22, 2012 at 12:47 PM, Stefan Stavrev
<[email protected]> wrote:
> Ah yes, sorry.
>
> This is the signature:
>
> ImageBufAlgo::contrast (ImageBuf &R, const ImageBuf &A, float contrast,
> ROI roi, int nthreads)
>
> and this is what it does for grayscale images:
>
> r[0] = clamp (a[0] * contrast, 0.0f, 1.0f);
>
> where r is iterator over R, and a over A. Dead simple.
>
> The algorithm for color images is:
>
> r = (r-128) * contrast + 128;
> g = (g-128) * contrast + 128;
> b = (b-128) * contrast + 128;
>
> This assumes we work with unsigned char in range 0-255, but
> I can remap to other range if needed.
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
