<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">
<blockquote type="cite">I have an ImgPlus backed by an RGB
PlanarImg of UnsignedByteType and ARGBType.alpha(value) is 255
for all of them, so aSum is 765. It would appear that the
correct solution would be to divide aSum by 3.</blockquote>
Isn't it unusual to define an alpha for each color component,
generally you have a single A associated with a combined RGB? So
averaging the three alphas might make sense here, because I think
they should all be the same value.<br>
<blockquote type="cite">In addition, there's no scaling of the
individual red, green and blue values by their channel's alpha.
If the input were two index-color images, each of which had
different alphas, the code should multiply the r, g and b values
by the alphas before summing and then divide by the total alpha
in the end. The alpha in this case *should* be the sum of alphas
divided by the number of channels.</blockquote>
I think alpha processing is more cumulative, done layer by layer
in some defined layer order. For a given pixel say the current
output pixel value is ARGB1 and you are compositing a second image
with value ARGB2 on top of it: For the red channel the output
color should be ((255 - alpha(ARGB2)) * red(ARGB1) + alpha(ARGB2)
* red(ARGB2)) / 255. The alpha of ARGB1 is not involved.<br>
<br>
In other words, if you add a layer that is completely opaque you
no longer have to consider any of the colors or alpha values
underneath it.<br>
<br>
<br>
I think the bigger issue here is this code is specifically
designed to composite red, green and blue image layers. It's a
special case since for a given pixel the red comes from the red
layer, blue from blue layer, and green from green layer. These
layers shouldn't be completely opaque, since the colors wouldn't
combine at all then or completely transparent since then they
wouldn't contribute any color. I don't think transparency is
useful here.<br>
<br>
It's also possible that a multichannel image with > 3 channels
is being displayed with more color channels, namely cyan, magenta,
and yellow. The code here is designed to stop overflow, but I'm
not convinced those extended color channels would combine
meaningfully.<br>
<br>
Aivar<br>
<br>
<blockquote type="cite">In addition, there's no scaling of the
individual red, green and blue values by their channel's alpha.
If the input were two index-color images, each of which had
different alphas, the code should multiply the r, g and b values
by the alphas before summing and then divide by the total alpha
in the end. The alpha in this case *should* be the sum of alphas
divided by the number of channels.</blockquote>
I think alpha processing is cumulative layer by layer. <br>
<br>
This brings up some interesting questions:<br>
<br>
1) If the first, bottom-most layer is transparent, what color
should show through? Black, white? Or perhaps it's best to
ignore this base layer transparency.<br>
<br>
2) If you wanted to composite several transparent images, how do
you calculate the transparency of the composite? I'm not sure
this is something we need to do.<br>
<br>
Aivar<br>
<br>
<br>
On 7/15/13 10:31 AM, Lee Kamentsky wrote:<br>
</div>
<blockquote
cite="mid:CAHLFyjeejg8JbidrZDyTqtLS1E7PPq=w5OU4iLmGpdox4PnP5Q@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
<div dir="ltr">
<div>Hi all, </div>
<div>I'm looking at the code for
net.imglib2.display.CompositeXYProjector and as I step through
it, it's clear that the alpha calculation isn't being handled
correctly. Here's the code as it stands now, line 190 roughly:</div>
<div><br>
</div>
<div><span class=""> </span>for ( int i = 0; i < size; i++ )</div>
<div><span class=""> </span>{</div>
<div><span class=""> </span>sourceRandomAccess.setPosition(
currentPositions[ i ], dimIndex );</div>
<div><span class=""> </span>currentConverters[ i ].convert(
sourceRandomAccess.get(), bi );</div>
<div><span class=""> </span>// accumulate converted result</div>
<div><span class=""> </span>final int value = bi.get();</div>
<div><span class=""> </span>final int a = ARGBType.alpha( value
);</div>
<div><span class=""> </span>final int r = ARGBType.red( value
);</div>
<div><span class=""> </span>final int g = ARGBType.green( value
);</div>
<div><span class=""> </span>final int b = ARGBType.blue( value
);</div>
<div><span class=""> </span>aSum += a;</div>
<div><span class=""> </span>rSum += r;</div>
<div><span class=""> </span>gSum += g;</div>
<div><span class=""> </span>bSum += b;</div>
<div><span class=""> </span>}</div>
<div><span class=""> </span>if ( aSum > 255 )</div>
<div><span class=""> </span>aSum = 255;</div>
<div><span class=""> </span>if ( rSum > 255 )</div>
<div><span class=""> </span>rSum = 255;</div>
<div>
<span class=""> </span>if ( gSum > 255 )</div>
<div><span class=""> </span>gSum = 255;</div>
<div><span class=""> </span>if ( bSum > 255 )</div>
<div><span class=""> </span>bSum = 255;</div>
<div><span class=""> </span>targetCursor.get().set(
ARGBType.rgba( rSum, gSum, bSum, aSum ) );</div>
<div><br>
</div>
<div>I have an ImgPlus backed by an RGB PlanarImg of
UnsignedByteType and ARGBType.alpha(value) is 255 for all of
them, so aSum is 765. It would appear that the correct
solution would be to divide aSum by 3. In addition, there's no
scaling of the individual red, green and blue values by their
channel's alpha. If the input were two index-color images,
each of which had different alphas, the code should multiply
the r, g and b values by the alphas before summing and then
divide by the total alpha in the end. The alpha in this case
*should* be the sum of alphas divided by the number of
channels.</div>
<div><br>
</div>
<div>However, I think the problem is deeper than that. For an
RGB ImgPlus, there are three LUTs and each of them has an
alpha of 255, but that alpha only applies to one of the colors
in the LUT. When you're compositing images and weighing them
equally, if two are black and one is white, then the result is
1/3 of the white intensity - if you translate that to red,
green and blue images, the resulting intensity will be 1/3 of
that desired. This might sound weird, but the only solution
that works out mathematically is for the defaultLUTs in the
DefaultDatasetView to use color tables that return values that
are 3x those of ColorTables.RED, GREEN and BLUE. Thinking
about it, I'm afraid this *is* the correct model and each
channel really is 3x brighter than possible.</div>
<div><br>
</div>
<div>It took me quite a bit of back and forth to come up with
the above... I hope you all understand what I'm saying and
understand the problem and counter-intuitive solution and have
the patience to follow it. Dscho, if you made it this far -
you're the mathematician, what's your take?</div>
<div><br>
</div>
<div>--Lee</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
ImageJ-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ImageJ-devel@imagej.net">ImageJ-devel@imagej.net</a>
<a class="moz-txt-link-freetext" href="http://imagej.net/mailman/listinfo/imagej-devel">http://imagej.net/mailman/listinfo/imagej-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>