Let's take it for granted that there are multiple contrast-adjusting functions.
Some that I can think of:
1. manual, parameterized contrast-enhancing (just rescale values around a pivot
-- the average? or an option for manually specifying the pivot?)
2. automatic stretching by remapping the old range to a new min/max/average (I
don't think this needs a full histogram, just collecting min/max/average).
3. true histogram equalization -- fully automatic remapping to [0,1] with
equalized histogram?
4. tone mapping -- some conversion of HDR to [0,1] in a perceptually pleasing
way (I think they tend to use some kind of local histogram equalization, but
I'm not up to date on what people consider the best tone mapping algorithm
these days).
Let's not get too hung up on the names for these quite at this time. And we
don't have to implement them all (now, or ever). I'm hoping that somebody more
familiar with the issue could give us a suggestion about which would be most
useful, and for those what the preferred formulas would be.
I do know that we need to know how to handle all the corner cases -- for
example, what happens if a particular pixel, in your formula below, happens to
have a low enough value that (in - average) * contrast < 0 ??
Please look at the final version of the over() declaration in imagebufalgo.h
(where I added comments and a little bit of cleanup to your code). I will
reproduce it below for those who don't want to go check out branches. The
function prototype and English text description is what I mean by a
"specification" -- a completely detailed description of what the function does,
basically a fully spelled-out contract between you and the caller that should
give people enough information to predict how it will act in any situation,
without having to read and understand the code line by line. (Note: in this
case I did not go into detail about the underlying math, but only because I
said it used the "Porter/Duff" definition. If there were not an unambiguous
understanding, the proper thing would be to explain the math, if it could be
described succinctly.)
I'd like to see (and achieve consensus on) the specification for 'contrast'
(and indeed, for every operation you work on), before getting as far as a pull
request for the code. I think that will help us hash out what the code should
do, before introducing the confusion of actually examining the code. It wasn't
so necessary for 'over', but for many operations (including contrast), you will
need to explicitly describe what should happen for pixels in which the input or
output values are not in the 0-1 range. It's ok to have operations that are
meaningless in such cases, but that should be clear in the "contract" and we
should all agree that there isn't a way to fix it to be robust to HDR and/or
negative pixels.
--
Specification for "over":
/// Set R to the composite of A over B using the Porter/Duff definition
/// of "over", returning true upon success and false for any of a
/// variety of failures (as described below). All three buffers must
/// have 'float' pixel data type.
///
/// A and B must have valid alpha channels identified by their ImageSpec
/// alpha_channel field, with the following two exceptions: (a) a
/// 3-channel image with no identified alpha will be assumed to be RGB,
/// alpha == 1.0; (b) a 4-channel image with no identified alpha will be
/// assumed to be RGBA with alpha in channel [3]. If A or B do not have
/// alpha channels (as determined by those rules) or if the number of
/// non-alpha channels do not match between A and B, over() will fail,
/// returning false.
///
/// If R is not already an initialized ImageBuf, it will be sized to
/// encompass the minimal rectangular pixel region containing the union
/// of the defined pixels of A and B, and with a number of channels
/// equal to the number of non-alpha channels of A and B, plus an alpha
/// channel. However, if R is already initialized, it will not be
/// resized, and the "over" operation will apply to its existing pixel
/// data window. In this case, R must have an alpha channel designated
/// and must have the same number of non-alpha channels as A and B,
/// otherwise it will fail, returning false.
///
/// 'roi' specifies the region of R's pixels which will be computed;
/// existing pixels outside this range will not be altered. If not
/// specified, the default ROI value will be interpreted as a request to
/// apply "A over B" to the entire region of R's pixel data.
///
/// A, B, and R need not perfectly overlap in their pixel data windows;
/// pixel values of A or B that are outside their respective pixel data
/// window will be treated as having "zero" (0,0,0...) value.
///
/// threads == 0, the default, indicates that over() should use as many
/// CPU threads as are specified by the global OIIO "threads" attribute.
/// Note that this is not a guarantee, for example, the implementation
/// may choose to spawn fewer threads for images too small to make a
/// large number of threads to be worthwhile. Values of threads > 0 are
/// a request for that specific number of threads, with threads == 1
/// guaranteed to not spawn additional threads (this is especially
/// useful if over() is being called from one thread of an
/// already-multithreaded program).
bool DLLPUBLIC over (ImageBuf &R, const ImageBuf &A, const ImageBuf &B,
ROI roi = ROI(), int threads = 0);
On Jul 2, 2012, at 6:56 AM, Stefan Stavrev wrote:
> We can have both. The contrast algorithm for color images is:
>
> 1. RGB -> HSI.
> 2. Apply histogram equalization to I.
> 3. HSI -> RGB.
>
> Step 2 can be replaced by another contrast modification algorithm that does
> take parameters, unlike histogram equalization.
>
> The only question left is, which contrast formula do we use:
>
> 1. out = (in - average) * contrast + average
> 2. out = pow(in * pow(pivot, 1.0 / contrast - 1.0), contrast)
>
> I have tested 1) for grayscale and color images and it is not bad, gives good
> results. Malcolm's formula 2) is probably better, but have not tried it.
>
> Chris I would suggest we transfer the contrast conversation in the "Contrast"
> topic started. Also, the contrast algorithm will need color space
> conversions, for which I don't know yet if I should write them or maybe I
> could use something already existing. Not sure if Jeremy has those in
> OpenColorIO. On the other hand I think we can merge the histogram functions
> in few day, they are really very simple.
>
> Stefan
>
>
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
