Let's simplify and say its behavior is to "create UP TO n threads". Deciding
to create fewer -- either because there is some system limit, or the size of
the image is too small to justify that many threads -- is perfectly acceptable
behavior and not considered an error.
I'm not hugely against
What I am going after is to isolate the pure algorithm as one function,
from everything else like input validation and what not. Because later the
algorithms will get bigger and checking all the alpha and region cases in
different loops will lead to messy code. For now I will leave that as it
is, b
Nah, I'd say either accept the ambiguous cases, or reject them. I wouldn't go
down the path of "converting" the images.
Incidentally, you could turn the loops inside out. Instead of
for all pixels:
if (A has alpha and B has alpha)
R = A + A.alpha * B;
On Jun 13, 2012, at 10:38 AM, Stefan Stavrev wrote:
> I say let's do it "what you push is what you get". Don't assume anything. The
> input images must have same number of channels and alpha channel must be
> specified in same position. If the programmer, the user of OIIO, feels like
> handling
You think?
What are the relative probabilities of somebody asking you to composite two
CMYK images (or even *ever* seeing a CMYK image in the kind of environment
where somebody would be tempted to use "over"), versus being handed an RGBA
image that lacks the correct "TIFFExtraSamples" tag?
On Wed, Jun 13, 2012 at 10:03 AM, Larry Gritz wrote:
> (Exercise for the reader: under what circumstances, and for which formats,
> could you be SURE that a 4-channel image did not contain an alpha?)
>
A CMYK TIFF image?
That's clearly a corner case, but I guess if I had two cmyk tiff images an
Related to the previous message, how about we do include all these checks
and put all that code in a separate function as Larry suggested, but
instead of returning true or false, this function will modify the images.
If an alpha channel is missing and we assume it should have it, we will add
one. B
Giving all this a second look, I feel uncomfortable with all the alpha
assumptions. These functions will be used by programmers and they should
know to set the alpha channel properly. The functions are not intended for
users that will type something on command line and expect us to guess what
they
I see your point about not distinguishing between not knowing if there is an
alpha channel (and/or not knowing which one) versus a positive belief that
there is no alpha channel in the file -- alpha-agnosticism and alpha-atheism,
if you will. I would support a different constant to distinguish
On Thu, Jun 14, 2012 at 12:35 AM, Chris Foster wrote:
> As for the API, I like how the details have been fleshed out so far. I
> have one nitpick surrounding the assumed alpha stuff. It seems like the
> value of spec.alpha_channel can mean two distinct things:
By which I mean "a value of spec.a
Hi guys,
Thanks Larry for fielding Stefan's questions while I've been mostly out
of contact for the last few days. Good discussion.
As for the API, I like how the details have been fleshed out so far. I
have one nitpick surrounding the assumed alpha stuff. It seems like the
value of spec.alpha
11 matches
Mail list logo
