On Fri, Jun 22, 2012 at 2:10 PM, Stefan Stavrev <[email protected]> wrote: > 1. "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?" > > Eh, please ignore details for now. I don't know yet how will I deal with > ranges. I just wanted to show you guys that the math is really simple. But > very good questions, we will have to deal with this yes. >
Cool, no worries. In that case, I have no problem with the basic concept of what you are proposing as a contrast function. It looks perfectly correct. That's why I jumped straight to questions about the other stuff. :) > 2. "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?" > > I vote not to allow this, since it makes sense only to apply contrast to a > grayscale image or color image. It is strange applying this operation to a > channel I know it is alpha or z. I know compositors will apply all sorts of color manipulations to "utility" channels. Adjusting contrast of an alpha channel is often used for making edges look harder/softer. Color manipulations on Z channels are also pretty common. A contrast function on Z buffers is effectively a geometric scaling in the scene along the camera Z axis. To be fair, I usually never see somebody who wants the same transform applied to visible channels and utility channels. It's generally one or the other, but applying manipulations to non-visible channels, however "impure" or undefined, is often very useful. > > 3. "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?" > > Nope, I said "a color image has exactly 3 non-alpha and non-z channels". > Well, okay, I misquoted the phrasing, but you are still saying that there are "exactly 3." That's what I was referring to. > 4. Your proposal for channel masks will require significant changes I think. > I am afraid I can't make such big decisions, it depends if you guys agree on > such thing I will do it. Honestly I am against it, it will complicate things > so so much. > Honestly, I'm not even sure if something similar may already exist in OIIO. I have to admit, I've never found the time to familiarize myself with the internals the way I had hoped. My own use of the API barely scratches the surface. The idea of channel masks is inspired a bit by Nuke. In Nuke, you have checkboxes for which channels you want a filter to effect, so you can blue only red and blue, but leave green and alpha alone. Then adjust the brightness of just blue and alpha, etc. It's very flexible. (Though, Nuke thinks in terms of layers of only up to 4 channels, with an arbitrary number of layers. OIIO seems to be slightly more flexible with handling arbitrary numbers of channels.) > 5. "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?" > > Again, we will handle these details later. I just wanted to show you guys > the math. > > Stefan > Looks good! _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
